Behavior Space Reporters once per time period - netlogo

I want to record data while running Behavior Space once within a given period, e.g. once per 1000 ticks. I see that Behavior Space can call reporters once per tick or once at the end of the simulation run. However, I do not want to record once per tick, because that produces too much data, but I also don't want to just have data at the end of the simulation. I cannot change the simulation time represented by tick because of numerical stability. I tried putting code into Behavior space, i.e.
if ticks mod 1000 = 0 [reporter]
but this gave an error ("Syntax, expected reporter") when I started the experiment. Is there a way around this issue, or am I stuck with gathering too much or too little data? Thx.

In your "Go commands", put repeat 1000 [ go ] instead of just go. That way, each "step" is actually 1000 ticks, so recording the data each step records it once every 1000 ticks.

Related

Anylogic - How to measure work in process inventory (WIP) within simulation

I am currently working on a simple simulation that consists of 4 manufacturing workstations with different processing times and I would like to measure the WIP inside the system. The model is PennyFab2 in case anybody knows it.
So far, I have measured throughput and cycle time and I am calculating WIP using Little's law, however the results don't match he expectations. The cycle time is measured by using the time measure start and time measure end agents and the throughput by simply counting how many pieces flow through the end of the simulation.
Any ideas on how to directly measure WIP without using Little's law?
Thank you!
For little's law you count the arrivals, not the exits... but maybe it doesn't make a difference...
Otherwise.. There are so many ways
you can count the number of agents inside your system using a RestrictedAreaStart block and use the entitiesInside() function
You can just have a variable that adds +1 if something enters and -1 if something exits
No matter what, you need to add the information into a dataset or a statistics object and you get the mean of agents in your system
Little's Law defines the relationship between:
Work in Process =(WIP)
Throughput (or Flow rate)
Lead Time (or Flow Time)
This means that if you have 2 of the three you can calculate the third.
Since you have a simulation model you can record all three items explicitly and this would be my advice.
Little's Law should then be used to validate if you are recording the 3 values correctly.
You can record them as follows.
WIP = Record the average number of items in your system
Simplest way would be to count the number of items that entered the system and subtract the number of items that left the system. You simply do this calculation every time unit that makes sense for the resolution of your model (hourly, daily, weekly etc) and save the values to a DataSet or Statistics Object
Lead Time = The time a unit takes from entering the system to leaving the system
If you are using the Process Modelling Library (PML) simply use the timeMeasureStart and timeMeasureEnd Blocks, see the example model in the help file.
Throughput = the number of units out of the system per time unit
If you run the model and your average WIP is 10 units and on average a unit takes 5 days to exit the system, your throughput will be 10 units/5 days = 2 units/day
You can validate this by taking the total units that exited your system at the end of the simulation and dividing it by the number of time units your model ran
if you run a model with the above characteristics for 10 days you would expect 20 units to have exited the system.

NetLogo Experiment Setup

I'm working on a model in Netlogo and I'm having a problem understanding how to set up an "experiment". In my model, I have a matrix that has all of the values that I'm interested in (6 in total) and the matrix is updated whenever a condition is met (every time X turtles are killed off) basically capturing a snapshot of the model at that point. The previous values in the matrix are cleared, so the matrix is a 1x6, not a 10000x6 matrix with only one line being updated for each snapshot.
What I would like to do is to set up an experiment to run my model several hundred times, collecting this matrix each time for the first X number of snapshots or until Y ticks have occurred. But I can't see a way to do that in the experiment setup?
Is this possible to do, or would I have to create the 100x6 (100 snapshots) and then just export that matrix to a CSV somehow?
I've never set up an experiment in Netlogo, so this might be super easy to do or just be completely impossible.
If I understand your question correctly, then you want 6 values reported at specific ticks during the run. Those ticks are chosen by meeting a condition rather than a certain number of ticks. NetLogo has an experiment management tool called BehaviorSpace. It is straightforward to set up your several hundred runs (potentially with different values for any inputs on sliders etc). It's not so straightforward to only output on certain ticks.
The BehaviorSpace dialogue box has a checkmark for every tick or at the end only. If you have it set to every tick, then you can export your six numbers every tick automatically. In your case, it is likely to be easier to do that than to try and only output occasionally. You could add a seventh reporter that is true/false for whether the matrix is being reset this tick. Then all you have to do in post-processing is select the lines where that seventh reporter is true.
If you want to run the model for exactly N snapshots, then you would also need to set up a global variable that is incremented each snapshot point. Your BehaviorSpace settings would then use that counter for the stop condition.
I'm not sure I understand your question, but usually you will have a Setup function and a Run function, correct? So I'm guessing the code structure below should be kind of what you are looking for. I haven't used netlogo in a while so the exact matrix code you'll have to figure out yourself.
globals your-1by6-matrix your-100by6-matrix
to setup
;reset your experiment
end
to run
;run your experiment
end
to run100times
repeat 100[
setup
run
;save your 1by6matrix into your 100by6matrix
]
;use your 100by6matrix to plot or export
end

Simulink - Output 1 every 30 seconds, 0 otherwise

I need a subsystem that needs to output 1 at interval or 30 seconds or slightly over 30 seconds.
Written in matlab code it should work like that
function y = fcn(time,uplinkTimeInterval)
%#codegen
persistent lastTriggerTime
if isempty(lastTriggerTime)
lastTriggerTime = 0;
end
if time>=lastTriggerTime || time == 0
y = 1;
lastTriggerTime = time + uplinkTimeInterval;
else
y = 0;
end
end
where ulplinkTimeInterval is 30 seconds. Of course I tried to use the matlab function block with this code but for some reason it does not work (in debug mode I can see that y takes value 1 as it should but it simply does not ouput the value outside the block), therefore I wanted to use blocks but I do not know how to do it.
Thanks very much for your help
You can make this logic relatively easily with code or blocks. As you requested a solution using blocks, here it is!
Use the clock block to keep track of time, and some constant block to determine the interval (in seconds) at which to give 1 instead of 0.
Use the memory block to delay the clock signal by 1 timestep, so we can compare consecutive steps' values.
Divide the times by the interval, and round down, to give how many intervals have passed.
Finally, compare consecutive "number of intervals passed" using a relational operator. If more intervals have passed on the upper line, then you have just stepped over the interval threshold.
Note: this will return a 0 for every timestep where you have not crossed a new interval, and a 1 at each individual timestep where you have. The accuracy of the output will depend on the step size of your model.
Edit: It may be clearer / easier to just add the memory block after the floor block, so you are only doing the division / rounding once. It would still allow you to do a comparison to the previous time step. That would look like:
Easiest way to do this is with a just a single Pulse Generator block, set to have a "high" of 1 every 30 seconds. That is shown as part of the image below. The signal will be high for whatever the percentage of the period is specified in the block dialog.
If for some reason you really need to use a subsystem then use a Triggered and Enabled Subsystem (See top right of image). Feed the same pulse signal into both the trigger and the enable port, and set the outport inside the subsystem to have Output when disabled to reset, and to have an Initial Output of 0 (See the lower right of the image).
The model below shows how to do this. In this instance the pulse has been set to have a period of 30s with the rising edge happening every 1% of that period (See the top left of the image).
The output signal will be high for one time step every time the input rises (assuming the trigger is set to rising edge.)

Reach to the required ticks of the simulation

Dear Netlogo community,
I have created a simulation enviornment on Netlogo, which runs around 35000 ticks. It takes around 70 to 80 mins to execute completely. I am facing some errors at the end of simulation (near 25000 ticks). Now I am debugging program by using print command. simulation takes 45 to 50 mins to reach to the desired tick (a ticks that creates problem). Is there any fast way in Netlogo by using which i can reach to the desired tick quickly.
As JenB suggests, use the export-world and import-world primitives to save and restore world state. Or use the equivalent menu items of the same names on NetLogo's File menu.

Unknown delay in Netlogo

There are 5000 milliseconds in 5 seconds. So if I run this code in Netlogo during that time:
every 0.001 [
some-calls-in-the-middle
tick
]
I expect to get 5000 ticks, but I'm getting no more than 150. Is there any way to map ticks to seconds more efficiently?
Presumably whatever computation you're doing in some-calls-in-the-middle is taking approximately 1/150 second for NetLogo to perform.
every is only useful for making a snippet of code run less often — never for making it run more often. (It might help to give the dictionary entry for every a careful read.)