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.
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.
In the simulation window, before the run, I'd like to change some probability distributions (e.g. delay time) by typing, for example, "triangular(5, 20, 15)" into a specific editbox linked to a variable.
I know how to do this with static values, but I couldn't figure out how to do the same with probability distributions.
AnyLogic offers a built-in functionality for that with com.anylogic.engine.database.CodeValue.
It is originally meant that a distribution function stored as text in the internal database can be parsed to java code and executed, but it actually also works without the database and for any kind of code. It is the same idea as in Benjamin's answer, just that you do not need to add any external java library.
Use it like this:
CodeValue myCode = new CodeValue(this,"....java code to be executed");
myCode.execute();
And in your specific case, assuming you have a variable named variableA and an editbox named editbox, use the following to evaluate the expression, get a value and set it for the variable:
CodeValue myCode = new CodeValue(this,"variableA = "+editbox.getText());
myCode.execute();
Obviously, allowing the user to type any command there and running it without a check or error treatment is a bad idea, be aware of that.
This is a Java issue. You need to convert a String (your editbox content) to executable code. Not straight-forward but also not impossible, see Convert String to Code and similar posts.
So, I'm pretty new with Anylogic, but have done a lot of tutorials and I have programming experience in Java. For my thesis I'm modelling a vehicle flow as a process. In the source block, I create custom agents (vehicles) with some parameters from the database. This works fine. Then I want to assign an electric parameter with randomTrue(0.5). For this, I call a setupTaxi-function, where electric ist set. The parameter for the randomTrue-function should be changeable, so I set it as an extra paramter anteilEtaxis (0.5).
After that, I want the vehicles to do different things depending on the value of electric using SelectOutput. I selected the Condition and test on agent.electric.
I basically did the exact same thing as described in the Anylogic help. And yet the framework always chooses the true Output port, no matter if the parameter ist set to true or false.
See the image for setup and parameters. I tested this via console (the first line is a println-call in source, the second a println-call in selectOutput.). Plus you can see that the parameter is set to different values, because the 3D visualisation model depends on it:
enter image description here
Also, I tried a few different combinations of setting the parameters, reading them etc... The only thing that will work is putting randomTrue(0.5) directly in the Condition box. This is not what I want though. So if you have an idea, what is wrong, please tell me.
This is a typical beginners problem.
I will assume you are calling the setupTaxi-function in your source in the "on exit" action... If you are doing that, then it's too late and the agent already made its decision on where it will go after the select output block.
You have to call your setupTaxi-function in 2 possible places:
1) In your source on the "on at exit" action
2) In your vehicle agent on the "on startup" action
Or even.. just make electric variable have a default value of randomTrue(main.anteilEtaxis)... that will also work.
In the implementation of a flow models that function with Modelica Standard Library DynamicPipe (or a similar model that builds from PartialTwoPortFlow) there are examples of flow models that take place in an environment with heat transfer that requires wall properties (e.g., heatPorts.T and/or heatPorts.Q_flow) in order to calculate the pressure drop.
For example, a pressure drop model may need to calculate a new visocisty or Prandtl number based on the medium pressure and the wall temperature to capture cooling/heating effects, etc.
The heat transfer model obtains properties of the medium via passing the "states" however there is no existing connection in DynamicPipe or PartialTwoPortFlow that goes the other way.
I've tried numerous variations of ideas and have had no success, including creating a new PartialTwoPortFlow that contains all the heat transfer calls that exist in DynamicPipe.
I hesitate to post this question as I am surprised I am having so much difficulty with this and would not be surprised to find a straight forward solution. Nevertheless I need this ability and curious if others have already solved this issue as I am running short on ideas.
So my questions is:
What is a proper/efficient means of passing the heatPorts.T values to the flowModel?
For those familiar with the MSL Fluids library and more specifically the Pipe models provided, this answer should (hopefully) make sense.
Aside:
It seems the dynamic pipe could be improved a little bit by not restricting the heat transfer area to the perimeter x lengths and instead introduce a parameter (e.g., heatTransferArea) that would permit the user to define it and default to perimeter x lengths. See below
parameter SI.Area heatTransferArea = perimeter*lengths "Total heat transfer area";
HeatTransfer heatTransfer(
...
final surfaceAreas=heatTransferArea , //perimeter*lengths <- replaced
...
End Aside:
In order to communicate heatPorts.T to the flowModel and to not have errors when I checked each of the models I had to do the following:
Make an "input" in the flowModel for Ts_w. Not parameter (take a look at how mediums.state is passed)! Might have to do some finagling with it like "diameters" (see DetailedPipeFlow) to make it be used how you think it's going to be used.
Duplicate PartialTwoPortFlow and add the final Ts_w = Ts_wFM to flowModel. Additionally define the variable SI.Temperature[nFM+1] Ts_wFM in PartialTwoPortFlow and establish definitions similar to statesFM in the equation section.
This will require adding a HeatPorts model to be added.
Duplicate DynamicPipe and change the extension to the new PartialTwoPortFlow. Set use_HeatTransfer to true (as I've set it up this has to be true now for this to work which isn't ideal but manageable). Might be good to make it a final parameter so it can't be changed.
Don't forget to connect heatPorts to the heatports added in step 2.
I believe that this capture a quick version of how I was able to get the wall temperature passed to the flowModel. Perhaps there is a more elegant way but I though this was pretty serviceable. I now simply have one more Partial model and one more pipe model called PartialTwoPort_wTemp and GenericDynamicPipe (I also incorporated my surfaceArea correction in the new pipe).
Not really critical question, but i'm curious
I am working on a form and sometimes the generated function name is /1BCDWB/SF00000473, and sometimes /1BCDWB/SF00000472. This goes back and forth.
Does anyone know what's the idea behind this? Cuz i'm quite sure it's not a bug (or i might be wrong on that).
It is not a bug. You always have to use SSF_FUNCTION_MODULE_NAME to determine the actual function module name and call it dynamically using CALL FUNCTION l_function_module.
Smartform FMs are tracked by internal numbering and thats saved in the table STXFADMI. You would always notice the different number in Development System if you have deleted any existing Form. Similarly, you would also notice the different number in your Quality system based on the sequence the forms are imported in QAS and the forms as well (as test forms are not migrated to QAS.
Similar behavior is also true for Adobe Form generated FMs.
You need to understand that every smartform has a different interface and hence the automatically generated function module needs to have different import parameters.
Due to this reason the 'SSF*' FMs generate a FM specific for your smartform. The name of the 'generated' FM changes when you migrate from one system to another. And that's the reason why you should use a variable while calling the 'generated' fm and not hardcode it.
The same goes with Adobe form as someone has rightly said in this thread.