Hi,

if you need some information about dynamic state selection you could have a look at [https://www.modelica.org/events/workshop2000/proceedings/old/Mattsson.pdf][/url]

Maybe the solver uses for the calculation of the next step also cached values from the time before the last state switch. This could be the reason for the problem.

Hi antoinem,

I tried to reproduce your problem and it was possible for me. I used rev16563 from jul-09-13.

Can you please give some information about your version of omc.

Thanks.

Hi,

as far I remember you need three thinks to compile the msvc targets if you compile omc on your own and one think if you use the installer. If you use the installer the visual studio compiler 9 is needed. If you compile omc on your own you need OMDev, CMake and visual studio 9.

Maybe the nmake file which is used to compile the simulator is not yet ready to use external libraries. But this should be easy to find out by checking the file.

Hi Jim,

the actuall state selection implementation is based on

Mattsson, Sven Erik and Söderlind, Gustaf: Index reduction in differential-algebraic equations using dummy derivatives, SIAM J. Sci. Comput., url = http://dx.doi.org/10.1137/0914043.

Based on means the implementation consider some Modelica Specific Issues like StateSelection and is not yet finally. The one think that is missising is a complete check for singular systems. 
A description of the implememented algorithm is not yet availible.

Which one of the jacobian do you mean. There is a jacobian for the linearized system, one for the nonilinear sytems, one for pivoting for dynamic state selection?

Jens

Hi,

the index of the error message is nothing else than the equation number. If you want do know the differential index of the system you could use +d=bltdump with the PFPlusExt Matching Algoritm and cound how often the system equations are diffentiated. (search for "Reduce Index").


setMatchingAlgorithm("PFPlusExt");
setIndexReductionMethod("dynamicStateSelection");

Now OMC reports an error message in case of singulare systems. (r14028)

Hi,

you have to replace one of the revolutes with a RevolutePlanarLoopConstraint. Without that your model is structuraly singulare because is is overconstrained.

Cheers

Jens

fixed in r13681

works since r13361

Hi,

I added in the past CMake files. If you update this files (trunc/SimulationRuntime/c) it should be easy to get the project files for vs but I am not sure if it is possible to compile the generated files with vs c++ 6.0. You may have to change a few things (empty arrays for example)

Frenkel TUD

Hi,

you can send the model to the mailing list. But before you do this please try the latest nightly build and have a look if the error Message is still there. Normally it tells you which variable (exp) is zero. If the information is not enough please have a look in the genearated code at the line reported in the error Messages. There you see the full equation solved for a variable. (Yes the code is not nice but readable)
With this information you may get your model simulating.

Hi,

can you give more information about what you did to produce the error?

Hi,

use +d=dumpindxdae, this dumps the system right before code generation. There you see first all time depend variables then all time depend equations, then all time independent variables, then all alias variables. In case of a model with independent subsystems the time depend variables and equations dumped for each system before the time independent variables.

Another option is to use +d=backenddaeinfo. There you see the number of time depend variables and equations and number of the linear/nonlinear subsystem.
If you use additional the stateselection flag (+d=backenddaeinfo,stateselection) the selected states also dumped.

fixed in revison 12049

-fixed in revision 12046

Hi,

it looks like a error in the handling of algorithms in case of arrays. See dumpdaelow report below. I assume the detection of output and input variables did not work for array symbols.

dumpdaelow:
Variables (11)
=========
1:  arrayRec.T_degC_liq_port[5]:VARIABLE() .loopIndexTester, .Arrays, .Real type: Real [5] indx = -1
2:  arrayRec.T_degC_liq_port[4]:VARIABLE() .loopIndexTester, .Arrays, .Real type: Real [5] indx = -1
3:  arrayRec.T_degC_liq_port[3]:VARIABLE() .loopIndexTester, .Arrays, .Real type: Real [5] indx = -1
4:  arrayRec.T_degC_liq_port[2]:VARIABLE() .loopIndexTester, .Arrays, .Real type: Real [5] indx = -1
5:  arrayRec.T_degC_liq_port[1]:VARIABLE() .loopIndexTester, .Arrays, .Real type: Real [5] indx = -1
6:  arrayRec.T_liq_port[5]:VARIABLE() .loopIndexTester, .Arrays, .Real type: Real [5] indx = -1
7:  arrayRec.T_liq_port[4]:VARIABLE() .loopIndexTester, .Arrays, .Real type: Real [5] indx = -1
8:  arrayRec.T_liq_port[3]:VARIABLE() .loopIndexTester, .Arrays, .Real type: Real [5] indx = -1
9:  arrayRec.T_liq_port[2]:VARIABLE() .loopIndexTester, .Arrays, .Real type: Real [5] indx = -1
10:  arrayRec.T_liq_port[1]:VARIABLE() .loopIndexTester, .Arrays, .Real type: Real [5] indx = -1
11:  $dummy:STATE(fixed = true )  type: Real  indx = -1


Equations (6)
=========
1 : Algorithm no: 0 for inputs: (arrayRec.T_liq_port[5], arrayRec.T_liq_port[4], arrayRec.T_liq_port[3], arrayRec.T_liq_port[2], arrayRec.T_liq_port[1]) => outputs: (arrayRec.T_degC_liq_port[5], arrayRec.T_degC_liq_port[4], arrayRec.T_degC_liq_port[3], arrayRec.T_degC_liq_port[2], arrayRec.T_degC_liq_port[1])
2 : Algorithm no: 0 for inputs: (arrayRec.T_liq_port[5], arrayRec.T_liq_port[4], arrayRec.T_liq_port[3], arrayRec.T_liq_port[2], arrayRec.T_liq_port[1]) => outputs: (arrayRec.T_degC_liq_port[5], arrayRec.T_degC_liq_port[4], arrayRec.T_degC_liq_port[3], arrayRec.T_degC_liq_port[2], arrayRec.T_degC_liq_port[1])
3 : Algorithm no: 0 for inputs: (arrayRec.T_liq_port[5], arrayRec.T_liq_port[4], arrayRec.T_liq_port[3], arrayRec.T_liq_port[2], arrayRec.T_liq_port[1]) => outputs: (arrayRec.T_degC_liq_port[5], arrayRec.T_degC_liq_port[4], arrayRec.T_degC_liq_port[3], arrayRec.T_degC_liq_port[2], arrayRec.T_degC_liq_port[1])
4 : Algorithm no: 0 for inputs: (arrayRec.T_liq_port[5], arrayRec.T_liq_port[4], arrayRec.T_liq_port[3], arrayRec.T_liq_port[2], arrayRec.T_liq_port[1]) => outputs: (arrayRec.T_degC_liq_port[5], arrayRec.T_degC_liq_port[4], arrayRec.T_degC_liq_port[3], arrayRec.T_degC_liq_port[2], arrayRec.T_degC_liq_port[1])
5 : Algorithm no: 0 for inputs: (arrayRec.T_liq_port[5], arrayRec.T_liq_port[4], arrayRec.T_liq_port[3], arrayRec.T_liq_port[2], arrayRec.T_liq_port[1]) => outputs: (arrayRec.T_degC_liq_port[5], arrayRec.T_degC_liq_port[4], arrayRec.T_degC_liq_port[3], arrayRec.T_degC_liq_port[2], arrayRec.T_degC_liq_port[1])
6 : der($dummy) = 0.0

Hi,

it looks like a error in the frontend:

class InOut
  Real m.x[1];
  Real m.y[1];
equation
  m.eq1.x[1] + m.eq1.y[1] = 1.0;
  m.eq2.x[1] ^ 2.0 + m.eq2.y[1] ^ 2.0 = 1.0;
end InOut;

because m.eq1.x, m.eq1.y, m.eq2.x and m.eq2.y are unkown variables.

Hi,

unfortunately the tearing implementation is not yet finished.

If you want to do more symbolic simplification than in default case you could use additional optimization modules  via the flags
+preOptModules=""
or/and
+postOptModules=""

for the preOptModules the default case is "removeFinalParameters,removeEqualFunctionCalls,partitionIndependentBlocks,expandDerOperator, removeSimpleEquationsFast"

Additionally you cold use for example removeProtectedParameters. This module replace all protected parameters with there value.
If you want to add, it simply write it in an appropriate place in the list. Node the order of the list is the same as the compiler performs the modules. A good place for  removeProtectedParameters is before  removeSimpleEquationsFast. This is because replacing protected parameters with there value will result in more simple equations.

(Node, there are also script functions to set the flags)

You could check the order of the modules by adding the flag +d=execstat

More Ideas about simplification modules are very welcome.

Jens

Fixed with revision 10629

now result1=result2=result3=-1

result1 = value1
result2 = -1.0
result3 = -1.0

value3 is replace with -1 because it is a bound parameter and the bound expression is final.

Why is the $DER term problematic for you? This is just a silly prefix for a variable.

By the way +d=bltdump also works with .mos files and if you use +d=dumpindxdae you get the equations after all optimisation phases.

Hi,

I am not really sure if I got the question, but from a theoretical point of view this is possible. It depends on the model. Do you have an example?

Hi,

the significance of  a "DUMMY_DER" variable is that this variable was used inside a "der" function or market as state (for example stateSelect=StateSelect.prefer). During the index reduction algorithm it was found that this variable is not a state in the meaning of an independent variable (by a constrained equation) and this variable kind was changed from "STATE" to "DUMMY_STATE". (same for derivatives.)

If a optimized code of a linear circuit will contain $DER depends on the used library. If the library manage to use a minimal state form no $Der will occur, but normally this is not practical for  the design of the library.

For further information please have a look at https://www.modelica.org/events/worksho … ttsson.pdf for example.