In the Thermal Power Library from Modelon, there are two kinds of connectors: flow connector and volume connector.
Based on the tutorial shipped with the library, these two kinds of connectors should NOT be connected with the same kind of connector.
But I checked their code, it seems the codes are the same.
I checked the code in the ThermoSysPro library from EDF and ThermoPower library, too. They also use two kinds of connectors, and the recommendation of connecting principle is also the same.
So I read the code of “MixVolume” and “SteamTurbineStodola”, which include volume connectors and flow connectors respectively, but I am not sure the difference between these two kinds of connectors.
My question is :
Could someone tell me the philosophy of using such two kinds of connectors in thermo-hydraulic systems, and in the code of every component, how should I deal with them so they work like they’re designed for.
Here is a very short and simplified explanation applying to thermo-hydraulic systems.
In flow models (pipes, valves etc.) enthalpy is unchanged and mass flow/pressure drop are related with a static equation.
In volume models pressure and enthalpy are dynamic state variables, that is, mass and energy conservation is "elastic".
As a rule of thumb, you should build thermo-hydraulic system models of alternating flow and volume models (in a staggered grid scheme) to decouple nonlinear systems.
For the dynamic pipe model in the top figure in your post the connectors merely indicate that, internally, the pipe model begins with a volume model and ends with a flow model.
Claytex has a nice blog post on the subject here https://www.claytex.com/blog/how-to-avoid-computationally-expensive-fluid-networks-in-dymola/
Also the authors of the Modelica Buildings Library have done a great effort explaining this in various papers. See e.g. https://buildings.lbl.gov/publications/simulation-speed-analysis-and
These kind of connectors are indeed the same due to modelica language specification. You can only connect two connectors that are interchangeable, that have the exact same amount and type of flow and potential variables. At every node all flows have to sum up to zero and all potentials have to be the same, therefore they have to be type consistent.
The difference is just information wise for the modeler or someone trying to understand the model and all components have been designed with such a thing in mind. It is easiest to understand with electrical components, where you have positive and negative pins which indicate in which direction the current should flow, but this is actually never really forced. Positive and negative pins are, ignoring their name, identical.
Although i don't know the connectors you are talking about i would assume that the VolumePort is a connector of something that has a volume and passes that information, whereas FlowPort passes the information about the mass flow rate. Usually a pipe i guess (?). Broken down to abstract dae theory one could say the names indicate if the potential or the flow variable are considered unknown for the component.
I have to emphasize that these are only indicators and that it is never actually forced by the model or the compiler. It is just how it should logically resolve in the end if you respect these restrictions of only connecting VolumePortto FlowPort connectors.
Related
I have been working with Anylogic for about 6 months now and my goal is to model a generic energy supply chain for an energy demand (e.g. storm and heat for a house). As a result I want to evaluate how suitable the components in the energy supply chain are to meet the energy demand.
My idea would be to model the components (Ex. PV->Battery Storage->House) as agents. I would have modeled the energy flow in the agents with SD and individual events of the components (e.g. charging and discharging at the battery) via state diagrams.
Currently I have two problems:
Which possibilities are there to create a variable interconnection of my components (agents). For example, if I do not want to evaluate the scenario PV->Battery Storage->House, but PV->Electrolysis->Tank->Fuel Cell->House. My current approach would be to visually connect the agents with ports and connectors and then pass input and output variables for DS calculation via set and get functions. Are there other possibilities, e.g. to realize such a connection via an input Excel? I have seen a similar solution in the video: "How to Build a True Digital Twin with Self-Configuring Models Using the Material Handling Library" by Benjamin Schumann, but I am not sure if this approach can be applied to SD.
To evaluate the energy supply chain, I would like to add information to the energy flow, for example the type (electricity, heat), generation price (depending on which components the energy flow went through) and others. Is there a way to add this information to a flow in SD? My current approach would be to model the energy flow as an agent population with appropriate parameters and variables. Then agents could die when energy is consumed or converted from electricity to heat type. However, I don't know if this fits with the SD modeling of the energy flow.
Maybe you can help me with my problems? I would basically be interested in the opinion of more experienced Anylogic users if my approaches would be feasible or if there are other or easier approaches. If you know of any tutorial videos or example models that address similar problems, I would also be happy to learn from them.
Best
Christoph
Sounds like what you need is a model that combine agent-based and system dynamics approaches with Agents populating the stocks (in your case energy that then gets converted into heat) depending on their connection. There is an example of AB-SD combination model in 'Example' models and I also found one on cloud.anylogic.com, although it is from a different domain.
Perhaps if you can put together a simple example and share then I'll be able to provide more help.
I'd like to start off by saying that I'm new to StackOverflow and to Modelica.
My goal is to simulate the injector system of a Rotating Detonation Engine. Essentially this is a piping system from a tank to a rocket engine. This system will change depending on the experimental setup, so I chose Modelica (specifically OpenModelica) because of the re-usability of components. The flows encountered will be at high pressures and high flow rates (sustaining a detonation requires this), and choked flow will occur.
My question is this: does the standard "Fluid" library in Modelica allow for choked flow? I understand that a few valves model this, but will the current library be able to capture "choking" in a long rough pipe, or the small end of a converging pipe (basically anywhere choking can happen, despite it not being the design location for a choke)?
If yes, excellent. If not, is there a non-standard library available? Should I be looking at something other than Modelica? I am happy to work on making a new library, but before going through that work I thought I would check to see if anything already existed.
I have read through most of the "Media" and the basics of the "Fluid" libraries and I get the feeling that compressible flow is modeled as a means of increasing accuracy over in-compressible flow, but not to actually handle choked flow.
Thank you for your time. I hope everyone is keeping safe!
The pipe model in the Modelica library does not handle choked flows.
Adding a standard orifice in series with the pipe should help provided the 'zeta' value is adjusted to make the velocity at the orifice match with the speed of sound in the gas. In other words Modelica library does not provide a valid mean of modeling choked flows in pipes.
However, I found a very interesting library called FreeFluids (https://github.com/CarlosTrujilloGonzalez/FreeFluidsModelica) who does have a very good model for choked pipes. An example is provided with the library for a choked air flow in a 10m long diam. 50mm circular pipe. The model returns correct values for air.
I have been reading about Finagle and trying to understand the code to figure out how Aperture's subset choice works.
I have seen that ApertureLeastLoaded has a "useDeterministicOrdering" and an "EndpointFactory" which I guess should be the key points to make the decision of which clients to take in the subset.
While reading the "deterministic subsetting" section of Google SRE's book, I understood that the best way to pick a subset of servers from the client point of view, is to know the total number of clients, and a unique sequential identifier of the current client, that can be used as seed of the subset generator.
In Finagle I can't understand how this process is done (I'm not super familiar with Scala) and the documentation both on the website and in the code, explain just how the aperture paradigm works, but not very clear how the initial subset is chosen
I hope somebody can enlighten me
One of the unique properties of Aperture is that its window is sized dynamically based on a clients offered load. That is, clients have a built in controller which can expand or shrink their window at runtime. This property is important as it allows clients to operate more efficiently and better adapt to a changing environment, but it does make it more complex to achieve a uniform load distribution across servers.
To contrast, the subsetting algorithm, as proposed by the Google SRE book, suggests that operators choose a static subset size which allows a uniform load distribution to be calculated analytically but introduces another static configuration that needs to be revisited as a system evolves.
Deterministic Aperture is, to the best of our knowledge, a novel algorithm for achieving a uniform load distribution while maintaining the dynamic properties of the window sizing mentioned above. From a high level, clients construct a topology of their peer cluster (which gives them a sense of ordering and proximity) and then derive a unique per-client permutation of the servers from the topology such that each server is uniformly represented across the permutations.
We are still in the early stages of testing this in production at Twitter, but early results look very promising. After we gather more empirical results, we hope to publish some more detailed content on how the algorithm works and its properties.
I am currently working with a Modelica model in Dymola to simulate a chemical process. The reactor modeling itself is done to a satisfying extent, but I'm having a hard time implementing these models into Modelica, especially with respect to getting the various Media definitions to interconnect and communicate, so to speak. This is also the key achievement of the Modelica implementation of the model.
At the moment I'm struggling with a specific type of error which, even though it appears quite obvious and straight-forward, I find relatively hard to solve. The errors are of the type:
Note: The input connector p of coopolReactor_2706_1.medium is not connected from the outside.
It is likely that it should have been connected, and recursive check will assume this.
The missing connection is a likely cause of errors in the model.
Note: The input connector h of coopolReactor_2706_1.medium is not connected from the outside.
It is likely that it should have been connected, and recursive check will assume this.
The missing connection is a likely cause of errors in the model.
The model has the same number of unknowns and equations.
The model has the same number of unknowns and equations.
The model EmulsionPolymerizationToolbox.Test.Test_2706 component coopolReactor_2706_1 is structurally singular.
when assuming the most generic outside couplings to all the flow variables of its connectors.
In the specific code which gave this error message, I've mimic'ed a simple lumped volume extending base classes from the Modelica Standard Library, but the error is still the same as for my complete reactor models. That's why understanding and solving this problem is vital to the progress of my assignment.
I've been searching a bit online to find out more about what could cause this problem, without much luck. Could someone please elaborate a bit on these kind of errors, and maybe even suggest solutions? Any inputs from this board will be useful to me.
Thanks in advance.
Regards, Fredrik.
It's possible this is actually a Red Herring. It appears as though this message is generated because of an imbalance in equations. Dymola then searches for the source. It may be that when it seems an imbalance in your component, it also notices that you have an unconnected input and reports that, even if that may not be your problem.
Another thing to keep in mind is that one of the new features in Modelica 3.x was the addition of rules about local balancing of equations and unknowns. One impact of these rules was that for medium models to be balanced, it was necessary to mark some of the variables as inputs (implying they would be specified from the outside). This use of the input qualifier isn't meant to indicate that these variables need to be connected to (or even specified via equations or modifications). Instead, it is really just a way of indicating how many equations are provided by the media model and how many are provided outside.
So where does this leave you. Well, I could be completely wrong (let's not overlook that possibility). But if I'm right, this indicates that you have an imbalance that has nothing to do "unconnected inputs". I suppose the only real help my answer gives is to encourage you to look for other "missing" equations.
If you actually posted code of your simple case, someone might be able to spot the missing equation.
The Modelica Standard Library comes with the Modelica.Media library which makes available thermodynamic properties of fluids.
Quoting from the Modelica.Media documentation:
Media models in Modelica.Media are provided by packages, inheriting
from the partial package Modelica.Media.Interfaces.PartialMedium.
Every package defines:
[...]
A BaseProperties model, to compute the basic thermodynamic properties of the fluid;
setState_XXX functions to compute the thermodynamic state record from different input arguments (such as density, temperature, and composition which would be setState_dTX);
[...]
There are - as stated above - two different basic ways of using the Media library
which will be described in more details in the following section.
One way is to use the model BaseProperties.
[...]
The second way is to use the setState_XXX functions to compute the thermodynamic state record from which all other thermodynamic state variables can be computed [...]
My colleague prefers BaseProperties (he spends most time modeling components),
I prefer the setState_XXX functions (I spend most time writing a property library).
Now we want to develop a simple&small component library together and probably we should agree to use one of the two approaches.
Can you recommend a publication that explains the advantages/disadvantages of the two approaches? Publications that promote the use of the setState_XXX function are preferred of course... ;-)
Are there some simple rules to decide which one of the two approaches to use when modeling a component (e.g. a very simple turbine)?
The components in Modelica.Fluid seem to use both.
The 2 types of patterns for computing properties can both be used for all types of components, but BaseProperties have been designed to make life for the Modeller easy for components with dynamic states, i.e. usually for the storage of mass and energy in volumes. You need to write just the conservation equations, instantiate BaseProperties, equate the relevant variables and you are done. That is often overkill (more equations than minimally needed) for components with a stationary mass and energy balance, like simple valves, pumps and turbines. For that type of components (no dynamic states), the setState_xxx method provide a way to work with the minimally necessary number of equations. I think that is also what you will see in Modelica.Fluid: BaseProperties are used together with dynamic equations for mass- and energy storage, and setState elswhere.
The minimum number of equations is not the whole story w.r.t. computational efficiency, but in geeneral models shoudl not ocmpute more than what is actually needed.