There is an option in Dymola "Save start values in the model", which allows one to re-use these parameters in order to tune the simulation.
I was looking for a similar possibility in OpenModelica, but so far I wasn't able to figure it out. Particularly, I am building a model with ThermoSysPro, which is rather sensitive to the change of initial values. My model has several vertical pipes (upstream, downstream), so it fails quite easily.
1. Is it possible to save initial / start / guess values in OpenModelica?
2. What would be the ways of implementing / taking these values in the model? (let's say I have density - ρ, enthalpy - h, temperature - T and so on. Just for simplification purposes for Modelica newbie)
------UPDATE------
In my case, I have two approaches to start / initial values: (ThermoSysPro - TSP)
Approach 1 - Run the simulation for 1s without changing default start-values given in TSP by introducing desired boundary conditions or close ones that it would run successfully.
Gather the generated initial values and add them as start-values (time-consuming when one has a lot of components).
For components such as “volume” or any other component that is not discretized it is enough to give these values under the “Initialization” section in the component or in the “Text view” window e.g. Q(start = 0.3); P(start = xxx).
But in case of discretized components, such as “pipe” it has to be done via “Text view” by using the operator each e.g. Q(each start = 0.3). However, the operator “each” disappears when one changes any parameter of the component via “Diagram view”, so it has to be given as follows:
• Q(start = {0.3 for i in 1:componentName.Ns+1})
• Q(start = fill(0.3, componentName.Ns+1))
• Q(start = {x1, x2, x3, x4, … xi})
Ns + 1 - for hydraulic nodes / Ns – for thermal nodes
PROBLEM
P.1.1 - Normally, one should write:
Q(start = fill(0.3, Ns+1), fixed = fill(true/false, Ns+1))
But it is the same story as with operator each, after changing any parameter of the component via “Diagram view”, the attribute fixed changes automatically to fixed=false, although an array is needed. I tried creating a Boolean parameter and using array comprehension but I always get the same outcome. Any advice or workaround?
P.1.2 – I cannot see any improvement (speed up / better results / or something else) of simulations, after adapting the generated start-values instead of using default ones. Also, after adapting too many of them, I start getting initialization problems – which should be opposite for my understanding. So, I am not sure how I should be using/declaring start-values properly? Maybe the problem is that I do not explicitly add fixed = true/false?
Approach 2 – calculate start-values based on the boundary conditions by using Modelica functions. So firstly, I calculate start-values of multiple parameters (normally I do for pressure and enthalpy). e.g.
parameter Modelica.SIunits.Enthalpy init_enthalpy[Ns+1] = {Modelica.Media.Water.WaterIF97_base.specificEnthalpy_pT(P[i], T) for i in 1:Ns+1}
and then add it for specific component as:
h(start = init_enthalpy)
PROBLEM:
P2.1 With the ThermoPower library this approach works perfectly, but with ThermoSysPro, I am having difficulties, as there are so many parameters that can be given for initialization. How many parameters generally should be given or how to locate the most important ones that definitely should be given?
P2.2 Is there a difference between declaring start / initial values in the initial equation section and calculating it as a parameter (like above)?
P2.3 By indicating that start-value is either fixed=true / false wouldn’t mean that you are using the so-called "inverse problem"?
P1.1 Regarding the missing each operator, that unfortunately is a known bug we are trying to fix. Related ticket:
I also cross linked this question.
P1.2 Start values don't really speed up the simulation, only (slightly) the initialization. If you don't provide any, the compiler just sets them to zero and starts from there. This could cause multiple problems:
If you provide to many initial values you could cause alias conflicts or over-constrain the system. If you have an equation as a=b and provide start values for both, they have to be equal. Your provided start values will always shadow the ones from the original model and not cause alias conflicts though. If you have conflicts the compiler chooses arbitrarily between the options (some pretty basic heuristic).
Approach 2 Unfortunately i am no engineer so i don't know if that is the right way, but in general this seems fine.
P2.1 The default initial values from libraries are fine most of the time, you only have to set them specifically if you want to do something differently. E.g. a boiler starts with higher temperature or something like that.
If you want to have full information use: Simulation -> Simulation Setup -> Translation Flags The field Additional Translation Flags. Put: -d=backenddaeinfo,stateselection,discreteinfo,iterationVars
I did this for Modelica.Electrical.Analog.Examples.Rectifier and here is the output:
[1] 11:25:25 Symbolic Notification
Model statistics after passing the front-end and creating the data structures used by the back-end:
* Number of equations: 128
* Number of variables: 128
[2] 11:25:25 Translation Notification
List of all iteration variables (DAE kind: initialization)
Iteration variables of torn nonlinear equation system:
IdealDiode6.s:VARIABLE(start = 0.0 unit = "1" protected = true ) "Auxiliary variable for actual position on the ideal diode characteristic" type: Real
IdealDiode3.s:VARIABLE(start = 0.0 unit = "1" protected = true ) "Auxiliary variable for actual position on the ideal diode characteristic" type: Real
Iteration variables of torn nonlinear equation system:
IdealDiode5.s:VARIABLE(start = 0.0 unit = "1" protected = true ) "Auxiliary variable for actual position on the ideal diode characteristic" type: Real
IdealDiode2.s:VARIABLE(start = 0.0 unit = "1" protected = true ) "Auxiliary variable for actual position on the ideal diode characteristic" type: Real
Iteration variables of torn nonlinear equation system:
IdealDiode1.s:VARIABLE(start = 0.0 unit = "1" protected = true ) "Auxiliary variable for actual position on the ideal diode characteristic" type: Real
IdealDiode4.s:VARIABLE(start = 0.0 unit = "1" protected = true ) "Auxiliary variable for actual position on the ideal diode characteristic" type: Real
Iteration variables of torn linear equation system:
SineVoltage1.n.v:VARIABLE(flow=false unit = "V" ) "Potential at the pin" type: Real
[3] 11:25:25 Symbolic Notification
Model statistics after passing the back-end for initialization:
* Number of independent subsystems: 2
* Number of states: 0 ()
* Number of discrete variables: 6 (IdealDiode1.off,IdealDiode2.off,IdealDiode3.off,IdealDiode4.off,IdealDiode5.off,IdealDiode6.off)
* Number of discrete states: 0 ()
* Top-level inputs: 0
[4] 11:25:25 Symbolic Notification
Strong component statistics for initialization (33):
* Single equations (assignments): 29
* Array equations: 0
* Algorithm blocks: 0
* Record equations: 0
* When equations: 0
* If-equations: 0
* Equation systems (linear and non-linear blocks): 0
* Torn equation systems: 4
* Mixed (continuous/discrete) equation systems: 0
[5] 11:25:25 Symbolic Notification
Model statistics after passing the back-end for simulation:
* Number of independent subsystems: 1
* Number of states: 4 (Inductor2.i,Inductor3.i,Capacitor1.v,Capacitor2.v)
* Number of discrete variables: 6 (IdealDiode1.off,IdealDiode2.off,IdealDiode3.off,IdealDiode4.off,IdealDiode5.off,IdealDiode6.off)
* Number of discrete states: 0 ()
* Top-level inputs: 0
[6] 11:25:25 Symbolic Notification
Strong component statistics for simulation (28):
* Single equations (assignments): 24
* Array equations: 0
* Algorithm blocks: 0
* Record equations: 0
* When equations: 0
* If-equations: 0
* Equation systems (linear and non-linear blocks): 0
* Torn equation systems: 4
* Mixed (continuous/discrete) equation systems: 0
[7] 11:25:25 Symbolic Notification
Torn system details for strict tearing set:
* Linear torn systems: 1 {(1,100.0%) 9}
* Non-linear torn systems: 3 {2 7,2 7,2 7}
[8] 11:25:25 Translation Notification
List of all iteration variables (DAE kind: simulation)
Iteration variables of torn nonlinear equation system:
IdealDiode2.s:VARIABLE(start = 0.0 unit = "1" protected = true ) "Auxiliary variable for actual position on the ideal diode characteristic" type: Real
IdealDiode5.s:VARIABLE(start = 0.0 unit = "1" protected = true ) "Auxiliary variable for actual position on the ideal diode characteristic" type: Real
Iteration variables of torn nonlinear equation system:
IdealDiode6.s:VARIABLE(start = 0.0 unit = "1" protected = true ) "Auxiliary variable for actual position on the ideal diode characteristic" type: Real
IdealDiode3.s:VARIABLE(start = 0.0 unit = "1" protected = true ) "Auxiliary variable for actual position on the ideal diode characteristic" type: Real
Iteration variables of torn nonlinear equation system:
IdealDiode1.s:VARIABLE(start = 0.0 unit = "1" protected = true ) "Auxiliary variable for actual position on the ideal diode characteristic" type: Real
IdealDiode4.s:VARIABLE(start = 0.0 unit = "1" protected = true ) "Auxiliary variable for actual position on the ideal diode characteristic" type: Real
Iteration variables of torn linear equation system:
SineVoltage1.n.v:VARIABLE(flow=false unit = "V" ) "Potential at the pin" type: Real
Under [2] you can see the iteration variables that need to have start values. In [3] you can see the discrete variables that either need to have start values or be explicitly defined in the system (e.g. if you use a when condition to switch them they need to have start values. Boolean default: false). In [5] you can see the chosen states, they need start values and need to be fixed (you can also instead provide initial equations for their derivatives e.g. steady state initialization).
P2.2 Start values can be used as initial values for iteration variables (necessary for newton solver). For states they won't always be used unless you set fixed=true, fixed=false is default. Initial equations are always part of the initial system. For calculating a parameter the same rules apply whether you use that parameter as a start value or in an initial equation.
P2.3 Unfortunately i am not quite sure what you mean by inverse problem. As i mentioned you could provide initial equations for the state derivatives instead of the states and that would also work (maybe that's what you are implying here?). fixed=false is default, the option to state this is to revoke fixed=true decisions made on lower levels or in used libraries.
Sorry this is quite verbose, i hope i could help!