I tried to find zero-crossings of a function using  --daeMode, but the result was not was I expected. In "ode-Mode" everything is fine.

loadModel(Modelica,{"4.0.0"});



loadString("

model ExampleDaeMode 

  Real x;

  Boolean GREATER;

equation

  x= 1.5* sin(time);

  GREATER = x>0.0;

  when edge(GREATER) then

    Modelica.Utilities.Streams.print (\"time = \" + String(time),\"./mytestfile.txt\");

  end when;

end ExampleDaeMode;

"); getErrorString();



setCommandLineOptions("--daeMode");

simulate (ExampleDaeMode, startTime = -0.1, stopTime = 10.0, stepSize=0.01, tolerance=1e-6 , simflags="-lv=LOG_STATS");

getErrorString();

plot ({GREATER,x});

Build.mos

The same problem when removing the "when - block"

In ExampleDaeMode_16dae.c  a function ExampleDaeMode_evaluateDAEResiduals  was defined, but never called.

Does anyone have similar experience with --daeMode ??

Best Johann

OMCompiler v1.19.0-dev.30+gbc38d8eead
platform Linux64

fixed with commit 'fix issues with OpenSuse'  from Jun 30

no issue with: OMCompiler v1.19.0-dev.30+gbc38d8eead

Thx

Error message received:

 

In file included from ffi_omc.c:36:

./../../3rdParty/libffi/install/include/ffi.h:58:10: error: 'ffitarget.h' file

      not found with >angled> include; use "quotes" instead

#include >ffitarget.h>

         ^~~~~~~~~~~~~

         "ffitarget.h"

After changing from system #include to local #include it's OK.

modification in ffi.h

58:  #include "ffitarget.h"

OMCompiler v1.18.0-dev.297+gb7d5bf71f1
Platform LINUX 64
clang version 7.0.1
on my system installed version of libffi: 3.2.1 (only lib, no includes)


BR / Johann

before opening a ticket:
I'm using elements from Modelica.ComplexBlocks e.g. block feedback

When using the original implementation

block Feedback

...

equation

    y = (if useConjugateInput1 then Modelica.ComplexMath.conj(u1) else u1) -     (if useConjugateInput2 then Modelica.ComplexMath.conj(u2) else u2);

I received a warning and initialization fails.

Warning: The initial conditions are over specified. The following 2 initial equations are redundant, so they are removed from the initialization sytem:
         $DER.GridConverter.Icontroller.PId.x = 0.0
         $DER.GridConverter.Icontroller.PIq.x = 0.0.

After modification of feedback block:

block MyFeedback

...

equation

//     y = (if useConjugateInput1 then Modelica.ComplexMath.conj(u1) else u1) -     (if useConjugateInput2 then Modelica.ComplexMath.conj(u2) else u2);

   y = u1 - u2;

everything is fine.

unfortunately I was not able to create a simple model to demonstrate this behavior.

As my temporary workaround a removed all "useConjugateInput" from all ComplexBlocks elements I used.

omc: OMCompiler v1.18.0-dev.188+gb64a64f15a
MSL: 3.2.3
OS: Linux 64

Thx & BR

Hi,

Once again.
With your suggested speed control setup, the speed cannot exceed the setpoint of 1500 RPM.
If the actual speed is equal to the setpoint, the output of the controller (with proportional characteristic) is zero. That means your motor is not producing any torque. Therefore, the actual speed CANNOT be higher than the reference value.

==> MODELICA implementation if the problem is correct.
==> OM works perfect.

When your are expecting overshooting of the speed, change the structure of your controller. (e.g. from P to PI). But be carefully with the limiter you installed (to avoid wind-up problems).

Je vous souhaite beaucoup de succès
BR: your google translator

What result do you expect?
You have used a speed controller with a P-characteristic. The simulation result is OK.

BR

After removing a 3 years old SuiteSparse installation (libs&includes) from /usr/local/lib/ and new compilation of omc everything is fine.
Thx

I will prepare a simple example. In the meantime I checked deaMode with other models - the same problem.
Is it OK to work with  OMCompiler v1.17.0-dev.224+g4c291412fa ??
with v1.16.0  I had no problems  with --deaMode  and sparse solver
with  v1.16.1  I received an error during compilation so I switched to v1.17.0-dev....

BR Johann

OMCompiler v1.17.0-dev.224+g4c291412fa  on x86_64 x86_64 x86_64 GNU/Linux

simulation option:  -idaLS=klu  -lv LOG_SOLVER

Limited backtrace at point of segmentation fault

/lib64/libpthread.so.0(+0x132d0)[0x7f3d054022d0]

/usr/local/bin/../lib/x86_64-linux-gnu/omc/libsundials_sunlinsolklu.so.3(SUNLinSolSolve_KLU+0x92)[0x7f3d03b70f52]

/usr/local/bin/../lib/x86_64-linux-gnu/omc/libsundials_idas.so.4(idaLsSolve+0x1b7)[0x7f3d02860e17]

/usr/local/bin/../lib/x86_64-linux-gnu/omc/libsundials_idas.so.4(IDACalcIC+0x6b3)[0x7f3d0285df23]

/usr/local/bin/../lib/x86_64-linux-gnu/omc/libSimulationRuntimeC.so(ida_event_update+0x2b1)[0x7f3d08404021]

/usr/local/bin/../lib/x86_64-linux-gnu/omc/libSimulationRuntimeC.so(updateDiscreteSystem+0x89)[0x7f3d083ee969]

/usr/local/bin/../lib/x86_64-linux-gnu/omc/libSimulationRuntimeC.so(initialization+0x40b)[0x7f3d0841886b]

/usr/local/bin/../lib/x86_64-linux-gnu/omc/libSimulationRuntimeC.so(initializeModel+0xde)[0x7f3d083f9cce]

/usr/local/bin/../lib/x86_64-linux-gnu/omc/libSimulationRuntimeC.so(solver_main+0x140)[0x7f3d083fae30]

/usr/local/bin/../lib/x86_64-linux-gnu/omc/libSimulationRuntimeC.so(+0xd3e41)[0x7f3d08441e41]

/usr/local/bin/../lib/x86_64-linux-gnu/omc/libSimulationRuntimeC.so(startNonInteractiveSimulation+0xd1c)[0x7f3d08440f5c]

/usr/local/bin/../lib/x86_64-linux-gnu/omc/libSimulationRuntimeC.so(_main_SimulationRuntime+0x72)[0x7f3d08443fb2]

./DFIM10(main+0x19b)[0x416ad1]

/lib64/libc.so.6(__libc_start_main+0xea)[0x7f3d0505834a]

./DFIM10(_start+0x2a)[0x41490a]

LOG_SOLVER        | info    | NO override given on the command line.

LOG_SOLVER        | info    | numberOfIntervals = 10500

LOG_SOLVER        | info    | Allocated simulation result data storage for method 'mat' and file='DFIM10_res.mat'

LOG_SOLVER        | info    | recognized solver: ida

LOG_SOLVER        | info    | Initializing IDA DAE Solver

LOG_SOLVER        | info    | ## IDA ## Initializing solver of size 111 in DAE mode.

|                 | |       | | The relative tolerance is 1e-08. Following absolute tolerances are used for the states: 

|                 | |       | | IDA uses internal root finding method YES

|                 | |       | | Maximum integration order 5

|                 | |       | | use equidistant time grid YES

|                 | |       | | IDA linear solver method selected ida use sparse direct solver KLU. (default)

|                 | |       | | Jacobian is calculated by "Colored numerical Jacobian, which is default for dassl and ida. With option -idaLS=klu a sparse matrix is used."

|                 | |       | | initial step size is set automatically.

LOG_SOLVER        | info    | ##IDA## do event update at -0.5

LOG_SOLVER        | info    | ##IDA## corrected step-size at 2.22044604925031e-16

LOG_SOLVER        | info    | #### IDA error message #####

|                 | |       | |  -> error code -22

|                 | |       | |  -> module IDAS

|                 | |       | |  -> function IDACalcIC

|                 | |       | |  Message: tout1 too close to t0 to attempt initial condition calculation.

LOG_SOLVER        | info    | ##IDA## IDACalcIC run status -22.

|                 | |       | Iterations : 0

LOG_SOLVER        | info    | ##IDA## first event iteration failed. Start next try without line search!

simulation option  -idaLS=dense  -lv LOG_SOLVER
results as expected

LOG_SOLVER        | info    | NO override given on the command line.

LOG_SOLVER        | info    | numberOfIntervals = 10500

LOG_SOLVER        | info    | Allocated simulation result data storage for method 'mat' and file='DFIM10_res.mat'

LOG_SOLVER        | info    | recognized solver: ida

LOG_SOLVER        | info    | Initializing IDA DAE Solver

LOG_SOLVER        | info    | ## IDA ## Initializing solver of size 111 in DAE mode.

|                 | |       | | The relative tolerance is 1e-08. Following absolute tolerances are used for the states: 

|                 | |       | | IDA uses internal root finding method YES

|                 | |       | | Maximum integration order 5

|                 | |       | | use equidistant time grid YES

|                 | |       | | IDA linear solver method selected ida internal dense method.

|                 | |       | | Jacobian is calculated by "Colored numerical Jacobian, which is default for dassl and ida. With option -idaLS=klu a sparse matrix is used."

|                 | |       | | initial step size is set automatically.

LOG_SOLVER        | info    | ##IDA## do event update at -0.5

LOG_SOLVER        | info    | ##IDA## corrected step-size at 2.22044604925031e-16

LOG_SOLVER        | info    | #### IDA error message #####

|                 | |       | |  -> error code -22

|                 | |       | |  -> module IDAS

|                 | |       | |  -> function IDACalcIC

|                 | |       | |  Message: tout1 too close to t0 to attempt initial condition calculation.

LOG_SOLVER        | info    | ##IDA## IDACalcIC run status -22.

|                 | |       | Iterations : 0

LOG_SOLVER        | info    | ##IDA## first event iteration failed. Start next try without line search!

LOG_SOLVER        | info    | ##IDA## IDACalcIC run status 0.

|                 | |       | Iterations : 0

LOG_SUCCESS       | info    | The initialization finished successfully without homotopy method.

LOG_SOLVER        | info    | Wrote parameters to the file after initialization (for output formats that support this)

LOG_SOLVER        | info    | Start numerical solver from -0.5 to 10

LOG_SOLVER        | info    | Sparse structure of DAE sparse pattern [size: 111x111]

|                 | |       | | 393 nonzero elements

|                 | |       | | Transposed sparse structure (rows: states)

with version v1.16.0  sparse direct solver was working.
BR / Johann

Consider this as a proposal


In the present “OMCompiler v1.16.0”  the workflow for linearization as follows:

omc --generateSymbolicLinearization  --linearizationDumpLanguage=modelica  buildMODEL.mos

./MODEL -l 0.0   #then a “linearized_model.mo” is created

with this model I can work now, using OM.

my approach: Separate code from data
In some cases it can be useful to run linearization with different sets of parameters. The dataset for ABCD presently is available as MODELICA Code. This makes parameter-studies less efficient. I'm using the ABCD matrices in post-processing routines for eigenvalue decomposition, transfer-function, participation-factors, … preferred in python language.

I also tried to use  --linearizationDumpLanguage=python  : the generated python code  is not correct.

A workaround attached.
I added some code in “linearize.cpp” to create a MAT4 file with ABCD,x0.  The names for states/input/output are found in MODEL_init.xml


Thanks for your comments.
BR / Johann

Hi,

1) parameters should be inside the model (at the moment parameters are in the package)

2) I've no idea about the technical problem behind your model. But with a Coupling Factor of 99% the system is NOT stable. I changed

parameter Real unite = 0.40  "e.g."; 

and it was OK.

best regards
Johann

homotopy function / -override

best wishes for the NEW 2020 !!

I tried Ticket5696.mos  -> OK
BUT: in my model the  homotopy  function is used, and then the parameter values are not "overwritten"
This  I can solve by using the "-noHomotopyOnFirstTry"  option.  Then everything is fine.

The same observation when changing parameter values direct in Model_init.xml
* OMCompiler v1.16.0-dev.99+g1a4ceb3d0      git clone from 2019-12-27
* LINUX64   platform

thx / Johann

Hi,

in model PumpChamber  there are a lot of wrong connect(.. statements.  Remove all connects in Text View mode, reconnect and try again.

BR / johann

dear all,

obviously there is a problem with regex and GCC4.8.   
so  >> OMSimulator  --version  when using GCC4.8.5 on LINUX platform x86_64  crashed.

I tried to replace  std::regex   by   boost::regex in Options.cpp, Options.h, ComRef.cpp and FMUWrapper.cpp
included  -lboost_regex and everything  is fine (with some additional modifications in cmake)

Unfortunately I'm not an expert in C programming, so I want to ask for experience of any other user?

thanks in advance / johann

SOLVED !

I used a package named "battery"  and an element name "battery".

    battery.Converter battery annotation(Placement(.....

This results in an "endless loop"  and a stack overflow. After renaming the element everything works is fine now.
I'm not sure if my code was compliant with MODELICA standard. JM issued no warning.

BR   Johann

dear all,

I tried to run a complex model and received a lot of error messages (see below).
The model runs without any problems in JModelica

my system:
OMCompiler v1.13.0-dev.456+g74ad9da44
uname -a
Linux notebook.all 4.4.114-42-default #1 SMP Tue Feb 6 10:58:10 UTC 2018 (b6ee9ae) x86_64 x86_64 x86_64 GNU/Linux

Any ideas how to solve the problem?

Thanks in advance
Johann

**************************
"Error: Stack overflow occurred while evaluating simulate(DTe7G, startTime = -1.0, stopTime = 20, stepSize = 1, tolerance = 1e-8, simflags = "-noEquidistantTimeGrid  -lv=LOG_STATS"):
[bt] #1 /usr/local/bin/../lib/x86_64-linux-gnu/omc/libOpenModelicaRuntimeC.so(mmc_setStacktraceMessages_threadData)
[bt] #2 /usr/local/bin/../lib/x86_64-linux-gnu/omc/libOpenModelicaRuntimeC.so(mmc_do_stackoverflow)
[bt] #3 /usr/local/bin/../lib/x86_64-linux-gnu/omc/libOpenModelicaCompiler.so(NFSCodeEnv.EnvTree.get)
[bt] #4 /usr/local/bin/../lib/x86_64-linux-gnu/omc/libOpenModelicaCompiler.so(NFSCodeLookup.lookupInLocalScope)
[bt] #5 /usr/local/bin/../lib/x86_64-linux-gnu/omc/libOpenModelicaCompiler.so(NFSCodeLookup.lookupSimpleName2)
[bt] #6 /usr/local/bin/../lib/x86_64-linux-gnu/omc/libOpenModelicaCompiler.so(NFSCodeLookup.lookupSimpleName)
[bt] #7 /usr/local/bin/../lib/x86_64-linux-gnu/omc/libOpenModelicaCompiler.so(NFSCodeLookup.lookupName)
[bt] #8 /usr/local/bin/../lib/x86_64-linux-gnu/omc/libOpenModelicaCompiler.so(NFSCodeLookup.lookupNameSilent)
[bt] #9 /usr/local/bin/../lib/x86_64-linux-gnu/omc/libOpenModelicaCompiler.so(NFSCodeDependency.lookupClass2)
[bt] #10 /usr/local/bin/../lib/x86_64-linux-gnu/omc/libOpenModelicaCompiler.so(NFSCodeDependency.lookupClass)
...
...
[bt] #1023 /usr/local/bin/../lib/x86_64-linux-gnu/omc/libOpenModelicaCompiler.so(NFSCodeDependency.lookupClass2)
[bt] #1024 /usr/local/bin/../lib/x86_64-linux-gnu/omc/libOpenModelicaCompiler.so(NFSCodeDependency.lookupClass)
[bt] #1025 [...]
"
false
***********************************
report from fmuCheck.linux64  from the FMU generated with JModelica
...
[INFO][FMUCHK] FMU kind: ModelExchange and CoSimulation
[INFO][FMUCHK] The FMU contains:
219 constants
484 parameters
14 discrete variables
2252 continuous variables
0 inputs
0 outputs
2485 local variables
0 independent variables
557 calculated parameters
3336 real variables
46 integer variables
24 enumeration variables
89 boolean variables
31 string variables
***********************************