I´m trying to use the NetLogo System Dynamics Modeler to control the behavior of individual agents. But when I set up the Modeler diagram, the code that is generated automatically includes variables (stocks, variables) as Global. Instead I would like these variable to be under turtles-own, so that each agent runs the systems dynamic model autonomously.
If this is not possible, I guess I can go on writing the ODEs myself. But in doing this, is it best to solve the ODEs in R using the R-extension (I haven´t used R yet), or will this be slower than using Euler´s Method in the NetLogo Code?
NetLogo's SDM doesn't allow this. (In general, the NetLogo SDM's capabilities are pretty rudimentary.)
But, if you already have an existing SDM model, you could at least use it as a starting point, by just copying the generated NetLogo code out of the SDM window's Code tab, pasting it into your model's main Code tab, and then taking it from there, starting with changing globals to turtles-own.
The output of the NetLogo SDM is just ordinary NetLogo code, no hidden magic, no special solver running in the background, just the code you see.
No idea about your second question — you might try asking that separately.
Related
i’m currently working on project using anylogic. I’m making a system dynamic to modelling a SIR model. and I make a manual calculation of each stock in excel (using euler method) , but the results in excel are different from the result in anylogic. I’m curious about how anylogic calculate the model that I build on it. anyone know how the calculation works on anylogic?
if your SD model is mixed with discrete-events or agent-based, the time step that you set up in the configuration for your model is not considered anymore and a different time step is used for which you have no access, unless you run the simulation in virtual mode (at least it's more likely to behave as you expect that way)
I have extensively tested this, and as long as your model is 100% system dynamics, your euler equations should work as expected, in which case the reason is that your excel is incorrect.
On the other hand if you use RK4 approximation in anylogic, it doesn't really work properly, so I don't even know why they still have it as an option.
I suggest you Vensim and make some tests to see the difference in results and be sure you are calculating correctly in Excel..
In my course i talk in detail about this topic: noorjax.teachable.com
I am using Dymola 2020x to develop a thermal model and export the FMU to Simulink to simulate controllers.
For implementing advanced controllers, I require an iteratively run framework, which helps to initialize the states after every iteration to the values at end of every previous simulation. This can be done within Dymola through “import initial” and “Continue” commands in the Simulation tab of Dymola.
However, since I am designing the controller in MATLAB, I require a similar feature for that platform. The only way I know right now is to manually change the initial conditions in the FMU block, but since I have a lot of states, it would not be feasible to do it manually. Any scripting ideas are welcome as well.
All in all, I require a framework/method to be able to initialize states of my model through MATLAB/Simulink to the values I get after running a single iteration.
Some help would be appreciated.
Expose the initial conditions of the variables as parameters, and set them from MATLA Scripts with e.g.
FMIKit.setStartValue(gcb, 'step', 'true')
see https://github.com/CATIA-Systems/FMIKit-Simulink/blob/master/docs/fmu_import.md
Is there a way to set the maximal solver stepsize (hmax) directly in Dymola?
The value for hmax can be changed in dsin.txt and it works if the simulation is run with dymosim.exe, but gets overwritten if simulation is started in Dymola.
Is there some hidden flag that I can use?
Thanks!
After editing dsin.txt, try to execute dymosim.exe directly instead of using the GUI (without parameters e.g. when executing via a double-click from the explorer this will create dsres.mat instead of <modelName>.mat). This should prevent Dymola from re-creating dsim.txt and therefore consider your setting for hmax.
Not very convenient, but currently the only way I know to make it work.
You can as well create dsin.mat and provide it as an argument for dymosim.exe to be able to re-create dymosim.exe using the GUI, without modifying dsin.txt every time. This is shown here: dymola.readTrajectory - different sample times. You need to skip the second parameter "<DymolaWD>\tgrid.mat" obviously.
#Shanga: I think this should work for eviter as well, but I have no model to reliably test it. So feedback would be appreciated...
Setting maximum stepsize is only reasonable for solvers without stepsize control, e.g. Euler or Runge-Kutta. In those cases, a Fixed Integrator Step can be set in Simulation setup.
Currently there is no convenient way to do this directly from Dymola. The dsin.txt file has to be edited as you describe.
I believe you set it through the parameters Interval length or Number of intervals in the General section of the Simulation Setup. The system will be solved at least on those points, which I understand as the maximum stepsize.
background
I'm working on a group project to simulate some consensus algorithms used by a group of independent robots to form an arbitrary shape on a 2D plane. The robots are modeled as unit disks, and all run the same algorithm. Basically, each robot can move, wait, or observe its local environment at any moment, but cannot communicate explicitly with an other robots. We'd like to find a simulation or even 2d graphics library to help us without writing too much from scratch.
Question
Can anyone recommend a simulation library meeting the requirements below, which could be used for a multi-robot 2D simulation?
I've never coded a simulation before, so it's possible some of my concerns are readily addressed by many existing libraries. However, the Mason project is the only resource I've found that seems promising so far. Unfortunately, a few of our team members are not very proficient in Java, so I'd like to find something suitable in a different language, if possible.
Requirements
* language preference (descending order): python, c++, (maybe) java
* open source/FOSS recommendations only
* Options/flags to disable simulation: We plan on running several thousand trials of randomly generated shapes against each algorithm, so for the bulk of trials we don't care about any visual representation, just data. So the simulation logic has to be decoupled from the graphics components if this makes sense.
* collision detection
* Customizable visual representations: Within a simulation, we'd like to have several views (or toggles for a single view) that present additional information about each robot like current state, the area it's currently observing etc.
For such simple graphics you can surely get away with either pyqt or wxpython.
The simulation itself should be its own python module; the GUI should just load the module, then call its "timestep" function at regular intervals (timer, GUI idle callback, etc); the step function should evolve the robot system by one small time step.
The GUI should just display the simulation state. Avoid mixing everything (display and simulation) in one module, it'll get pretty messy, plus if your simulation engine is a separate module you can then also run it directly from the command line and look at the output file.
It would be pretty easy to write a python script that reads such output file and generates commands to represent it graphically in either excel or powerpoint using win32com, in which case you don't even need pyqt or wxpython.
For the collision detection, look at pybox2d.
I wonder if there a way to "debug" a modelica code, I mean debugging the code line by line and you can see how variables change, things like that?
I know that the modelica code is translated into C, I just want to know if there's a possibility to do that somehow, if there is, I believe it's gonna be a great improvement for any of the simulation environments. Thanks.
HY
This is a good question and it comes up a lot. But first, let's step back for a second.
The idea of debugging "line by line" is something comes from imperative programming languages. By "imperative" I mean that a program is simply a sequence of instructions to be carried out in the specified order.
When someone debugs Java or Python, this "line by line" approach makes sense because the statements are the fundamental way behavior is represented. This "line by line" approach could also be extended to modeling formalisms like block diagrams (e.g. Simulink) because, while graphical, they are also imperative (i.e. they constitute steps to be carried out in a specified order).
But Modelica is not an imperative language. There is no notion of steps, statements or instructions. Instead, we have omnipresent equations. So thinking linearly about debugging doesn't work in Modelica. It is true that you could think about debugging the C code generated from Modelica, but that is typically not very useful because it bears only a partial resemblance to the equations.
So how do you debug Modelica code? Well, debugging Modelica code is really debugging Modelica equations. Normally, Modelica models are composed of components. The equations that are generated when components are connected are automatically generated so lets stipulate that the Modelica compiler generates those correctly. So what's left is the equations in the component models.
The simplest way to approach this is to test each component individually (or at least in the smallest possible models). I often say that trying to debug Modelica components by throwing them all together in a big model is like listening to an orchestra and trying to figure out the one instrument that is out of tune. The fact that these equations in Modelica tend to form simultaneous systems of equations means that errors, when they occur, can propagate immediately to a number of variables.
So your best bet is to go through and create tests for each individual component and verify the behavior of the component. My experience is that when you do this, you can track down and eliminate bugs pretty easily.
Update: You shouldn't need to add outputs to other people's component models to debug them. An output can be created at any level, e.g.
model SystemModel
SomeoneElsesComponent a;
SomeOtherGuysComponent b;
end SystemModel;
model SystemModel_Debug
extends SystemModel;
output Real someNestedSignalFromA = a.someSubsystem.someSubcomponent.someSignal;
output Real someOtherNestedSignalFromB = b.anotherSubsystem.anotherSignal;
end SystemModel_Debug;
Of course, this becomes impractical if you have multiple instantiations of a signal component. In those cases, I admit that it is easier to modify the underlying model. But if they make their models replaceable, you can use the same trick as above (extends their model, add a bunch of custom outputs and then redeclare your model in place of the original).
There is a transformation debugger in OpenModelica now. You can find here which variable is evaluated from which equation.