Hi Eric,

Try using the CVODES solver, it seems to avoid the "No unique solution for solving linear equation..." error. However, that alone wont simply solve your state selection problem.

In the two port component, the derivative of T occurs in the following equation:

flowPort_a.H_flow + flowPort_b.H_flow + Q_flow = m * medium.cv * der(T);

So if any state beside T is to be chosen using stateSelect=always, it needs to be able to use that to solve der(T). V_flow is not such a variable, possibly due to the presence of the special "semiLinear" function in the component. I was however able to trick it to add an additional state, beside T by using your original approach:

Change

V_flow = flowPort_a.m_flow / medium.rho;

To

der(V_flow) = der(flowPort_a.m_flow) / medium.rho;

in the TwoPort component. In your model, you will only be able to set 2 out of 3 pipes to use V_flow as a state, since the third variable can be directly calculated from the other 2. With 3 states, the solution would be over determined. You can for example have:

PipelineSection pipelineSection(T_a.fixed = false, T_b.fixed = false, T0fixed = true, V_flow(stateSelect = StateSelect.always));
PipelineSection pipelineSection1(T_a.fixed = false, T_b.fixed = false, T0fixed = true, V_flow(stateSelect = StateSelect.always));
PipelineSection pipelineSection2(T_a.fixed = false, T_b.fixed = false, T0fixed = true);

Try the attached model and see if it works for your purposes.

This could be considered a pretty dirty fix, so there could be a better way. I would have to think about it a bit more.

Attachments:

Hi Eric,

Does this error occur at the beginning of the simulation? That could indicate that it is an initialization problem, where it fails to find a consistent set of initial values due to the non-linearity. The solver will prefer to use the specified initial values of states over other variables, so now with a new set of states, the initial conditions could be badly formed. You can force the solver to use a certain initial condition, even if the variable is not a state using the fixed=true keyword:

model TestStates
  Real x(start = 1);
  parameter Real k = 1;
  output Real y(start = 0,stateSelect = StateSelect.always);
equation
  x * k = y;
  der(x) = 1;
end TestStates;

Will initialize y to 0.

model TestStates
  Real x(start = 1,fixed=true);
  parameter Real k = 1;
  output Real y(start = 0,stateSelect = StateSelect.always);
equation
  x * k = y;
  der(x) = 1;
end TestStates;

Will initialize y to k*x.

To see how states were selected and initialized before and after you force v to become a state, you can go to Tools > Options > Simulation Center > Debug Output and select "Normal" and mark "Initialization" from Simulation Center.

I see you described the difference between "prefer" and "always". However, both are returning the same error in Simulation Center

Hi Eric!

The only variables that can be used for sensitivity analysis are those that the solver uses as states. You can influence how the solver selects states with the stateSelect attribute.

For example, in the following model:

model TestStates
  Real x(start = 1);
  parameter Real k=1;
  output Real y(stateSelect=StateSelect.always);
equation
  x*k=y;
  der(x)=1;
end TestStates;

y is forced to be used as a a state.

So the following code will bring up y's sensitivity to k:`

WSMPlot[WSMSimulateSensitivity[
  "TestStates", {0, 10}, {"k"}], {{"y", "k", 0.1}}]

The stateSelect attribute can take on the following values: StateSelect.never, StateSelect.avoid, StateSelect.default, StateSelect.prefer, StateSelect.always.

The difference between prefer and always is that in both cases the solver will prefer choosing the variable as a state, but if StateSelect.always is set, it will throw an error if it is unable to use the variable as a state. The same, but inverse is true for avoid and never.