Hi I recently bought SystemModeler and was disappointed that the Fluids Library is not included In the Modelica Standard Library . Is there a plan to include this library in SystemModeler future updates and when will this happan
Fluid's library is a work-in-progress for us. If everything goes as per plan then we should be able to release it in the next version i.e. 12.2.
Any updates on SystemModeler 12.2 and the inclusion of streams and Fluid Library. I have a need for streams in my modeling and would like to stick to SystemModeler as my base package as I like the Mathematica integration. Currently I am having to work with OpenModelica to use the stream and Fluids functionality of MODELICA 3.3. I am hoping that SystemModeler will include streams and fluids in the next release.
You should be able to use streams with 12.2, Fluid's library is still a work-in-progress.
You can drop me a mail at firstname.lastname@example.org if you want to try out the development version.
I'm also interested in using the Fluid's library that is part of Modelica. I have installed v12.2 and still cannot see the library or get it to work. I get odd behavior when I try to use the examples provided within Modelica.Fluids v4.0. Suggestions?
Hi @Patrick Fourspring, as the support is still on experimental it is not activated by default. You will have to right click on the Modelica library in the class browser and select Version > 3.2.2 with Fluid library (experimental) or Version > 4.0.0 with Fluid library (experimental).
Hello Jan, Thanks for the quick response. I was able to both open the (experimental version of 4.0).
I am running System Modeler v12.2 using Modelica 3.2.3 experimental. The heat exchanger component (Modelica.Fluid.Examples.HeatExchanger.BaseClasses.BasicHX) runs successfully if the node parameter is set equal to one (nNodes = 1). However, the component fails to run with any value greater than one (nNodes >1) with the following message:
"Tearing of equation system with 96 variables reached leaf node limit without finding a feasible solution, where the leaf limit is currently not customizable. Consider splitting equations so that discrete-valued variables can be solved separately.Validation of model HeatExchangerSimulation1 completed with 1 error."
Instead of speaking of the component base class, could you please provide a complete simulation model that illustrates the problem?
Thanks for your interest, Henrik. I am new to the forum, and I should have included that I am attempting to run the example, HeatExchangerSimulation, as is (except for the nNodes parameter) provided in the Modelica.Fluid.Examples.HeatExchanger library. Let me know if I can provide anymore information.
Unfortunately, you have come across the only known example that doesn't build due to this error. (There is also the regression testing model IncompressibleFluidNetwork_StandardWaterOnePhase exhibiting the same issue.) For me, using 12.3, it doesn't even build with nNodes = 1 (I'll come back to this below).
Explaining what the problem really is here is a bit complicated, but it has to do with the de facto standard procedure for dealing with so-called mixed equation systems in Modelica, which requires a separation into one part of the equation system having only discrete-valued variables (such as Integer and Boolean variables), and one part with only continuous-valued (Real) variables. In practice, there are tricks that can be applied to obtain the separation even when it may look impossible at first glance, like here, where there are algorithms involving a mix of variables. While we are generally able to work things out, what you have encountered is an exception.
I wanted to see if there was something that we could learn by looking at the special cases of small values of nNodes, and found that – in line with your observations for WSM 12.2 – the case of nNodes = 1 can actually be fixed by the addition of some randomization to our algorithm. While we're trying hard to avoid such randomization because unpredictable build success is probably most of the time worse than no success at all, the important lesson learned is that a solution is actually hiding somewhere in the exponentially large combinatorial search space. One just needs the right (predictable) search algorithm to find it quickly.
For nNodes = 2, randomization is no longer enough, but one could hope that a systematic (predictable) way of solving the nNodes = 1 case would actually work also for higher values of nNodes… Unfortunately, because of the domain-specific nature of the problem and how it interacts with heuristics that need to work well across all domains, I cannot give any estimate of when the issue might get fixed.
Whew! Thanks for the lengthy response, Henrik. I appreciate the details. As you probably know, the model is configured into segments because the thermodynamic properties of the fluids change sufficiently as they pass through the heat exchanger. Then for each segment, the properties are assumed to be constant.
If I understand correctly (a big if) from your response that if the problem was configured to involve only discrete variables, the formulation of the equation system would be simplified. In other words, if problem was configured with only discrete variables by re-assigning continuous (global) variables into discrete variables for each segment, the formulation of the equation system would be simplified.
Another approach would be to drop the segmentation of the problem and instead present a model for the heat exchanger with only continuous variables, including equations of the thermodynamic properties as a function of temperature and pressure. This approach will be more involved at my end but possible.
Turning Real variables into discrete-valued ones is probably not possible considering the constraints on how such variables may be solved in Modelica models: each discrete-valued variable needs to be solved from an equation in solved form, and must not form cyclic dependencies with other discrete-valued variables. In addition, having many discrete-valued variables in a mixed system generally makes it more difficult to deal with.
By looking at the case of nNodes = 1, which also simulates without problems, I made some additional observations that might be of interest. The discrete-valued variables are only region and phase variables. Moreover, there's just a single region that actually contributes to mixedness in a non-trivial way. When the equation system tearing succeeds, this non-trivial discrete-valued variable becomes hidden as an intermediate variables of the computation that actually doesn't affect the mixedness of the equation block, so from the outside it becomes a system in only continuous-valued variables. This probably matches well what one would expect of a heat exchanger.
The first open question that remains is how to conclude that the region and phase variables can be given similar roles also for nNodes > 1. Once that has been established, the next question becomes to think about what this means for our current approach of introducing temporary records for the results of function calls, especially when combined with equation tearing as a method of "hiding" the discrete-valued variables.
None of this is easy for someone who isn't an expert on media modeling in general, and modeling with Modelica and its Media in particular. I'm also afraid it isn't really of any help to you.
Thank you, Henrik. Let me know if I can answer any questions about heat exchanger analyses. I have little to contribute to the coding required to solve the Modelica code (with Media) in this case. I appreciate the engagement and the candor.
Thank you, Patrick, for bringing our attention to this problem. Also thanks for offering expertise on heat exchanger analysis! To me, however, this looks very much like problem in the technical details of how medium properties are computed in Modelica. Still, your idea of modifying nNodes has already been very helpful, and will probably be of much value once again when we get the chance to turn our full attention to the problem.
Update: The HeatExchangerSimulation is now working in development builds, after adjustments to the tearing algorithm. This would have required much more effort without the valuable discussion in this thread. Thanks!
Excellent news, Henrick. Thanks for sharing your progress.