How to position Canvas with agents in classical Agent-Based Modeling in AnyLogic - anylogic

I'm new to AnyLogic and trying to figure out how Agent-based models should be set there. There is a famous Epidemic model, which I'm trying to reproduce. Most tutorials on classical ABM deal with old GUI settings.
For example, in version 8.5+, which is actual now, the Environment object (that was used for positioning of layouts) has been deprecated.
Now I see that new object Canvas is used to put the layout with agents on the page. But the structure of source code file is a bit unclear for me and I've failed to find relevant description how Canvas can be set for the purpose. (Besides I'm not sure that this is recommended way of doing this task.)
Question: I would love to learn the right way to arbitrary position the area with agents on the page. Below you may see what I get by default.

After some playing around, the 'minimalistic' functionality is as follows.
One should create some population with arbitrary name Person (population name people adds automatically).
The following structure of the Project is to be reproduced (arbitrary names are marked with yellow).
Comment: after adding a Canvas called mapCanvas one adds the function setCanvasCellColor with following body:
mapCanvas.fillCircle(person.getX(), person.getY(), 3, color);
It is clear that former two arguments stand for coordinates of a given point, then its size (i.e. 3) and color. Do not forget to add two arguments used in the body, namely, person as Person and color as Color.
From Entry Action of the statechart named state call the just made function. I've put black color here just for the sake of demonstration; chartreuse constant gets used instead in the Epidemic example.
main.setCanvasCellColor(this, black);
Finally, you may run the model to get the following picture.
Note
If one is reluctant to bother with Canvas, use Main - Presentation - xxx_presentation and click Draw agent with offset to this position checkbox.

Related

Is there a way to force "Categorized" symbolization to use attributes in the table for e.g. color definition?

I have a map with a couple of dozen of different "categories" of polygons and would like to symbolize them using the "Categorized" symbolization in QGIS. Every category already has its color defined in a "fill_color" attribute within the table.
I would like the symbolization to honor that color definition instead of assigning some color of its own to the categories.
Is there a way to do this, without manually going through every category and changing its color?
I'm not a Python programmer, so if there is a possibility of programming this, it's beyond me.
The software itself does not offer the option to do what I need in "Categorized" symbolization, although you can do it in "Single Symbol". If you try it in "Categorized" it will let you do the same steps, but the program will nevertheless use colors of its own choosing.
Of course, if I go the "Single Symbol" way, I can't generate a proper legend of map units in Layout.

How to select output in Anylogic by agent parameter?

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.

How to pass heatPorts.T to DynamicPipe flowModel?

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).

What underlying difference makes Node Instances appear different?

I have two similar (if not identical) node instances that are appearing differently in a deployment diagram (and anywhere else that I use them).
I may have done some odd things in the past while beating EA into submission.
But, now ... by pulling every lever I can imagine, I can't get them to appear the same (or behave the same). The one on the right is consistent with all the other nodes I have.
The colour is off and the "properties" (maybe they're tags?) showing in the body of the one on the left appear but I can't figure out where to edit / remove them.
I've tried:
Element ... Advanced ... Change type (Node --> Device and back to Node just to try and get it to 'forget' anything it's holding onto)
Remove & re-add stereotype to both the Node type (i.e. type from which instance was made) and the instance itself.
Creating a new instance from the same type, just to see what happens. It creates a node instance more like the one on the right.
Early on in developing this model, I created my own MDG technology. My guess is that the node on the left was created from a type in that MDG, which had some attributes available. It's conceivable to me that Sparx is hanging onto those attributes and not providing a way to edit because of the type was changed.
Any guidance on how to manipulate the under lying data (without creating a new node instance and replacing on all diagrams and re-configuring all relationships)?
Those are different elements. You see that the name (FQN) is different on both. Click each and issue Ctrl-G to locate them in the browser.
The green dot on top makes me think that you use your own MDG which puts the dot on <<SUSE>> stereotyped elements. So the MDG is likely what also makes them appear different depending on tagged values.
Regarding the Version and OS shown in the lower compartment of the left class: those are run states. You can edit them via Context/Features../Run State
For the colour of the element, I think what happened is this ... at some point, I selected (Element Context Menu) --> Appearance --> "Default Appearance" and clicked Reset to defaults. Even with a stereotype applied, this reverts to the "unstereotyped" appearance. I grabbed the RGB values from one the element on the right in the image and set the element on the left's values to those numbers and it's all consistent now.
The main question was the Run State variables, which #(Thomas Killian) addresses in another answer.

Default diagram for Toolbox

I have a custom toolbox with a foo element.
I would like the foo to be green on an class diagram and red on flow chart diagram by default.
Adding more than one stereotype to non- UML type is impossible (as far as I know).
Is it possible to create 2 toolboxes- one for class diagrams and one for flow charts, specifying the default diagram for each toolbox in the profile?
Not quite the way you describe it.
Toolboxes don't specify which diagram they open, it's the other way around: you create a custom diagram type and associate it with a toolbox. Different custom diagrams may use the same custom toolbox.
You can create two custom diagram types, one for class ("Logical") and one for flow chart ("Activity"), but if you're only after getting the same stereotyped element (foo) to display differently in the diagrams, you don't need to.
The solution is to create a shape script for the stereotype, which checks the diagram type and changes the color accordingly. The diagram type can be queried from the shape script using the diagram.type property (for the base UML diagram type), or diagram.mdgtype (for the custom diagram type, if you've defined one). There is no need to create an Add-In, as another answer suggests, at least not in EA 11.
Check the help file under Extending UML Models -- MDG Technology SDK -- Shape Scripts -- Write Scripts -- Display Element/Connector Properties.
A simple script might look like this:
shape main {
if (hasproperty("diagram.type", "Logical")) {
setfillcolor(0, 255, 70);
} else if (hasproperty("diagram.type", "Activity")) {
setfillcolor(255, 87, 87);
}
drawnativeshape();
};
No. You need to have two different stereotypes. The target diagram is independent of the element. If you want the element appear different on the type of the diagram where you use it you need to adapt the shape script so it calls an add-in which detects the diagram type.
Well, writing the last sentence I would not know how to detect the diagram where the element in question is in. Needs investigation. But other than that - no solution I know of.
Edit: Since the add-in just receives the element GUID it has no way to figure out the diagram from where the call is made. Probably worth a feature request. But the time where we saw those realized in the next build are gone (since more than 10 years).
A last though: template packages. I almost never used them. Maybe they offer coloring depending on diagram/element.
Edit2: Last resort EA_OnPostNewDiagramObject. Catch that and you can get all information you need to apply the color.