NaN issue in model for kc_roundTube

[maltelenz]

The csv file ModelicaTest/Fluid/Dissipation/Verifications/HeatTransfer/HeatExchanger/kc_roundTube/kc_roundTube.csv in the reference result repository contains a nan in the first row of data.

Is this expected? What should it be interpreted as?

[beutlich]

@wischhusen There is a floating-point overflow at simulation start time for Nu[3] in Modelica.Fluid.Dissipation.HeatTransfer.HeatExchanger.kc_roundTube_KC which is not covered. Therefore, either the test model ModelicaTest.Fluid.Dissipation.Verifications.HeatTransfer.HeatExchanger.kc_roundTube or the called function Modelica.Fluid.Dissipation.HeatTransfer.HeatExchanger.kc_roundTube_KC need to be fixed.

[maltelenz]

@beutlich I think this can be closed after #3512 was merged?

[beutlich]

I am not sure if this should be closed, since we only removed the invalid test but not the actual cause. Would be good to get some feedback from @wischhusen after all.

[wischhusen]

we are having a look at the underlying functions … sorry for the delay.

[wischhusen]

The issue is caused by log(Re_Dc) in several divisor expressions ... We will propose something.

[TManikantan]

@wischhusen Hi,i recently assumed the role of project deputy. Did you get around finding the solution to the issue.Would you please commit the fix if you have done it.Thanks

[TManikantan]

@wischhusen hi, did you get around finding the solution?

[arunkumar-narasimhan]

I have investigated this further. Certainly caused by log(Re_Dc) in the divisor, but might be originating from Re_Dc during low or zero flow conditions in Modelica.Fluid.Dissipation.HeatTransfer.HeatExchanger.kc_roundTube_KC. Despite this expression with MIN, Modelica.Units.SI.ReynoldsNumber Re_Dc=max(MIN, (abs(IN_var.m_flow)*IN_con.D_c /(IN_var.eta*A_c))), kc values goes to infinite near initialization, maybe causing floating point overflow. Tested with a small dummy real value of 1.1 in place of MIN as is followed in other thermal libraries as reference and found that there were reasonable numbers for kc[2] and kc[3] as well. @wischhusen, would such a solution work? Please note that I haven't done a csv compare yet to see if there are modifications in kc[1] and kc[4].

[TManikantan]

I have investigated this further. Certainly caused by log(Re_Dc) in the divisor, but might be originating from Re_Dc during low or zero flow conditions in Modelica.Fluid.Dissipation.HeatTransfer.HeatExchanger.kc_roundTube_KC. Despite this expression with MIN, Modelica.Units.SI.ReynoldsNumber Re_Dc=max(MIN, (abs(IN_var.m_flow)*IN_con.D_c /(IN_var.eta*A_c))), kc values goes to infinite near initialization, maybe causing floating point overflow. Tested with a small dummy real value of 1.1 in place of MIN as is followed in other thermal libraries as reference and found that there were reasonable numbers for kc[2] and kc[3] as well. @wischhusen, would such a solution work? Please note that I haven't done a csv compare yet to see if there are modifications in kc[1] and kc[4].

@hubertus65 , @casella , @wischhusen do you agree with this solution suggested by @arunkumar-narasimhan ?

[hubertus65]

Hi Mani,

Yes, please go ahead, I agree with your proposed solution. @TManikantan

[TManikantan]

Thanks for your response @hubertus65

[arunkumar-narasimhan]

Upon further investigation, we narrowed down the issue to the numerical value in Re_Dc Re_Dc:=max(40, (abs(IN_var.m_flow)*IN_con.D_c/(IN_var.eta*A_c))) in function Modelica.Fluid.Dissipation.HeatTransfer.HeatExchanger.kc_roundTube_KC. Setting it to 1.1 did not help, especially with 3rd fin case (slitFin). Case 2 geometry has different if loops based on Re # which is the cause, Case 3 geometry has this ratio 26.7*IN_con.N/Re_Dc, which transitions from above 2 to small values close to zero. This appears to be the prime reason in the case of slit fin geometry. Assuming a different value of 40 in Re_Dc expression avoids this big transition, or in other words small values of Re_Dc in the divisor. We could also derive an expression for generic cases. However, for some time instances, Re_Dc is a constant value, so Nu would also appear as constant value - reason why Nu[1] is erroring out in attached html file. Did a csv compare with the old reference result containing Nu[2], Nu[3] as well in attached zip file. Would this fix work or should we go for a generic expression? file_base.zip

[TManikantan]

@casella @wischhusen would you please comment on what could be the next step of action here.

[casella]

@TManikantan I'm not sure I get the full picture. Unfortunately I don't have time now to go through the entire chain of computations. What I found weird in the CSV file is that the Nusselt numbers have totally erratic values.

I checked the kc_roundTube function. In the released 4.0.0 version, the Re and Nu outputs are only computed under some conditions, but are otherwise undefined, which could explain the weird numerical results. In the current master, an assert was added to guard against that. I guess the reference results were obtained with 4.0.0, so this could explain the orginal problem.

In any case, IMHO a Modelica tool should not compute some variables to be NaN with impunity, and then continue, I think it should raise a runtime error and stop, as it happens with division by zero or logarithm of a negative number. NaNs can propagate in the solution like a cancer, and I'm not aware of any definite semantics of NaN in Modelica, the search for "NaN" in the current Modelica Language Specification returned no results.

[HansOlsson]

In any case, IMHO a Modelica tool should not compute some variables to be NaN with impunity, and then continue, I think it should raise a runtime error and stop, as it happens with division by zero or logarithm of a negative number. NaNs can propagate in the solution like a cancer, and I'm not aware of any definite semantics of NaN in Modelica, the search for "NaN" in the current Modelica Language Specification returned no results.

Yes, and one reason is that if variables could have the value NaN tools would be prevented from performing most symbolic simplifications. E.g., consider x+y=x+1; where we normally find that y=1, but if x is NaN then that breaks down in some way (depending on what we mean with equality).

[casella]

@HansOlsson, according to Section 12.4.4 of the MLS,

It is an error to use (or return) an uninitialized variable in a function.

I wonder if those reference results for Nu[] were obtained disregarding this rule. Would the current version of Dymola produce those erratic values (including NaNs) if ModelicaTest.Fluid.Dissipation.Verifications.HeatTransfer.HeatExchanger.kc_roundTube is run with version 4.0.0 of the MSL?

Just by looking at them, they really seem not to be related to the physical behaviour of the system, but really look like spurious uninitialized values coming from who knows where.

Thanks!