I used heat exchanger from Building library and changed the media to MSL media. I am getting the warning as mentioned in the figure. But, It is simulating. Can anyone tell me what the warning represents? How to avoid it
The warning seems to indicate that you have a variable where the nominal-attribute cannot be evaluated to a literal.
A trivial model would be:
model M
Real x(nominal=p);
parameter Real p=10 annotation(Evaluate=false);
equation
der(x)=1-x;
end M;
The warning indicates that since the attribute couldn't be evaluated it is ignored, as if it hadn't been set.
The nominal-attribute is used for scaling of variables (in particular states), and should indicate the natural scale of the variable - and it is most important if the variable varies on scale substantially different from 1 and may be close to zero; so it seems somewhat important in this case.
The answer by #ReneJustNielsen indicates the likely cause.
It looks as if you have a component volume in your model to which you haven't assigned a medium model (air) but only kept the default PartialMedium
Related
I build a simple model to understand the concept of "Discrete expressions", here is the code:
model Trywhen
parameter Real B[ :] = {1.0, 2.0, 3.0};
algorithm
when time>=0.5 then
Modelica.Utilities.Streams.print("message");
end when;
annotation (uses(Modelica(version="3.2.3")));
end Trywhen;
But when checking the model, I got an error showing that "time==0.5" isn't a discrete expression.
If I change time==0.5 to time>=0.5, the model would pass the check.
And if I use if-clause to when-clause, the model works fine but with a warning showing that "Variables of type Real cannot be compared for equality."
My questions are:
Why time==0.5 is NOT a discrete expression?
Why Variables of type Real cannot be compared for equality? It seems common when comparing two variables of type Real.
The first question is not important, since time==0.5 is not allowed.
The second question is the important one:
Comparing reals for equality is common in other languages, and also a common source of errors - unless special care is taken.
Merely using the floating point compare of the processor is a really bad idea on idea on some processors (like Intel) that mix 80-bit and 64-bit floating point numbers (or comes with a performance penalty), and also in other cases it may not work as intended. In this case 0.5 can be represented as a floating point number, but 0.1 and 0.2 cannot.
Often abs(x-y)<eps is a good alternative, but it depends on the intended use and the eps depends on additional factors; not only machine precision but also which algorithm is used to compute x and y and its error propagation.
In Modelica the problems are worse than in many other languages, since tools are allowed to optimize expressions a lot more (including symbolic manipulations) - which makes it even harder to figure out a good value for eps.
All those problems mean that it was decided to not allow comparison for equality - and require something more appropriate.
In particular if you know that you will only approach equality from one direction you can avoid many of the problems. In this case time is increasing, so if it has been >0.5 at an event it will not be <=0.5 at a later event, and when will only trigger the first time the expression becomes true.
Therefore when time>=0.5 will only trigger once, and will trigger about when time==0.5, so it is a good alternative. However, there might be some numerical inaccuracies and thus it might trigger at 0.500000000000001.
The noEvent operator in Modelica doesn't use iteration to find the precise time instant in which the event was triggered.
It seems this would cause calculation error, here is an example I find on the following website
https://mbe.modelica.university/behavior/discrete/decay/
So Do I have to ensure the function is smooth when using noEvent operator?
What's the purpose of using noEvent operator if it can't ensure accuracy?
Although the question is already answered I would like to add some points, as I think it could be useful for many.
There are some common reasons to use the noEvent() statement:
Guarding expressions: This is used to prevent a function from being evaluated outside of their validity range. A typical example is der(x) = if x>=0 then sqrt(x) else 0; which would work perfectly in most common programming languages. This doesn't work always in Modelica for the following reason: When searching for the time when the condition x>=0 becomes false, it is possible that both branches are evaluated with values of x varying around 0. The same fact is mentioned in the screenshot posted by marvel This results in a crash if the square root of a negative x is evaluated. Therefore der(x) = if noEvent(x>=0) then -sqrt(x) else 0; Is used to suppress the iteration to search for the crossing time, leaving the handling of the discontinuity to the solver (often referred to as "expressions are taken literally instead of generating crossing functions"). In case of a variable step-size solver being used, this makes the solver reduce the step-size to meet it's relative error tolerance, which will likely result in degraded performance. Additionally this can be critical if the function described is not smooth enough resulting in non-precise or even instable simulations.
Continuous Expressions: When a function is continuous there is actually no event necessary. This comes down to the fact, that events are used to describe discontinuities. So if there is none, usually the event is simply superfluous and can therefore be suppressed. This is actually covered by the smooth() operator in Modelica, but the specification says, that a tool is free to still generate events. To my experience, tools generate events if the change to the function is relatively big. Therefore it can make sense to have a noEvent() within a smooth().
Avoid chattering: noEvent can help here but actually chattering is a more general problem. Therefore I'd recommend to solve issues related to chattering by re-building the model.
If none of the above is true the use of noEvent should be considered carefully.
I think the Modelica Language Specification Version 3.4 Section 3.7.3.2. and Section 8.5. will help you out here (in case you have not already checked this).
From what i know it should only be used for efficiency reasons and in most cases one should use smooth() instead or in conjunction.
Based on the two different ways of dealing with the event. If using noEvent operator, there is no halt of the integration, but the numerical solver assumes that the function should be smooth, with unsmooth functions, there would be numerical errors.
I met an error during initialization when using ThermoSysPro library.
It seems like the Turbine5.Pe is larger than Turbine2.Pe, so the result is negative. but I checked my parameters, there shouldn't be such a problem.
Is this because the nonlinear solver couldn't solve the equation in the following picture?
There is not enough information and I would recommend to set Details and/or Nonlinear iterations in Simulation setup>Debug>Nonlinear solver diagnostics to get more information.
The full expression causing the problem is sqrt((Turbine2.Pe^2-Turbine5.Pe^2)/(Turbine2.Cst*Turbine2.proe.T))
Since the two Pe-values have fixed=true it seems unlikely that they are wrong, but it is impossible to see without the complete model.
However, it is also possible that either Cst or proe.T is negative, or computed to a negative value based on other values.
Without a complete model that is impossible to tell.
According to the comparison between ThermoSysPro(Open source library from EDF https://github.com/alex19941215/ThermoSysPro ) and ThermalPower(Commercial library from Modelon https://www.modelon.com/library/thermal-power-library ), there should be some inspiration for people faced with the same situation.
Here is the code form ThermoSysPro library:
Connectors.FluidInlet Ce
Connectors.FluidOutlet Cs
Here is a type code from Thermal Power library:
Interfaces.FlowPort feed(
h_outflow(start=hstartin))
Interfaces.FlowPort drain(
p(start=pstart),
h_outflow(start=hstartout))
From the code, we can see that in the Thermal Power library each connector's attribute is assigned values according to the parameters, but in the ThermoSysPro library, the connector is using default values, probably zero. So that's why the Thermal Power library has better performance in the term of initialization convergence
What is a test point and its intended use in matlab ?
I am working on a model and have to use 3 AND gates in conjunction coupled with similar 2 more AND gates. While checking the model I am getting warning "Identify single logical operator blocks with more than 9 inputs signals.", which is not shown if I use testpoint on each of these AND gate output.
Think of a signal in Simulink as corresponding to a memory location.
In an effort to reduce memory consumption, one of the standard optimizations used by Simulink is to re-use the same memory address when possible.
For instance, assume the input to a gain block is stored at memory location X. Then the output of the gain block would overwrite the data in X. Consequently the input value would no longer be available. But it doesn't need to be as it's value is never used again. (This assumes that the input value is not used elsewhere, such as feeding a block like a Scope.)
In your case, the warning is telling you something about Simulink storing the logical values in memory locations that it subsequently overwrites when possible.
Note that Simulink will never re-use memory when it needs the signal value in subsequent calculations, i.e. when it would effect the simulation result if it did so.
Nor will it re-use memory (for a specific signal) when you designate the signal as being a test point.
This is why the warning is going away in your case.
One particular use of a test point is if you are using a Floating Scope. Floating Scopes cannot be made to look at signals where the memory is being re-used because then it wouldn't be clear which signal was being displaying.
By looking at only test points it is guaranteed that you are looking at the expected data/memory.
In the Modelica Standard Library 3.2.1 a model for the refrigerant R134a was included, but it seems not to work properly with Modelica.Fluid. In a simple example with one DynamicPipe, it results in the following error:
A calculation of two-phase properties with input of pressure and temperature is not possible.
Please use setState_dTX or setState_phX instead.
The stack of functions is:
setState_pTX_Unique15
setState_pTX_Unique15(101325, 293.15, {1.0}, 0)
use_T_start is false. What is the problem here? How can it be solved?
TIA
Update:
The selected states are h and p, as it should be. The parameters of the pTX call seem to be the default values for the chosen medium.
PartialStaggeredFlowModel uses Medium.density_pTX and Medium.setState_pTX, but changing these to the respective phX-functions does not solve the problem.
The issue here is your choice of thermodynamic states. As the message indicates, you cannot use a two-phase medium with pressure and temperature as the thermodynamic states.
As a simple example, consider water/ice. If you measure the temperature as it is freezing, you'll see that when the mixture is "slushy" (contains both liquid and solid), the temperature will remain constant. So knowing the temperature is not sufficient to know the true (thermodynamic) state of the system because we cannot compute the relative fractions of liquid and solid with that information. The solution is to use pressure and enthalpy (as the error message suggests) as the thermodynamic states.
I don't know enough about the Modelica.Media and Modelica.Fluid libraries to tell you how to change your selection of thermodynamic states. But I suspect you'll find the answer in the documentation of one of those libraries.
The solution is already in my update. PartialStaggeredFlowModel uses Medium.density_pTX and Medium.setState_pTX. Replacing these with Medium.density_phX and Medium.setState_phX avoids the pT-problem. The reason why it did not work at first was one reference to the unmodified class I forgot to change.
Other Modelica.Fluid-components have the same problem, e.g. the pump-models are based on PartialPump, which also uses Medium.density_pTX.
Thank you for your contributions.