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.
Related
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 :)
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.
I have run across issues in developing models where the translation time (simulates quickly but takes far too long to translate) has become a serious issue and could use some insight so I can look into resolving this.
So the question is:
What are some of the primary factors that impact the translation time of a model and ideas to address the issue?
For example, things that may have an impact:
for loops vs a vectorized method - a basic model testing this didn't seem to impact anything
using input variables vs parameters
impact of annotations (e.g., Evaluate=true)
or tough luck, this is tool dependent (Dymola, OMEdit, etc.) :(
use of many connect() - this seems to be a factor (perhaps primary) as it forces translater to do all the heavy lifting
Any insight is greatly appreciated.
Clearly the answer to this question if naturally open ended. There are many things to consider when computation times may be a factor.
For distributed models (e.g., finite difference) the use of simple models and then using connect equations to link them in the appropriate order is not the best way to produce the models. Experience has shown that this method significantly increases the translation time to unbearable lengths. It is better to create distributed models in the same approach that is used the MSL Dynamic pipe (not exactly like it but similar).
Changing the approach as described is significantly faster in translational time (orders of magnitude for larger models, >~100,000 equations) than using connect statements as the number of distributed elements increases to larger numbers. This was tested using Dymola 2017 and 2017FD01.
Some related materials pointed out by others that may be useful for more information have been included below:
https://modelica.org/events/modelica2011/Proceedings/pages/papers/07_1_ID_183_a_fv.pdf
Scalable Test Suite : https://dx.doi.org/10.3384/ecp15118459
I wonder if there a way to "debug" a modelica code, I mean debugging the code line by line and you can see how variables change, things like that?
I know that the modelica code is translated into C, I just want to know if there's a possibility to do that somehow, if there is, I believe it's gonna be a great improvement for any of the simulation environments. Thanks.
HY
This is a good question and it comes up a lot. But first, let's step back for a second.
The idea of debugging "line by line" is something comes from imperative programming languages. By "imperative" I mean that a program is simply a sequence of instructions to be carried out in the specified order.
When someone debugs Java or Python, this "line by line" approach makes sense because the statements are the fundamental way behavior is represented. This "line by line" approach could also be extended to modeling formalisms like block diagrams (e.g. Simulink) because, while graphical, they are also imperative (i.e. they constitute steps to be carried out in a specified order).
But Modelica is not an imperative language. There is no notion of steps, statements or instructions. Instead, we have omnipresent equations. So thinking linearly about debugging doesn't work in Modelica. It is true that you could think about debugging the C code generated from Modelica, but that is typically not very useful because it bears only a partial resemblance to the equations.
So how do you debug Modelica code? Well, debugging Modelica code is really debugging Modelica equations. Normally, Modelica models are composed of components. The equations that are generated when components are connected are automatically generated so lets stipulate that the Modelica compiler generates those correctly. So what's left is the equations in the component models.
The simplest way to approach this is to test each component individually (or at least in the smallest possible models). I often say that trying to debug Modelica components by throwing them all together in a big model is like listening to an orchestra and trying to figure out the one instrument that is out of tune. The fact that these equations in Modelica tend to form simultaneous systems of equations means that errors, when they occur, can propagate immediately to a number of variables.
So your best bet is to go through and create tests for each individual component and verify the behavior of the component. My experience is that when you do this, you can track down and eliminate bugs pretty easily.
Update: You shouldn't need to add outputs to other people's component models to debug them. An output can be created at any level, e.g.
model SystemModel
SomeoneElsesComponent a;
SomeOtherGuysComponent b;
end SystemModel;
model SystemModel_Debug
extends SystemModel;
output Real someNestedSignalFromA = a.someSubsystem.someSubcomponent.someSignal;
output Real someOtherNestedSignalFromB = b.anotherSubsystem.anotherSignal;
end SystemModel_Debug;
Of course, this becomes impractical if you have multiple instantiations of a signal component. In those cases, I admit that it is easier to modify the underlying model. But if they make their models replaceable, you can use the same trick as above (extends their model, add a bunch of custom outputs and then redeclare your model in place of the original).
There is a transformation debugger in OpenModelica now. You can find here which variable is evaluated from which equation.
I'm new to Dymola and I have to implement a chemical reactor in Dymola.
I modeled the behaviour of the reactor in 3 different models, because the reactor behaves different depending on a variable x. So that model a is valid for x<=0.1, model 2 is valid for 0.75>x<0.1 and model 3 is valid for x>0.75. Is there any way to run only one of the three models in each simulation step? I have looked into the "if" statement to put all 3 model equations in one model, but that didn't work. Is there anyone out there who can help me? Any hint would be great! Thank you!
Modelica does not handle variable structure problems. What this means is that the set of variables cannot change during the simulation.
Most people who are trying to solve such systems typically find a way to keep all variables present but somehow "deactivate" different sets by switching equations (which can, to some extent, change during the simulation).
If you give a bit more information about the types of models you need to switch between, I could try to give you some hints about how to "deactivate" them from one phase to another.