CODEWITHSUNDEEP
netlogo
JG667
JG667

Reputation: 11

Update a monitor once per tick instead of continuously. Slow model

I know that monitors are updated several times per second, and that can be helpful when checking the output of a model; however, that is not the case for my model, it just weighing it down.

I am trying to plot data from a monitor. I want the monitor to only update the reporter once per tick, if possible.

My model currently functions but it is bogged down updating multiple times a second. I was hoping someone could help me minimize my model's computational effort by updating once per tick.

sample of current code:

globals [initial-patch0-health patch0-health intial-patch2-health patch2-health]
patches-own [ptype penergy max-penergy alive?]

to setup
 clear-all
 set patch-health 0
 ask-patches [
    setup-patches
    ]
 reset-ticks
end
to setup-patches
 let temp random 100
 if temp <= 50 [
  set ptype 2
  set max-penergy random-in-range 0 5
  set alive? true
 ]
 if temp > 50 and temp <= 75 [
  set ptype 0
  set max-penergy random 10
  set alive? true
 ]
 set penergy max-penergy
 set patch2-health (ptype2-health)
 set patch0-health (ptype0-health)
end

to go
 ask-patches
  update-patch-health
 tick
end

to patch-health
 if ptype = 2[
   set patch2-health (ptype2-health)
 ]
 if ptype = 0 [
  set patch0-health (ptype0-health) 
 ]
end

to-report ptype2-health
  report [penergy] of patches with [ptype = 2]
end

to-report ptype0-health
  report [penergy] of patches with [ptype = 0]
end

My monitors and plot read (same for patch2-health):

sum (initial-patch0-health)

and

plot sum (patch0-health)

I use sum in this situation because the reporter delivers a list.

For context, I am doing a simple "sheep-wolf predation" style model but I want to monitor the initial grass health vs grass health over time, with multiple grass types (ptype). I have turtles but did not include that code here. Let me know if you need more code from me.

This code gives me the output I desire just at the cost of speed. I figured only reporting once every tick would save some computing time. Any suggestions for cleaning and speeding it up?

Upvotes: 0

Views: 343

Answers (1)

Luke C
Luke C

Reputation: 10336

Your code example is not usable to me (undefined variables, patch0-health is not output from a reporter, other errors)- check the MCVE guidelines. With that in mind, I'm having trouble replicating the issue you describe- I ran a few profiler tests with a monitor present and not present, and didn't get any difference in runtime. With this setup:

extensions [ profiler ]
globals [ patch-turtle-sum profiler-results]

to setup
  ca
  ask n-of ( ( count patches ) / 2 ) patches [
    set pcolor red
  ]
  crt 1000 [
    setxy random-pxcor random-pycor
  ]
  set profiler-results []
  reset-ticks
end

to profile-check
  repeat 20 [
    profiler:start
    repeat 20 [ 
      go
    ] 
    set profiler-results lput profiler:inclusive-time "go" profiler-results
    profiler:reset
  ]
  print profiler-results
end

to go
  ask turtles [
    fd 1
  ]
  tick
end

to-report patch-turtle-sum-report
  report sum [count turtles-here] of patches with [ pcolor = red ]
end

I ran the profile-check procedure from the interface, once with a monitor that monitors patch-turtle-sum-report present (mean go inclusive time: 678.59 ms) and once without (mean go inclusive time: 678.56 ms)- no detectable difference. However, I'm not sure if profiler accounts for monitor, so maybe that assessment is just not useful in this case. It could also be that the number of patches you're dealing with is quite large (in my test example I was doing 100 X 100 patches) so that the calculations get bogged down.

I wonder if you could get around your issue by using a monitor that just reports a variable that you manually calculate once per tick (instead of a to-report reporter)- eg to follow my example above, monitor a variable that is updated with something like: 

set patch-turtle-sum sum [count turtles-here] of patches with [ pcolor = red ]

That way you control when the calculation is done, which may speed up the model if the calculation is what's actually slowing down your model.

Upvotes: 2

Related Questions