I'm working with a NetLogo model on EV charging behaviour. All (500) agents monitor their my-charging-demand per tick and I want to find out what happens to this emergent behaviour when I change the policy intervention that is active (costs of electricity in this case). I am trying to show changes in charging characteristics such as charging-duration, charging power etc.
What is the best way to create data on the agents' my-charging-demand in time?
Right now I am plotting all their data in one graph using the following code:
ask adopters
[ create-temporary-plot-pen (word-who)
set-plot-pen-color color
plotxy ticks my-charging-demand
]
It works, but unfortunately it also made the model incredibly slow, as 500 pens are to be updated every tick. The model needs 105120 ticks before a whole year/run is completed, as each tick in the model represents 5 minutes. Therefore, speed does matter :-)
Is there a more efficient way to keep track / create data of one variable all agents have?
If I have understood this correctly, you want each agent to remember the value of its variable my-charging-demand across all time. If so, the easiest way (but I don't know if it's more efficient) is to have the list as a turtle variable. So, modify your turtles-own to add another variable:
adopters-own
[ ....
my-charging-demand
my-charging-demand-series
]
And wherever you have the code for calculating demand, add the result to the list
ask adopters
[ ...
set my-charging-demand ...
set my-charging-demand lput my-charging-demand my-charging-demand-series
...
]
I can't imagine a plot with 500 lines is readable. The plot should do something like the average of my-charging-demand or the proportion of turtles with my-charging-demand greater than some threshold.
Related
Looking for a way to store a turtle length of stay in the model after they have left the model. My model runs for several months and a few thousand turtles enter, undergo process then leave the area. It's complicate model (it's a hybrid DES and ABM) so I've tried to reproduce the simple bit below.
Turtles will be created at every tick and given a random length of stay but will only be able to begin process when they move to the right area (area-name) and when their time is up they leave the area. Their time-in-system reflects the wait for the area and the length-of-stay which I want to save once they're complete. If I leave them in the model it starts to break down after a couple of months and I suspect this is because the model has too many turtles still in the system for calculation and is inefficient.
go
create turtles 2
[
set time-in-system 0
set length-of-stay ceiling ((random-normal 48 4) + ticks)]
set shape "person"
if any? area-name with [not any? turtles-here]
[move-to one-of area-name]
]
undergo-process
end
to-undergo-process
ask turtles with [shape = "person"]
[
set time-in-system time-in-system + 1
]
ask turtles-on area-name
[if ticks = length-of-stay
[set shape "dot"
move-to exit-door]
end
I can then plot and see in realtime to make sure it is working
histogram time-in-system of turtles with [shape = "dot"]
but can't seem to figure out how to store them as unique values for plotting after the model has run and I have a dataset of outcomes without keeping them alive in the model. The real-time plot isn't necessary as long as I can store the unique values after they have left
If I ask them to die then I lose the unique values in the histogram. I don't want a tally of all values but each turtle's unique value at the end of the process after they left - at the moment the only solution I have to storing them is as an agent-set that stays alive in the exit-door patch but this takes up a lot of calculation power as the model progresses for months...
There may be a really simple command for this but I've been going round in circles through the programming manual trying to find it. Any tips appreciated
You should create a list storing the values of turtles that left.
Isolating only the code that is relevant for this purpose, it would be something like:
globals [
times
]
to setup
set times (list)
end
to leave-simulation ; This being executed by turtles.
set times lput (time-in-system times)
die
end
If your program is going to run for actual months, I recommend you use the file-write command to store your data. This way the data is preserved if the program halts for any reason; it gives you much more freedom to do the analysis you want without running the full simulation again.
If you write to a .csv (comma separated value) file, you can use almost any program (excel, R, matlab, python, C# or back to netlogo) to plot a histogram.
I have a NetLogo model, simplified to this:
to setup
clear-all
create-turtles 1000 [
fd 100
]
end
When I add a monitor widget to the UI, with a reporter like mean [xcor] of turtles and then run setup, the values in the monitor change a slight bit constantly. It might show 0.2305090322262271 one moment then 0.2305090322262268 the next, and then another similar number on and on.
What is making my monitor widget flicker or flash like this? How can I prevent it?
This is caused by a combination of a few things:
NetLogo's use of floating point numbers, which can produce small accuracy issues. See Floating point accuracy in the NetLogo programming guide: https://ccl.northwestern.edu/netlogo/docs/programming.html#math
Agentsets such as turtles are always returned in a random order.
Monitors re-run their reporter calculation constantly, even when you are not running any model code with a forever button or through the command center.
So the monitor constantly re-runs its mean [xcor] of turtles reporter, but the turtles agentset gives the turtles in a random order, and so the floating-point inaccuracies for mean will accumulate in a slightly different way each time due to the order differences. The end result is you see very slightly different numbers flashing through the monitor widget while nothing is happening.
You would see the same problem doing sum [xcor] of turtles or variance [xcor] of turtles - anytime you're reducing a bunch of floating point numbers from an agentset into a single value. You can also see the problem running your reporter code directly in the command center repeatedly, without a monitor widget at all.
The fixes are fortunately pretty easy:
Sort your numbers before you calculate: mean sort [xcor] of turtles, sum sort [xcor] of turtles, variance sort [xcor] of turtles. If the numbers are in the same order you'll still have small floating-point inaccuracies, but they'll be the the same every time so you won't see the values change. This is probably the best solution, but it can be slow if you have a really large agentset.
Change the Decimal places setting of your monitors to a number where you don't notice the changing values. Since the differences in results should be small, this is usually possible.
I've made a population model in Netlogo where the simulation stops when all my turtles have died OR the number of 300 ticks is reached. I need to report (or write to a file) the mean state of my turtles (turtle-own variables) one tick before the simulation ends. It would be easy if all simulations will run to 300 ticks, but in most cases the simulation ends before this happens (all turtles die). How can I achieve this? The death of the turtles is conditioned to either their "lifetime" runs out or to a stochastic probability of dying, so I can't predict when will this happen, and I need to know whether the last turtle died due to their lifetime running out or due to the probability worked against the turtle. Thanks!
Have you played around with BehaviorSpace at all? It works pretty well for means and sums etc. You can easily make BehaviorSpace experiments to export whatever reporters you set up to a .csv spreadsheet or table, whether you want reports at the end of your simulation or at each tick. For a simple example, if I want to know the mean x-coordinate of my turtles, I can set up the reporter using to-report:
to-report mean-xcor
let xlist ( [xcor] of turtles )
report mean xlist
end
Then, I can use Behavior Space (Tools > Behaviour Space) to set up an experiment that writes that mean xcor for all turtles at either each tick or only at the end of a run. The tool also allows you to set up multiple parameterizations of your simulation and compare results with different treatments- it's really handy! You can get creative with what you report in order to have the output be what you need. For your specific case, you could just make sure that your experiment is recorded at each tick.
You could also do this manually and with a little more control if you prefer. You can create a file and header during your setup using something like:
to setup-turtle-reporting
file-open "turtle_details_out.csv"
file-type (word "tick, who, xcor, ycor \n")
file-close
end
That sets up a .csv file in your model folder that has the column headers tick, who, xcor, and ycor. Then, during each tick you can have turtles write the appropriate variables to that same file:
to turtle-report
file-open "turtle_details_out.csv"
ask turtles [
file-type (word ticks ", " who ", " xcor ", " ycor "\n" )
]
file-close
end
This option gives you a bit more control in some ways, but is fiddlier. You will have to also play around with file-delete or manually delete/rename the file as you complete different simulations, as file-type will append to the existing file rather than overwriting it.
The monitor (below) is continually running and generating a random list of output, even though there is no tick activity.
Questions: Should it be continually running? Is there a way to monitor the list on the interface without the continual random output?
Code
to go
crt 100 [fd random 14 + 1]
end
to-report report-red-turtles
report [who] of turtles with [color = red]
end
To run:
On the interface, create a monitor report-red-turtles and a simple go button
It is by design that "Monitors automatically update several times per second". It's a convenient design in most cases, but can also have some weird consequences (be careful never to have side effects in monitor code!)
What happens in your case is that
[who] of turtles with [color = red]
produces different output each time it runs: the list produced by of is always in random order.
To get around this fact, you have two options.
Remove the randomness: sort [who] of turtles with [color = red].
Use a global variable (e.g. red-turtles), update it once per tick, and display that in your monitor.
It's a trade-off between simplicity and speed: the first option is simpler and cleaner, but more computationally expensive.
I am building a type of 'honey-bee' model, where the bees are turtle agents and the honey is a patch specific variable. In my model, each patch is assigned a value of 'honey-here' between 1-100 based on a specific distribution.
The model starts with the bees only being able to collect honey from flowers with honey = 1, for which they then receive 1 unit of honey in return. Before the bees can 'target' flowers with honey = 2, they need to occupy (i.e. a bee on a flower) X% of the total flowers with honey = 1. For example, I might require the bees to achieve 80% occupancy, which means if there are 10 flowers total with the variable honey = 1 then the bees need to occupy 8 of those flowers before they are allowed to start looking/targeting flowers with honey = 2. As each bee individually acts, the % occupancy value will change.
I'm having performance issues for the occupancy calculation. Ideally the calculation is updated within a turtle procedure as it needs to be applied to each turtle within the loop. Here's what I currently have to find the value of the variables I need to set current % occupancy before each bee is allowed to act:
ask bees
[
;; set up variable based on ratio of number of turtles occupying target patch size against total number target patch size
;; note -- don't do this in one step to avoid divide by 0
let patch-count-current (count patches with [honey-here = bee-honey-target-size])
;; don't want number of bees, want number of unique patches
let patch-target-occupy count patches with [ (count bees-here > 0) and (honey-here = bee-honey-target-size) ]
...
Later in the code, after checking to make sure patch-count-current isn't 0, I find my % occupancy via patch-target-occupy / patch-count-current
It turns out this is a very expensive hit on my processor performance. Especially as my number of bees grows, which is exponential in my model.
Is there a better way that won't cost me so much processor for each iteration of the loop?
Thanks!
-dp
Given your response to StephenGuerin, you could manually track the counts with global variables. If there is only one bee-honey-target-size at a time, this is pretty simple. Just make a patch-count-current global and a patch-target-occupy. Then, increase them or decrease them as things change.
The Sandpile model (from the models library) uses this technique to keep track of the total amount of sand without having to iterate over the patches. Check out how the total global variable is used.
If you need to keep track of the counts for all bee-honey-target-sizes at once, you could store a list of the counts in a global variable, where the index of the list corresponds to a value of bee-honey-target-size. This is much messier unfortunately, so you would have to write helper functions for sure.
Let me know if any of this needs clarification.
Percentage occupancy is a property of the group and only needs to be calculated once per simulation step. Your performance hit is due to calculating occupancy for every bee in your simulation. The calculation for percentage occupancy for a given 'target-honey' could look like this:
to-report calc-occupancy [target-honey]
report (sum [count turtles-here] of patches with [honey-here = target-honey]) / count turtles
end