I was trying to compare the performance of a microgrid between Simulink and Openmodelica. The microgrid has different VSC converters working in EMT average, synchronous generators, loads, lines and buses and the model obtains quite logical results, the problem is that when the same model is created with OpenModelica, the following error is obtained with DASSL solver and a step size of 2e-5 s:enter image description here . Also, the libraries used are Dynawo and the standard Modelica library. Does anybody knows what this error means and how can it be solved? If anybody wants to see the models or needs more information I could send it.
Thanks!
I tried to simplify the model the much as possible, using simple control techniques for the VSCs (no droops or LVRT) in Simulink and Modelica and I confirmed that the same values are used in both models. Also, I changed the tolerance, the step size and the solver.
Related
we want to publish an Open-Source for integrating Reinforcement Learning to Smartgrid optimization.
We use OpenModelica as GUI, PyFMI for the import to Python and Gym.
Nearly everything is running, but a possibility to connect or disconnect additional loads during the simulation is missing. Everything we can do for now is a variation of the parameters of existing loads, which gives some flexibility, but way less then the possibility to switch loads on and off.
Using the implemented switches in OpenModelica is not really an option. They just place a resistor at this spot, giving it either a very low or very high resistance. First, its not really decoupled, and second, high resistances make the ODE-system stiff, which makes it really hard (and costly) to solve it. In tests our LSODA solver (in stiff cases basically a BDF) ran often in numerical errors, regardless of how the jacobian was calculated (analytically by directional derivatives or with finite differences).
Has anyone an idea how we can implement a real "switching effect"?
Best regards,
Henrik
Ideal connection and disconnection of components during simulation
requires structure variability, which is not fully supported
by Modelica (yet). See also this answer https://stackoverflow.com/a/30487641/8725275
One solution for this problem is to translate all possible
model structures in advance and switch the simulation model if certain conditions are met. As there is some overhead involved, this approach only makes sense, when the model is not switched very often.
There is a python framework, which was built to support this process: DySMo. The tool was written by Alexandra Mehlhase, who made a lot of interesting publications regarding structure variability, e.g. An example of beneficial use of
variable-structure modeling to enhance an existing rocket model.
The paper Simulating a Variable-structure Model of an Electric Vehicle for Battery Life Estimation Using Modelica/Dymola and Python of Moritz Stueber is also worth a look. It contains a nice introduction about variable structure systems and available solutions.
I build a Modelica model, but when checking the model (Here is the model download link), it shows a local singularity like in the following screenshot.
so I delete the code showed in the error message.
h[3]=(hout+hl)/2
but although the model checks fine, there is a strong nonlinearity issue which causes the initialization failure.
So I try to delete the following code line:
h[1]=(hin+hv)/2
and the model not only checks but also there is no initialization issue.
My questions are:
When debugging the model singularity, the error message showed by Dymola might be not the singularity source of the model? Is there a general method to find the source of the singularity problem? Or I have to analyze the equations in the model manually?
How to minimize the nonlinearity of the Modelica model and ensure convergence? I found this problem exists in many fields, especially in the thermo-hydraulic models, I found that one way to deal with this problem is the way used in Thermao Power Library from Modelon and ThermoSysPro for EDF, these two libraries divide the models or connector into two types: flow and volume. To ensure convergence, it requires to use a staggered grid scheme like in the following screenshot.
So is there another method to deal with the nonlinearity problem in thermo-hydraulic models?
is there a common view on how to deal with the nonlinearity problem in thermo-hydraulic models?
Problem Faced:
I have a SIMULINK model that has got two algebraic loops.
In order to overcome this I have set the model configuration properties as "warning".
The model runs well and has got the expected dynamics as shown in below image.
enter image description here
Now I need to convert this model to .exe which will be accessed by a GUI.
In order to do so I have to break this algebraic loop by using a unit delay block else the build process does not execute EVEN IF the configuration properties of the simulation model has been set to "none/warning".
But in the process of using a unit delay block, entire dynamics of the solution changes which shows that its a numerical error as shown in below image..
enter image description here
I request, somebody please suggest a suitable solution in dissolving this algebraic loop error without changing the dynamics of the model.
In many situations Simulink is capable of solving algebraic loops and provide a solution, but it can not generate code (see "Implications of Algebraic Loops in a Model" at the end). If I assume your implicit goal of creating an exe is to run it on systems without Simulink, that is not possible.
I wonder if there's some experience out there, how much performance can be gained from using the Simulink Coder to generate models over running the model in (rapid) accelerator mode?
For instance, how does it compare to the quite dramatic improvements from not-accelerated to accelerated models?
I know this is kind of vague and probably depends on the specifics of a model, but I'd be happy with examplary numbers.
I don't know if you will really find speed improvement anecdotes that helpful, as your results are going to be highly dependent on your own implementation.
That said, the following reference on How Acceleration Modes Work might be useful to you.
As described in this link...
The Accelerator mode generates and links code into a
C-MEX S-function. Simulink uses this acceleration target code to
perform the simulation...
...the model methods are separate from the Simulink
software and are part of the Acceleration target code. A C-MEX
S-function API communicates with the Simulink software, and a MEX API
communicates with MATLAB. The target code executes in the same process
as MATLAB and Simulink.
The link goes on to describe Rapid Acceleration, as such:
The Rapid Accelerator mode creates a Rapid Accelerator standalone
executable from your model. This executable includes the solver and
model methods, but it resides outside of MATLAB and Simulink. It uses
External mode (see Host/Target Communication) to communicate with
Simulink.
(Note that the actual link has some nice diagrams that help to illustrate this architecture).
I think that there are a few important things to takeaway from these descriptions. First, in Accelerator Mode, code is only generated for the model methods; however, in Rapid Accelerator Mode, code is also generated for the solver. In either case there will be some overhead due to communication between the generated code and Simulink (though in general that overhead would be greater in non-rapid accelerator mode).
Now, whether you are going to see significant differences between these acceleration modes and full-on code generation will most likely depend on how you would be using the generated code. You had stated that your application is intended to essentially analyze/visualize the outputs of simulink models. Do you intend for you application, itself, to be a Simulink model? If so, I imagine your workflow would be that you generate code for the "plug-in" model and then incorporate this into your "parent" model as an s-function. Based on the descriptions given above, my gut feeling is that you would not see much of a performance improvement compared to accelerator mode.
However, if your application is to be implemented outside of Simulink, then code generation would definitely be the way to go. In this case, you've completely eliminated the overhead of communicating with Simulink. In this workflow, you could, for example, generate a stand-alone executable from the "plug-in" model, execute that model to get the outputs, and then simply load those outputs for analysis and visualization into your application. Your application could be written in any language you want. In fact, you could even still write your application in MATLAB -- the key point, though, being that your application runs once the stand-alone executable (generated from the "plug-in" model) has finished executing, rather than interfacing with the plug-in model while it is executing.
I have a large simulink model with many source and sink blocks, many with only elementary arithmetic operations in between. I have been asked to document the equations behind the model. I am currently doing this manually and I am finding it rather slow and there is a relatively high chance of errors in the process.
Is there any way for Simulink to generate the equations (in MATLAB syntax for example) automatically?
There is no utility in MATLAB/Simulink that can do exactly what you are looking for (and I personally don't know of any third-party tools that can do this, either).
However, I think that your best bet might be to make use of Simulink Coder. This will allow you to convert your Simulink model to C code. From that code, you may be able to extract the equivalent equations more easily than you can by analyzing the Simulink model by hand.
The catch, though, is that Simulink Coder is an add-on package to base Simulink, so you may or may not have this tool available to you.