NetLogo - What is 1 distance unit in NetLogo? - netlogo

I am working on traffic simulations using NetLogo for a post graduate project.
For turtles to move forward we can specify the number of units it can move e.g. fd 1, which would mean the turtle moves forward by 1. What is this 1 unit? Is it equal to 1 patch or equal to the size of the turtle?

Each step is the same size as the patches.

As Luis said, each step is the size of one patch, but remember that steps are not restricted to integers, eg. fd 0.7 is a valid command and will move a turtle forward seven tenths of the size of a patch.

The patches represent a roadway (if you're discussing a traffic simulation model) and one scales patches in a model appropriately, e.g. 1 patch=25 m....etc.!

Related

why are my results from behaviorspace (netlogo) so inconsistent?

I am somewhat new to Netlogo, and have been scratching my head over some of the results I get from behaviorspace. I have been playing with the wolf-sheep predation model, and changing their movement based on what color patch they are in. There is a single wolf and a single sheep, and what I want to measure is the number of time steps it takes for the wolf to eat the sheep. The patches are colored randomly, based on some proportion from 0-100, as below:
to color-patches
let total 100
let p-red slider1 / total
let p-green total - p-red
ask patches [
let x random-float 1.0
if x <= p-red + p-green [set pcolor green]
if x <= p-red [set pcolor red]
]
end
The issue I am having is when I set the movement of the wolf and the sheep to move independently of the patch color:
ask sheep [
set heading random 360
fd 1
]
ask wolves[
set heading random 360
fd 1
eat-sheep
]
My expectation is that the mean and standard error for the number of time steps until the wolf eats the sheep should be pretty similar regardless of how many red patches and how many green patches there are, since their movement is not affected by it. I ran it in behaviorspace, with 1000 iterations per 10% increase in proportion of red patches (from 0 - 100%). However, I keep getting results that look kind of like this:
enter image description here
Basically the means+se are all over the place. Every time I run it, they are distributed differently (but same grand mean). This is particularly odd since when I introduce any sort of patchcolor-specific behavior for either the wolf or the sheep, I get very clear patterns with less variation.
Any ideas what might be going on here? The only thing I could think of is that relative starting position of each is pretty important (but each is placed at random xy coords). I assumed that in behaviorspace for each iteration for a given set of parameters, it would run through all the code (thus generating a new random landscape and new random starting points for the wolf and the sheep for each of the 1000 runs per parameter combination). Does behaviorspace maybe take the first landscape and starting coordinates for each turtle and use them for each of the 1000 iterations per parameter combination?
Thanks!
Now I think you may not have a mistake but instead are just misinterpreting your graph. The Y axis on the graph you posted ranges only from 2000 to 2200; if you set the Y axis scale to 0 to 2500, the results from each experiment would look very similar to each other.
The difference in mean between your results (~2100) and my results (~3100) is probably just due to different world sizes. I presented standard deviation while you graphed standard error.
If you histogram the results, they seem to follow an exponential distribution.

Moving downhill a patch variable while maintaining a global direction

I am building a dispersal model in a landscape with different landcover types: urban, forest, residential etc. Each one of these landcover types has a resistance-to-movement patch variable and they are found in clusters of patches:
urban - 4 + random-float 1.0
residential - 9 + random-float 1.0
forest - 1 + random-float 1.0.
I would like my turtles to move downhill the resistance values from one forest patch cluster to another. The issue I am having however, is that because the resistance values are not distributed in a gradient, the turtles will stay put if the resistance of its neighbours is the same or move backwards away from the forest patches if the resistance is lower in that direction.
Most models in the model library that use the downhill/uphill functions have gradient landscapes such as mountains, but mine are randomly distributed.
How can I get my turtles to move downhill while also maintaining a global direction towards the forest patches so that they do not move backwards?
Thanks!
That seems rather like a modelling problem than like a Netlogo problem to me.
How would you like the turtles to move, if they have visited all forest patches in that cluster?
Two ideas:
they move to the patch with the smallest resistance from all neighbor patches, that are closer to their destination, e.g. with min-one-of
face destination ; destination is a patch
; could be a global variable set in setup
let candidates (patch-set patch-right-and-ahead 30 1
patch-left-and-ahead 30 1
patch-ahead 1)
move-to min-one-of candidates [value] ; turtle moves to the candidate patch with the smallest "value"
or, if they have knowledge of the whole landscape, they could use a path search algorithm such as A* in order to minimize the sum of resistance on their path.

NetLogo: Measure total area covered by turtles

After my NetLogo simulation, I would like to measure the total area covered by only the turtles. Is there a simple way to implement this in NetLogo, or will I have to do this in another program?
My simulation has clusters that form and I would eventually like to calculate the cluster agent density. 1
NetLogo is not aware of where the edge of the turtles’ shapes are. So, if you are trying to work out what proportion of the screen has shapes on it, you need to do some complicated programming to calculate where the edges of the shapes are, how they overlap and so on. However, if all you care about is where the turtles are, then it's much easier. For example, to work out the proportion of patches where there are at least one turtle, you could do:
count patches with [any? turtles-here] / count patches

Move agent based on probability/point attribute value and point distance, NetLogo

I have the set of points implemented in netlogo and agents are moving from one point to another. Each point has a weight (number approximately between 0 and 9, its not a probability). What I want to made is a simple rule.
I want to give all points probability of visit by the value of weight.
So the next point which will be visited by agent should be calculated by the probability based on point weight and the closeness point (more close point - bigger probability), but that closeness isn't so much big factor as the point weight. For example, I would like to set in formula that closeness is twice lower factor then point weight.
I investigated rnd extension, but I am not sure how to append probabilities to points which I am having a lot (approximately around 250 points).
You're on the right track with the rnd extension. From that extension you need the weighted-one-of primitive and you just put the formula into the reporter block.
I think this is something like what you want. It's a complete model so you can run it and see what it does. The reporter block uses the weight and the distance in the probability. Since you want the probability to be larger for closer, then I have used the inverse of the distance, but you could simply subtract the distance from something like the maximum distance in the model. You will also need an appropriate scaling factor (replacing the 10 in my example) so that the weight is worth twice an average value of closeness.
extensions [rnd]
turtles-own [weight]
to testme
clear-all
create-turtles 10
[ setxy random-xcor random-ycor
set weight 1 + random 3
set size weight
set color blue
]
ask one-of turtles
[ set color red
let target rnd:weighted-one-of other turtles [ 2 * weight + 10 / distance myself ]
ask target [ set color yellow ]
]
end

To assign path cost to polygons in a buffer

I would like to build least-cost paths between the polygon (e.g. polygon A) where there is a wolf and all polygons that are situated in a radius of 3 km around the wolf and to found the polygon that has the lowest cost (see also How can I increase speed up simulation of my least-cost path model. Then, the wolf moves toward this polygon (e.g. polygon B). The process is repeated from the polygon B and so forth.
to-report path-cost
ask wolves [
set my-list-of-polygons-in-buffer ( [plabel] of patches in-radius 3 )
set my-list-of-polygons-in-buffer remove-duplicates my-list-of-polygons-in-buffer
set my-list-of-polygons-in-buffer remove [plabel] of patch-here my-list-of-polygons-in-buffer
set my-list-of-polygons-in-buffer remove "" my-list-of-polygons-in-buffer
foreach my-list-of-polygons-in-buffer [
let ID-polygon-in-buffer ?
ask patches with [plabel = ID-polygon-in-buffer] [
set path-cost calculate-LCP [my-ID-polygon] of myself ID-polygon-in-buffer] ] ]
report [plabel] of (min-one-of patches [path-cost])
end
1) From the polygon A, the code works because only the polygons in the buffer have a path cost. But from the polygon B, there is a problem. The code finds the polygon that has the lowest cost among polygons that are situated in the buffer of polygon A and in the buffer of polygon B. The code has to find only the polygon that has the lowest cost among polygons in the buffer of polygon B. How can I resolve this problem? Have I to reset the state variable “path-cost” for each polygon patch before to calculate path cost from polygon B?
ask patches [
set path-cost 0 ]
2) If a same polygon is included in the buffer of both three wolves, how the path cost will be assign to state variable "path-cost" for each patch polygon i.e. is it possible to have 3 x cost value for a same polygon ?
3) In the figure below, why does the least-cost path not follow a straight line? The least-cost path takes the patch diagonal instead of the patch side that is shorter.
Thank you very much for your help.
I'm going to answer your questions in reverse.
3) As Seth mentioned, this is a separate question. That said, here's the answer. By default, all links cost the same amount. That is, diagonal links cost the same amount as horizontal links. Thus, there's no reason to prefer the horizontal links over the diagonal ones. The cost is actually the same. You can use link weights to resolve this. Just make a new link variable (cost or something), set it to the length of the link, and then ask for the shortest weighted path using that variable.
2) Not really. You could set path-cost to a list that contains the values for the different wolves, but I wouldn't recommend. I don't think using a patch variable is the right way to go here.
1) You would have to set path cost to 0, but there's a better way. Also, your procedure only returns the least cost path for the last wolf run (since the wolves keep overwriting the patch variables).
First, I think that you actually want path-cost to be a wolf procedure (I would also name it something like least-cost-polygon as it's actually reporting a polygon). That is just, it just gives the nearest polygon for a wolf. So here is a simplified version that does that and doesn't store anything in any patch variables (thus avoiding collision because nothing is overwritten):
to-report least-cost-polygon
[ plabel ] of min-one-of patches in-radius 3 with [ plabel != [plabel] of myself ] [
calculate-LCP [ my-ID-polygon ] of myself
]
end
Yes
If only one wolf is computing costs at a time, then there's no problem. After one wolf has finished, that wolf's values for path-cost aren't needed anymore, so it's OK for the next wolf to overwrite them. Right? If it's not OK — if you have a need to keep the information around for later — then I'd suggest using links to store it; that's the usual way of storing many-to-many information in NetLogo.
Your questions 1 and 2 are about the same issue, but this is something entirely different. Please ask one question at a time. In any case, it doesn't seem to me like we can possibly debug this for you with the information we have. Apply standard debugging techniques.