I'm building electrical models that use a complex number or just the real part of a variable in a connector. Depending on a boolean I am switching between the two equation sets.
My question is: What is the best way to handle the imaginary when I don't want to use it. Setting it to zero leads to problems when I connect other components that do the same because the variable is overdetermined.
Is there a way to disable the imaginary part or change the connector so it only has a real variable if I use the real valued equation set?
Below I pasted the equation set.
equation
if transient then
v = Complex(Vnom*cos(theta + phiV),0); // how can I avoid setting im to zero here?
else
v = Complex(Vnom*cos(phiV), Vnom*sin(phiV));
end if;
Thank you in advance for your help!
There is actually an analogous issue in both fluid problems and multibody problems. In the fluid case, the "equation of state" changes which influences how many degrees of freedom there are. In the case of multibody systems, you have the issue that you need some kind of mechanical ground element but if you have a "loop" in your components it will be over constrained.
It seems to me your issue is closer to the fluid problem (but I don't now the AC domain well at all, so I'm just guessing). In that case, what you can do is cascade down through the hierarchy information about exactly what kind of formulation to use. If you want to use different connectors, then you use a replaceable package to cascade new connector types through the hierarchy. This gets kind of involved. If, however, you just want to know whether to use one equation or the other (across a bunch of components), then you can just cascade a (Boolean?) parameter value through everything (e.g., your transient flag).
Another thing you might consider is using inner and outer to implicitly cascade a parameter through your hierarchy. Several libraries use a so-called world object to provide global information about the model. In this way, you can put an inner world object at the root and all components within the same hierarchy can access it using the outer keyword. I try to avoid inner/outer and use the more explicit parameter cascading. But it is up to you.
Related
Modelica modeling is the first principle modeling, so how to test the model and set an effective benchmark is important, for example, I could design a fluid network as my wish, but when building a dynamic simulation model, I need to know the detailed geometry structure and parameters to set up every piece of my model. Usually, I would build a steady-state model with simple energy and mass conservation laws, then design every piece of equipment based on the corresponding design manual, but when I put every dynamic component together, when simulation till steady-state, the result is different from the steady-state model more or less. So I was wondering if I should modify my workflow to make the dynamic model agree with the steady-state model. Any suggestions are welcome.
#dymola #modelica
To my understanding of the question, your parameter values are fixed and physically known. I would attempt the following approach as a heuristic to identify the (few) component(s) that one needs to carefully investigate in order to understand how they influence or violates the assumed first principles.
This is just as a first trial and it could be subject to further improvement and fine-tuning.
Consider the set of significant set of variables xd(p,t) \in R^n and parameters p. Note that p also includes significant start values. p in R^m includes only the set of additional parameters not available in the steady state model.
Denote the corresponding variables of the steady state model by x_s
Denote a time point where the dynamic model is "numerically" in "semi-" steady-state by t*
Consider the function C(xd(p,t*),xs) = ||D||^2 with D = xd(p,t*) - xs
It could be beneficial to describe C as a vector rather than a single valued function.
Compute the partial derivatives of C w.t. p expressed in terms of dxd/dp, i.e.
dC/dp = d[D^T D]/dp
= d[(x_d-x_s)^T (x_d - x_s)]/dp
= (dx_d/dp)^T D + ...
Consider scaling the above function, i.e. dC/dp * p/C (avoid expected numerical issues via some epsilon-tricks)
Here you get a ranking of most significant parameters which are causing the apparent differences. The hopefully few number of components including these parameters could be the ones causing such violation.
If this still does not help, may be due to expected high correlation among parameters, I would go further and consider a dummy parameter identification problem, out of which a more rigorous ranking of significant model parameters can be obtained.
If the Modelica language had capabilities for expressing dynamic parameter sensitivities, all the above computation can be easily carried out as a single Modelica model (with a slightly modified formulation).
For instance, if we had something like der(x,p) corresponding to dx/dp, one could simply state
dcdp = der(C,p)
An alternative approach is proposed via the DerXP library
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 :)
I am building model in Dymola. I have defined the mass of this model as a parameter, because it would be transfered into other moduls and called in them. But the mass should be changing during the simulation in different time intervals. For example, during the first 100 seconds the mass should remain 500kg, and during 100 to 200 sec, a passenger is going to get in, so that a new mass should be calculated including the mass of the passenger. But it has been showed, that "The problem is structurally singular", because to the parameter values have been twice assigned. Could someone give some tips to solve this problem? Thanks a lot.
If you define the mass of your component as an input rather than a parameter then you can change it during simulation by assigning e.g. the output from a TimeTable to it. For example
model Component
input Modelica.SIunits.Mass mass "Passenger dependent mass";
equation
...
end Component;
model systemModel
TimeTable timeTable;
Component component(mass=timeTable.y);
OtherComponent otherComponent(mass=component.mass);
equation
...
end systemModel;
Note that the other components using the mass must also have their internal mass 'parameters' defined as input to allow higher variability than parameters.
Best regards
Rene Just Nielsen
Modelica parameters are defined by the fact, that they don't change over time. Therefore you would need to stop the simulation, change the parameter and restart the simulation (see another question). Given you description I would rather not use this possibility, as it seems your variable is designed to change over time.
A better alternative seems to be defining the mass as a variable. If this is done, you can:
Transfer this variable from one model to the others using interfaces. This could be a bit tedious depending on the amount of classes using the variable.
Use inner/outer (basically global variables) is a feasible concept for this use-case. This concept is used in the MultiBody libraries world model.
With both solutions you will have to modify the original mass model, as m would then have to be a variable instead of a mass.
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.