Modelica.Media.R134a Error - modelica

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.

Related

HX from Building library getting errors but simulating

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

integrate Modelica variable without influencing state selection

I want to integrate a Modelica variable over time, just for convenience in plotting and post-processing. The variable I want to integrate over time is the power of a compressor so that I get the total energy. The first idea would be to add these lines:
Modelica.Units.SI.Power P_comp;
Modelica.Units.SI.Energy E_comp;
equation
P_comp = der(E_comp);
Is that the recommended way, or are there (better?) alternatives? Is it expected to influence the selection of dynamic states?
Assuming that those two lines are the only ones using E_comp that should work.
Basically E_comp will be part of its own separate state-selection block and changes there shouldn't influence anything else.
However, state selection consists of a number of algorithms and heuristics so it is difficult to formally guarantee that any change does not influence it.
I could imagine some strange possibilities that would break this, but I don't think anyone has implemented them - and I don't see a use-case for them (except to mess up cases like this).
And if you instead of integrating want to differentiate a signal it is a lot messier.

A general question about Modelica initialization

How to set values to all the variables that could be possibly used as iteration variables, for example, there is a heat exchanger which includes a few connectors, and each connector includes a few variables, I can't know which variables could be used as iteration variables, when dealing with initialization, do I need to set values to every variable so that no matter which variable is chosen as iteration variable, there is a reasonable value?
Marvel,
I think that you are a bit on the wrong track for finding a solution: setting values to all variables that possibly could become iteration variables is often too many, and will lead to errors and problems. But I think I can give you some useful advice in any case.
Alias variables: there are many alias variable sin Modelica models. You should always try to only select one of them to set start values.
Feedback between start values and iteration variables: most Modelica tools will prefer to select iteration variables that have start values set. Selecting fewer thus can guide the algorithm towards selecting good one. Therefore: don't overdo it.
General advice for selecting iteration variables. For a pure ODE, the states will always be a complete set of start variables, even if sometimes not the best one. For DAE you can start with the following exercise: think of all equations that result from a singular perturbation of the complete physics as differential equations with states. For example, in a heat exchanger, you need to consider the dynamic momentum balance and not the most often used static reduction to an algebraic pressure loss only, i.e. add the mass flow as a state. Similar in chemical reactions: think of it as Kinetics, not equilibrium reactions. That gives you a pretty good starting point, even though often not the best one.
If your troubles don't quite resolve from that, I recommend that you contact us via www.modelon.com: we have advanced ways of dealing with hard initialization and steady state problems in our Modelic tool. :-)
There is also a simplest way to answer your question, working quite well with fluid models.
Giving the fact that you are using a dynamic model, what you need to initialize are the state variables of your system. To know the state variables, either you know the type of model you are wirking with or you can dig through them using options like 'List continuous time states selected' in Dymola (I do not know about other tools), giving you the state variables in the translation log.
In case of fluid models, most of the times those are pressure and energy (enthalpy or temperature). All other variables will be calculated based on them.
For complex (or not) models, this approach show limits, which can sometimes be solved by changing/correcting the structure of the model.
Static models are something else...
Hope this can help :)

Non-liner solver couldn't converge during the initialization in Dymola

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

How to use the value of the variable in the previous interval as an input to the equation....?

Is it possible to use the previous value of the time varying variable
for eg:
Suppose I have pipe whose inlet temperature is 298K with a specified uniform mass flow(m_flow), now suppose i am heating the pipe using a heater of 100 watts.
The outlet temperature will be attain a higher temperature of suppose 302K, now if i have to use this outlet temperature as my inlet temperature (in the sense i am recircuilating the water), how would i be doing it?
is it possible to update the value of the inlet temperature based on the outlet temperature at the previous timestep? so that for the next iteration the inlet temperature will be the same as the oulet temperature in the previous iteration (in other words the fluid would be recirculating).
Thanks
You cannot access the value in the previous time step. The closest you can get in Modelica is using delay(exp,T) to get the value T units of time ago.
The timestep does not enter into it at all. A model that uses information about timestep is just wrong. Nature doesn't know or care about integration time steps, the model should reflect that.
It seems to me what you want to capture is transport delay. Transport delay is the delay introduced by the time it takes for molecules, electrons, etc. through the system. So presumably what you wish to model is the time it takes the inlet fluid to reach the exit. Again, this has nothing to do with the integration timestep but rather the velocity of the fluid and the distance it must travel. Once you know how long that takes (by either a priori knowledge of the system of by looking at the simulation results themselves), you can follow Marco's suggestion of using the delay operator.
In order to setup a proper model for the system you described I suggest you to look at the example :
Modelica.Thermal.FluidHeatFlow.Examples.IndirectCooling
of the modelica standard library ver. 3.2. Instead of one pipe you can put an ambient or control volume component to better suit you needs. Moreover using continous and differentiable equations (the delay function is not) you will benefit from some of the advantages of the Modelica code, e.g. you will be able to reuse your models in a much wider range of cases, solve inverse problems, solve initial value problems, ...
I hope this helps,
Marco