Is it possible to hide objects or outputs after I have simulated a model? I have a ton of objects and I feel like I am wasting time sifting through them trying to find my correct response.
If not, is there a way to organize the way my outputs are displayed in the simulation tab?
Thanks.
The main possibilities in Dymola are:
Make components protected. As default protected components are not included in the results.
Use the selection of variables as linked by #Lukas-Exel http://www.claytex.com/blog/selection-of-variables-to-be-saved-in-the-result-file/ In Dymola 2017 FD01 there is also a GUI for this Edit>Variable Selections
Filter which variables are shown from the result - text-field under the Variable Browser (before Dymola 2017 FD01 that is found under "More").
You can also combine these solutions.
Optionally, there can be used HideResult in the variable annotation (but don't overuse it!):
Real myVar annotation(HideResult = true);
Related
I am trying to use a .mos file in Dymola to do multiple simulations, here is an example from claytex's blog:
openModel("C:/Dymola/Testing/Test1.mo")
translateModel ("Test1");
for i in 1:10 loop
a=i;
simulate();
system("copy dsres.mat results"+String(i) +".mat");
end for;
It seems when I translate a model in the script file, I could modify the model's parameters again, which is different when I use Dymola's GUI. In Dymola's GUI, if I try to modify the parameter after I translate the model, I have to re-translate the model. My question is:
In Dymola's script file, when I modify the parameter, how does Dymola deal with it?
The above comment by "user2024223" is correct, but I think "variable browser" is not stressed enough and some more explanation could help:
When changing the model's parameters after translation, make sure you are not using the model editing (either "Graphical" or "Text"-Ribbon), because this will change the model's code and therefore (usually) force re-translation. The same is true for the "Model View" in the "Simulation" Ribbon.
The code will not be changed if you use the "Variable Browser" in the "Simulation"-Ribbon. An alternative (which actually does the same) is typing the parameter value in the "Commands"-line. E.g. this could be J1.J=5 for the CoupledClutches example. Both of the variants in the paragraph should behave similarly to the script.
Dymola deals with parameter changes after translation by modifying the dsin.txt file.
Some/many parameters have been evaluated and cannot be changed in this way - these variables are not editable in the Variable Browser.
You will get a warning if you try to change non-editable variables in a script.
Note: You should in most cases not have to deal with re-translating the model even after modifying the editable parameters of that model in the GUI. Just simulate the model again - hopefully it does not need re-translation.
As a part of my studies, I am interested in modifying some constant properties of a medium like water. For example, in Buildings.Media.Water that cannot be accessed by Dymola (I opened it in Visual Studio Code), I am going to change a constant e.g. density. Is there any way to do so? or should I do it through partial medium?
This question is also applied to some thermo-physical properties like thermal diffusivity that I could not find it in the constants of water.
I would be thankful for your advise.
In Dymola you should be able to modify constants if you double-click the package containing the constant(s) and then edit the text using the Modelica-Text view. This way you should be able to edit all constants in the package. Obviously write-access is required to do so (which you e.g. don't usually have for the MSL).
Using inheritance (partial medium) makes sense if you want to be able to switch between multiple media quickly or you don't have write access. For experimentation it should be fine to directly change values - being careful not to forget to revert...
Regarding the thermal diffusivity: it probably simply is not there. You could inherit from the original package and add it if that is the best solution to your needs.
Using Dymola, I'm looking for a way to automatically execute a script when loading a library. The intention is to define additional displayUnits using the defineUnitConversion() command, which are specific to the library that is loaded. Still I think there are quite some other cases where this could be helpful.
What I figured out in this regard:
I know that it is possible to add conversions to the file in DymolaInstallDir/insert/displayUnits.mos but this comes with the disadvantage that is has to be done again on every new computer or after an update of Dymola. I would like to avoid this.
Other than that I only found the libraryinfo.mos file, which seems to be read during the start-up of Dymola. Therefore I assume it is not the right place to put the conversions, as it contains general information about the library and should only contain the respective functions.
Dymola 2022 has a new (tool-specific) feature that covers exactly this use-case. It is mentioned in the Dymola 2022 release notes in the section "Library startup script" on page 24.
It basically introduces the a new annotation, which allows to specify a path to a .mos script, which is executed, when the respective library is loaded. Here is the example from the release notes:
package ThisPack
annotation(__Dymola_startup =
"modelica://ThisPack/Resources/Scripts/Dymola/startup.mos");
end ThisPack;
The annotation can also be set via the UI...
I'm porting a large Simulink model from Simulink R2010a → R2017b.
The main model is basically a glue-layer for many interwoven reference models. My objective is to generate a standalone executable out of this main model using Coder.
Parameter tunability in this context is not done via the Signals and Parameters section on the Optimization tab in the Model Configuration Parameters dialog (as is the case in stand-alone models), but rather, via constructing Simulink.Parameter objects in the base workspace, and referencing those in the respective referenced models, or in their respective model workspaces.
Now, AFAIK, in R2010a it was enough to set
new_parameter.RTWInfo.StorageClass = 'Auto';
new_parameter.RTWInfo.CustomStorageClass = 'Define';
to make the parameter non-tunable and convert it into a #define in the generated code. In R2017b, this is no longer allowed; the StorageClass must be 'Custom' if you set a non-empty CustomStorageClass:
new_parameter.CoderInfo.StorageClass = 'Custom'; % <- can't be 'Auto'
new_parameter.CoderInfo.CustomStorageClass = 'Define';
But apparently, this does not make the parameter non-tunable:
Warning: Parameter 'OutPortSampleTime' of '[...]/Rate Transition1' is non-tunable but refers to tunable variables (Simulation_compiletimeConstant (base workspace))
I can't find anything in the R2017b documentation on making parameters non-tunable, programatically; I can only find how to do it in stand-alone models via the dialog, but that's not what I want here.
Can anyone point me in the right direction?
NOTE: Back in the day, Simulink Coder was called Real-Time Workshop (well, Real-time Workshop split into Coder and several other things), hence the difference RTWInfo vs. CoderInfo. Note that RTWInfo still works in R2017b, but issues a warning and gets converted into Coderinfo automatically.
In generated code it should appear as #define, the way you specified it.
https://www.mathworks.com/help/rtw/ug/choose-a-built-in-storage-class-for-controlling-data-representation-in-the-generated-code.html
Btw, yes, it's a bit confusing, because in m-file you specify CustomStorageClass = 'Define';, in GUI you specify Storage class as Define (custom), but in documentation they say Storage Class as Defined.
I am not sure why warning about tunability shows up.
I am using Behavior Search to calibrate my NetLogo model for 20 different hospital units. I am using global variables to set the min and max for several sliders in my model, but I think this is causing an error in Behavior Search when I attempt to load the parameter values from the model. However, I don't want to manually enter these parameter ranges manually each time I use Behavior Search.
Is there a way to get around this error? Is there a way to set the min and max for a specific slider to a constant, rather than using global variables?
Thanks for your help!
BehaviorSearch developer here -- if I'm understanding your question correctly, your NetLogo model has a slider which has a min/max constraint that is not set to a constant, but is instead set to a global variable (in the slider settings, accessed from the NetLogo interface).
When I choose such a model using the BehaviorSearch GUI, and then click the "Load parameter ranges from model interface" button, then I get the value of 0 for that constraint. (I don't see any error message -- just the value 0 (if you're getting an error message instead, then I may not be understanding your situation correctly, and perhaps you could post exactly what error message you're seeing?)
This will be true even if you are setting the slider min/max to a global value in the special STARTUP procedure (see: http://ccl.northwestern.edu/netlogo/docs/dict/startup.html), because STARTUP is only run when a model loads in the NetLogo GUI, and not when a model is loaded in headless NetLogo.
Thus, unfortunately, I think the answer to your question is: "no, there isn't a way to get BehaviorSearch to load the parameter ranges from global variables within the model".
Some possible work-arounds:
BehaviorSearch is open-source -- some changes could be made to it -- i.e., maybe adding in a call to "startup" whenever BehaviorSearch GUI loads the parameter ranges would be sufficient for you.
If you're only doing a few searches, I don't see why manually editing the parameter ranges would be particularly onerous. However, if you're generating a lot of different searches with this model, then I can see how it might be an issue. The .bsearch files are just XML text files, so you might consider generating them without the BehaviorSearch GUI, e.g. using a scripting language.