Hej! I am not sure if I understand your application. Do you want to restart the simulation with a given set of start values? The short answer is, there is no workaround for get/setFMUstate. However, if your FMUs don't use internal states, external objects, etc it might actually work. However, I don't recommend it, because i can easily result in wrong output which isn't trivial to catch.

I will see if we can put some resources on this issue to finally support this functionality in OpenModelica.

Thanks for this bug report. We collect all OMSimulator related issues actually on github: https://github.com/OpenModelica/OMSimulator/issues Feel free to post it there as well.

Can you please describe more precisely what you are looking for?

Google provides plenty of answers, e.g.: https://stackoverflow.com/questions/249 … ing-python

If OpenModelica is introducing initial equations in addition to those that are defined in the model, then the following message is displayed:

Warning: The initial conditions are not fully specified. For more information set -d=initialization. In OMEdit Tools->Options->Simulation->OMCFlags, in OMNotebook call setCommandLineOptions("-d=initialization").

What is the issue? It seems to work for me.

It seems that the dynamic model contains too much initial equations. Maybe this is because of index reduction. You should try to define less initial equations because otherwise OpenModelica will try to remove some by itself which might lead to strange results.

It simulates with the following initial equations, but I don’t know if this is what you want.

initial equation

  for i in 1:N_Trays loop

    der(M[i]*x[i,:].*hl[i,:]) = {0,0};

  end for;

Can you share the model?

Why is the initialization problem over-determined? Did you set `fixed=true` while setting the initial guess?

Thanks, now I see the issue. I will bring it up in the weekly developer meeting.

Can you use external objects for this?

Where is `Thermodynamic_Functions` definied?

I get the following error message:

[Functions.mo:19:5-19:82:writable] Error: Class Thermodynamic_Functions.HV not found in scope Functions.HLiqId (looking for a function or record).

Error: Error occurred while flattening model distillation

This looks like a bug in OpenModelica. Can you share the model? The error message doesn’t provide enough information to fix it. 

There are two flags for the simulation executable: iif and iit (see here for more information https://www.openmodelica.org/doc/OpenMo … mflag-iif)
Additionally, you have to disable the ordinary initialization with –iim=none.

// run simulation from time=0 until time=0.25 and save results to xxx_res.mat

simulate(foo, stopTime=0.25, fileNamePrefix="xxx"); getErrorString();



// run simulation from time=0.25 until time=1.0 and use previous results as initial solution

simulate(foo, startTime=0.25, simflags="-iim=none -iif=xxx_res.mat -iit=0.25"); getErrorString();

It is possible to initialize a simulation based on previous simulation results. Would that be helpful?

Unfortunately, we introduced some bugs into the module findZeroCrossings since 1.9.3. All known bugs are already fixed. Can you please check the latest nightly build? Otherwise we would need more information to investigate the issue.

I can confirm that the issue is connected to function inlining.
One can disable inlining of functions as a workaround using the following omc-flag:

-d=-inlineFunctions

.

There are some cases where the equation ordering may have an impact on the simulation:

• The ordering of iteration variables can affect the solution process of nonlinear systems.


• The ordering of equations/variables may affect tearing heuristics.


• The ordering of equations may affect the initialization if the initial conditions are not fully specified, i.e. under-determined or over-determined.


• Probably there are more such cases…

Yes, it did. It used the same equation system as for the simulation (including tearing).

Yes, we do collaborate with Federico Bergero in order to integrate their solver suite into OpenModelica. It is also planned to add a simcode target that directly exports code for their runtime system.
However, resources are quite limited and things don’t progress as fast as they should …

It would be good to join forces and work together on the existing qss implementation. Please feel free to comment on the current implementation or do pull requests in order to push modifications/extensions to the current approach.

Maybe you are looking for

.OpenModelica.Scripting.reopenStandardStream

. Therewith, you can redirect a certain standard stream to a file.

reopenStandardStream

Can you tell us a bit more about your solver? Did you implement it yourself? Or is it an adaption of an existing solver package? Is it a first-order or higher-order approach? ...
There are already some (experimental) qss implementations available/in development. So maybe it is possible to share some stuff in order to avoid too much redundant work.

I think you are right and it should trigger a warning or even an error message. Can you please open a ticket for this in the trac system?

Can you provide something, e.g. the model itself, to reproduce the issue?

Nominal values are used in different ways in OpenModelica. For example they are used to scale iteration variables for systems of equations. There are also some debug-flags that scale certain variables within the symbolic transformation (see +d=addScaledVars and +d=addScaledVarsInput,
omcflag-debug).

No, that is not possible. startTime/stopTime/numberOfIntervals only exist inside experiment annotation.

I will group the examples by issue and open tickets for them. We will see how fast we get full support for the OpenHydaulics library.

The OpenHydraulics library isn't supported well by OpenModelica yet: https://test.openmodelica.org/libraries … rsive.html

Sorry, I cannot give you any hint. Can you try to isolate the failing linear system and set up a small model that can be used as public test case?

Well, I did quite a lot of changes to the backend in that specific commit. Therefore, it is hard to pinpoint something.
However, we could start with the error message ;-). You wrote that your model failed during simulation, right? Is there any error message or something? Did you run the simulation from command line or using OMEdit?

Can you provide your model as test case to reproduce the issue?

simulate

simulates a modelica model by generating c code, build it and run the simulation executable. The only required argument is the className, while all others have some default values. simulate(className, [startTime], [stopTime], [numberOfIntervals], [tolerance], [method], [fileNamePrefix], [options], [outputFormat], [variableFilter], [cflags], [simflags]) Example command: simulate(A);

function simulate

  input TypeName className "the class that should simulated";

  input Real startTime = "<default>" "the start time of the simulation. <default> = 0.0";

  input Real stopTime = 1.0 "the stop time of the simulation. <default> = 1.0";

  input Real numberOfIntervals = 500 "number of intervals in the result file. <default> = 500";

  input Real tolerance = 1e-6 "tolerance used by the integration method. <default> = 1e-6";

  input String method = "<default>" "integration method used for simulation. <default> = dassl";

  input String fileNamePrefix = "<default>" "fileNamePrefix. <default> = \"\"";

  input String options = "<default>" "options. <default> = \"\"";

  input String outputFormat = "mat" "Format for the result file. <default> = \"mat\"";

  input String variableFilter = ".*" "Filter for variables that should store in result file. <default> = \".*\"";

  input String cflags = "<default>" "cflags. <default> = \"\"";

  input String simflags = "<default>" "simflags. <default> = \"\"";

  output String simulationResults;

end simulate;

see OpenModelicaUsersGuide/scripting_api

Please report bugs here.

And using all the flags form your post, I get the following messages:

<message stream="assert" type="debug" text="Solving non-linear system 3 failed at time=0.

For more information please use -lv LOG_NLS.">

<used index="3" />

</message>

<message stream="assert" type="info" text="simulation terminated by an assertion at initialization" />

I cannot reproduce the crash on Linux. The simulation just terminate with the following message:

Simulation execution failed for model: Problem_4_Fanger

assert            | debug   | Solving non-linear system 3 failed at time=0.

|                 | |       | For more information please use -lv LOG_NLS.

assert            | info    | simulation terminated by an assertion at initialization

All these information is available from the struct tm:
year: tm->tm_year+1900
month: tm->tm_mon
day: tm->tm_mday
hour tm->tm_hour
minute: tm->tm_min
second: tm->tm_sec

If I got you right, you want to get the current time within your Modelica model. That can be done easily using external functions. The following is a brief example that extracts the current hours information:

model TimeTest

  impure function getHours

    output Integer x;

  external "C" x = _getHours() annotation(Include = "#include <stdio.h>

    #include <time.h>

    int _getHours()

    {

      time_t now;

      struct tm *ts;

      

      /* Get the current time */

      now = time(NULL);

      ts = localtime(&now);

      

      return ts->tm_hour;

    }");

  end getHours;



  parameter Integer h = getHours();

end TimeTest;

external c function?

I think that is the expected behavior. If you want to get the stair step signal, you could change the when condition to “time > pre(nextTime)”.
The reason for the behavior is, that a when clauses is only invoked, if the condition changed from false to true. In your model the condition is true from the beginning and therefore the when clause is never invoked.

Did you attached your model? Or can you give some more information about what you are doing? Otherwise it is hard to say what the issue is in your case.

I think your model shouldn’t have passed the front end. So we should probably add a ticket about it anyway.

That is because there is no fixed attribute for string type. See section 4.8.4 in Modelica specification:

4.8.4 String Type

The following is the predefined String type: 

type String // Note: Defined with Modelica syntax although predefined

   StringType value;                    // Accessed without dot-notation

   parameter StringType  quantity    = "";

   parameter StringType start = "";     // Initial value

end String;

Numeric initialization was not able to handle discrete variables properly. Therefore, it was no good idea to trust the generated results. Now, this is completely removed and you should test the symbolic initialization (default configuration) for your models.
As Martin already wrote, you should be able to hint at the intended solution using start values. Therefore, the initialization (test +d=initialization) prints all the variables that are used in iteration processes.
Besides that, using homotopy could help as well. Unfortunately, there is only a poor implementation of it right now, but we will release a completely new implementation later on this year.

hideishi wrote:

Thanks.
Do you mean that solvers always choose when and how they iterate automatically so users can not set when and how they iterate ?

This is true for solvers with a (more or less advanced) step size control as our Default one DASSL. There are also solver with a fix step size available (e.g. radau1, radau3, radau5, lobatto2, lobatto4 or lobatto6).

wbraun wrote:

That's also the point were the spec is unclear, maybe we need to overwrite the startvalues with the initialize values.

No, we need not. The specification is clear in that point.

paul wrote:

It just cannot see this behavior as specification compliant or even sensible. It could be that i am completely mistaken; in this case it would be nice to give me a hint.

As Willi already wrote, there is nothing wrong with your Model as well as the OpenModelica implementation. I can briefly explain what happens and what you need to do to get the results you want:

The specifications says:

11.1.2 Execution of an algorithm in a model
An algorithm section is conceptually a code fragment that remains together and the statements of an algorithm
section are executed in the order of appearance. Whenever an algorithm section is invoked, all variables appearing
on the left hand side of the assignment operator ":=" are initialized (at least conceptually):
- A non-discrete variable is initialized with its start value (i.e. the value of the start-attribute).
- A discrete variable v is initialized with pre(v).