Please let me preface this with I am not a programmer by trade. I am a social scientist using M&S for some research. That being said, my goal is to use ABM (Netlogo) to create a model of state antifragility. That is a model of states that get better under stress rather than deteriorate or are resilient (return to their pre-stress levels).
The idea for this model is simple. Create agents (states) that have three properties-loops, capacity and performance. The Capacity of a state is defined as it's Agility + it's Learning + it's Power Conversion. ( I've done some regression analysis to see what the relationship between each of these variables and stress is and they are listed below. ) The state also has two loops-fragile and antifragile that are always running, but depending on the performance value and the stress value only one of those loops will activate to update the capacity/performance values to deal with the next stress. Finally, a state's performance ties all those together. That is, it is a function of capacity and stress.
States randomly roam about the world full of shocks (red patches with an intensity value). When the state comes across the patch, it interacts with that patch. To interact, it activates a loop and then performs and update of its capacity and it's performance for the next stress. This happens until a state dies (it's too fragile and fails) or it becomes the maxium value of antifragile.
UPDATED CODE BELOW ( 22 July) JenB, I took your advice and stripped it down to it's basic parts by removing the looping functions. Eventually, I'd like to get there in a future iteration, but for now I removed it. The code below is my stripped down, updated version. Where I am stuck is the stop movement function.
Starting with the latter, I am still unsure how to set something true or false. I kept getting an error about a string not a value for that command. (Again, I am really, really a beginner at this and even reading the Netlogo Dictionary isn't that easy for me.)
Now that I think about it there is a third thing. I'd also like to randomize the value of the red patches ("shocks"). I believe the way I have it set up right now is that they all have the same value, but I'd like some to be bigger or smaller.
Thank all of you for all your help in this journey!
Please see the code below:
breed [states state]
states-own [learning powerconversion agility performance category]
patches-own [intensity]
;; TO SET UP ;;
to setup
clear-all
grow-shocks
set-default-shape states "dot"
create-states 10 [
setxy random-xcor random-ycor
set color blue
set size 2.5
set performance random 100
set learning random 10
set powerconversion random 10
set agility random 10
]
reset-ticks
end
;; TO GROWN SHOCKS ;;
to grow-shocks ;; to grow shocks in the international environment do the following:
ask n-of number-shocks patches [
set pcolor red ;; make them red
set intensity random 10 ;; set their intensity to a random number between 0-10
]
end
;; TO GO ;;
to go
ask states [ ;; ask states to do the following : move, interact, update-category (AF, R, F)
move
interact
update-category
]
tick
end
;; TO MOVE ;;
to move ;; to move do the following:
right random 15
left random 15
forward 1
if abs pxcor = max-pxcor
[ set heading (- heading) ]
if abs pycor = max-pxcor
[ set heading (180 - heading) ]
end
;; TO INTERACT ;;
to interact ;; to interact with shocks do the following:
if pcolor = red [
set pcolor black set intensity 0 ;; if the patch is red, turn the patch black and set intensity to 0
update-performance ;; update-performance
update-category
]
end
;; TO UPDATE PERFORMANCE ;;
to update-performance ;; to update a state's performance do the following:
set performance (((-0.13 * learning ^ 3) + (1.89 * learning ^ 2) + (-5.72 * learning) + 8.13 ) +( 0.09 * agility ^ 3) + (1.29 * agility ^ 2) + (-3.45 * agility) + 5.57 +( 0.02 * powerconversion ^ 3) + (-0.89 * powerconversion ^ 2) + (9.93 * powerconversion) + -17.51 )
end
;; TO UPDATE STATE TYPE;;
to update-category ;; to update the state's type do the following:
if performance > 75 [ ;; if the state has a performance value of over 75, turn it green indicating an antifragile state
set color green
]
if performance < 74 and performance > 35 [ ;; if the state has a performance value between 35 and 74, turn it yellow indicating a robust state
set color yellow
]
if performance < 34 and performance > 5 [ ;; if the state has a performance value between 1 and 34, turn it red indicating a failed state
set color red
]
So I am guessing the line throwing the too large error is this one:
to activate-antifragileloop
set performance e ^ performance
end
This seems like a logic error to me. From the rest of your code, I am guessing performance numbers are generally in the range 0 to 100. Do you realise that e^100 = 2.6881171 x 10^43? It seems unlikely that you want performance to switch between numbers like 100 and numbers with 43 digits. I can't imagine a real world situation that you could be trying to represent where a key characteristic of the entities in the system has such a wildly varying value.
On the question of stopping, I would have another variable named something like done? that starts as false then you set it to true when you want it to stop. Then you can simply have ask states with [not done?] instead of ask states for any code that moves them around etc.
You said you are not a programmer. One of the best things a beginner can do is to make only minimal changes at a time. You have several problems with your code - this should almost never happen. Your life will be much easier if you only make one change at a time and get it working correctly before moving on. This is particularly important with NetLogo where it can be very difficult to work out whether something is working correctly because you are modelling systems that interact - how do you know whether the interaction is producing the results or a bug is producing the results?
Related
I am quite new to NetLogo, so I need some help figuring out a few things.
I have a requirement to generate turtles at random points and intervals when the go button is clicked. I have written the code mentioned below, but it generates turtles only when I click on the go button, and they are not moving properly. The go button I am using is a forever one, not the single-step button. Kindly help me where I am doing wrong.
to go
repeat num-students[
every t [
set t random 60
create-students 1 [
set xcor random -32 - 32
set ycor random -13 - -15]
ask students [
set size 2
set color blue
set heading ( 90)
forward random 10
]]]
end
I strongly recommend not using "every" -- it executes something every specified number of seconds in real time, which is very different from at random simulated times. You need code that decides at which ticks turtles are created. (I did not even know "every" existed until seeing this and have never seen it used.)
My first suggestion would be to indent your code, that makes it much easier to see which command fits into which block. You can do this by simply highlighting all of your code and clicking tab.
I am not very familiar with the every primitive but the following code works as intended and I can't seem to reproduce your problem of no extra turtles being made. Maybe it is just that your time interval is too big?
to setup
ca
set num-students 5
set t random 5
end
to go
every t [
set t random 5
create-students 1 [
set xcor random -32 - 32
set ycor random -13 - -15
]
ask students [
set size 2
set color blue
set heading ( 90)
forward random 10
]
if count students >= num-students [stop]
]
end
I removed the repeat num-students[] part since it didn't add anything to the code. It just makes you repeat the every command a few times inside each tick. Instead, I used if count students >= num-students [stop] in order to stop when the desired amount of students is reached.
Is it possible to subtract previously diffused values?
I have a land-use model where residential use (yellow patches) diffuses its land value with the diffuse primitive:
diffuse land-value 1
In the first image below, land value is represented as white tones, the brighter the tone, the higher the land value. Residential use sometimes abandons the patch, but their land value influence stays (second image). Is there a way that, when the land use disappears, the value it previously diffused to all patches be subtracted and also disappear?
Following comments under the question and following Luke's suggestion of framing the diffusion of land-value as a function of distance instead of a recurring diffuse, I have set up the following solution (in point 1).
Below (in point 2), you find a possible approach (not fully coded, but sketched-out enough) for addressing the issue if you want to stick to diffuse.
1 - Approach with function of distance
What happens here is that, when a patch gains residential status (to create-residence), all other patches in a certain radius calculate how much spill-over land-value they get based on the residential value of the new residential patch and on how much it is distant (to-report diffused-value).
The advantage of this approach is that this calculation is fully replicable at any moment because it is based on two constants: the distance between patches and the initial residential value of the patch in question (for which I created the patches-own own-residential-value, distinct from the general land-value).
For this reason, when a patch loses residential use (to dismantle-residence) it is possible to perform the same calculation but, instead of having patches add diffused-value to their land-value, they will subtract it.
I think the code I place below best illustrates its functionality if you create the create-residence and dismantle-residence buttons in the Interface, and play with them to see how overlapping land-values add and subtract in the View.
globals [
; Agentsets for patches.
residence
non-residence
]
patches-own [
land-value
own-residential-value
]
to setup
clear-all
set non-residence (patch-set patches)
set residence (patch-set)
end
to create-residence
let new-res one-of non-residence
ask new-res [
set non-residence (patch-set other non-residence)
set residence (patch-set self residence)
set own-residential-value (random 10) + 1
set land-value (land-value + own-residential-value)
set pcolor yellow
diffuse-value
]
update-colours
end
to diffuse-value
ask other patches in-radius 10 [
set land-value (land-value + diffused-value)
]
end
to dismantle-residence
let target one-of residence
ask target [
set residence (patch-set other residence)
set non-residence (patch-set self non-residence)
; As opposed to 'to create-residence', where 'diffuse-value' is at the end of this block of commands,
; here 'subtract-value' has to be placed before the patch updates its 'own-residential-value' to 0,
; because that value is needed to calculate 'diffused-value'.
subtract-value
set land-value (land-value - own-residential-value)
set own-residential-value 0
]
update-colours
end
to subtract-value
ask other patches in-radius 10 [
set land-value (land-value - diffused-value)
]
end
to-report diffused-value
; Here, 'myself' is the new residential patch (as 'new-res' in 'to create-residence') or
; the new non-residential patch (as 'target' in 'to dismantle-residence').
let d distance myself
let v [own-residential-value] of myself
report v * (0.9 / d) ; Just an arbitrary function of value and distance.
end
to update-colours
ask non-residence [
set pcolor scale-color white land-value 0 15
]
end
2 - Approach if sticking to diffuse
I have though of an approach for this case too, but I also want to understand if diffuse really is what you want to use.
As we know, diffuse is a zero-sum game: what is diffused by a patch is also lost by a patch.
Therefore, I imagine you will not be just using diffuse land-value 1, because in that case land-value of the residential patch will be 0 after one tick, will very slightly recover on the subsequent tick, and will then progressively approach 0 from the third tick on.
For example, the following code gives the results as in the table below:
patches-own [
land-value
]
to setup
clear-all
reset-ticks
ask patch 0 0 [set land-value 50]
end
to go
diffuse land-value 1
tick
end
I doubt this is anything you are interested in replicating, so I assume the approach would be something like:
patches-own [
land-value
temp
]
to setup
clear-all
reset-ticks
ask patch 0 0 [set land-value 50]
end
to go
diffuse-value
tick
end
to diffuse-value
ask patches [
set temp land-value
]
diffuse land-value 1
ask patches [
set land-value (land-value + temp)
]
end
However, I think that even in this case diffuse seems to be not fit for representing a residential value spreading to near-by areas. By using the code above, in fact, the result is the following:
The table above shows that, in 15 ticks, the patch which should be the one diffusing some value in the area experienced a 93593% increase (no, I didn't forget any decimal point!) in its land value. I know of course this might be mitigated with some formula, but I think it shows the tendency of diffuse in this case: to create an escalating positive feedback between patches, so that a small residential value grows without control.
I'm not the expert of residential values here, but I felt these results (from both the former and the latter use of diffuse) were worth pointing out from a NetLogo perspective.
That said, if the idea is to stick to diffuse...
patches-own [
land-value
own-residential-value
residential-start
temp
]
to setup
; Some code.
end
to go
; Some code.
end
to create-residence ; Executed by the observer. This procedure cannot be executed by the patch becoming residence because it contains 'diffuse'.
let target ; <- Identify here the patch that needs to become residence.
ask target [
; Set 'own-residential-value' to something.
set land-value (land-value + own-residential-value)
set residential-start ticks
]
; Have some code here that uses 'diffuse own-residential-value'.
end
to dismantle-residence ; Executed by the observer. This procedure cannot be executed by the patch being dismantled because it contains 'diffuse'.
ask patches [set temp 0] ; This is crucial in order to avoid any overlap among patches when using 'diffuse'.
let target ; <- Identify here the patch that needs to be dismantled.
let time-as-residence (ticks - [residential-start] of target)
ask target [
set temp own-residential-value
]
repeat time-as-residence [
; Insert here the exact same code that
; was used for using 'diffuse' but
; diffusing the 'temp' variable instead
; (e.g. 'diffuse temp 1').
]
ask patches with [temp > 0] [
set land-value (land-value - temp)
]
end
What happens above is that, whenever a patch loses residential use, the program performs exactly the same number of diffuse operations as it performed when actually diffusing land-value during the residential life of the patch at stake, but on temp instead of land-value. This way, all the surrounding patches will store in temp the same value they gained over time from the patch being dismantled - so they can subtract this value from their current land-value.
The success of this approach depends on the ask patches [set temp 0] statement: given that diffuse operates on each patch, by setting all temp to 0 and then doing ask target [set temp own-residential-value] we make sure that we only reproduce the pattern of value-diffusion that can be attributed to the patch being dismantled - avoiding any overlap that might have occurred over time, when patches may have gathered (and then re-diffused) value from other residential patches.
(This is based on the assumption that you use diffuse at every tick, as you said in a comment to the question. Even if that ceases to be the case, it will be easy to set time-as-residence in an alternative way according to the number of times that diffuse took place since a particular patch became residential)
Potential problem This is something that you will have to untangle yourself, but consider that there remains a possible issue: you have to decide whether you want to diffuse own-residential-value or land-value, with both options presenting some problem.
Diffusing own-residential-value seems intuitive to me, since that is the added value; however, this means that the diffused value would go into own-residential-value of the other patches (and not into their land-value) even if they really do not have any residential value of their own, which will create the need for extra computation (a possible option could be to rename own-residential-value to something more appropriate, like residential-value, and create a further tot-value patches-own variable that is updated at every tick as set tot-value land-value + residential-value).
On the other hand, diffusing land-value would be more straightforward in terms of coding (land-value would just propagate to other patches' land-value) but seems less precise based on what I can understand, given residential patches would be propagating land-value which often will not be just the new residential value that they bring, but also the result of that positive feedback discussed before, building on other patches' residential values.
Conclusions
While I'm quite confident that the second approach is viable and technically good, I definitely prefer the first based on the doubts that I expressed over the use of diffuse for this particular goal (at least based on the understanding I have of your intentions, which I might not understand fully) - and the feeling that a function of distance looks like a neat approach to diffusion of value in this scenario.
I am working on traffic simulation using netlogo. In attached image, i want to extend the road grids into two way road grid i.e. increase the width of each road grid. Here is the code that will need update but I am unable to do it myself.
set roads patches with [
(floor ((pxcor + max-pxcor - floor (grid-x-inc - 1)) mod grid-x-inc) = 0) or
(floor ((pycor + max-pycor) mod grid-y-inc) = 0)
]
Here is code that makes wider roads.
I tried to separate out the left lanes from the right lane so you can see what is happening if that helps you figure out where the cars should go.
I also separated the x-offset and y-offset values so you can adjust the grid in case you want to.
This code assumes that max-pxcor = 32, max-pycor = 32, and patch size = 6, so that the whole thing fits the same physical view area.
globals [
left-lanes
right-lanes
roads
]
to setup
clear-all
;; set the number of patches between lanes
let grid-x-inc 13
let grid-y-inc 13
;; offsets move the lanes slightly more to the right or further up
let x-offset grid-x-inc - 3
let y-offset -2
;; color the background
ask patches [set pcolor lime]
;; create the lanes
set left-lanes patches with [
(floor ((pxcor + max-pxcor - x-offset) mod grid-x-inc) = 2) or
(floor ((pycor + max-pycor - y-offset) mod grid-y-inc) = 2)
]
set right-lanes patches with [
(floor ((pxcor + max-pxcor - x-offset) mod grid-x-inc) = 1) or
(floor ((pycor + max-pycor - y-offset) mod grid-y-inc) = 3)
]
;; color the lanes for debugging purposes
; ask left-lanes [set pcolor yellow]
; ask right-lanes [set pcolor (yellow - 1) ]
;; merge left and right lanes into roads
set roads patches with [ member? self left-lanes or member? self right-lanes]
ask roads [ set pcolor yellow]
reset-ticks
end
to go
tick
end
OK, now I see what you are trying to do. You have a bigger problem than just drawing wider roads.
And I see now that you probably just want traffic just to go in one direction on each wider road, instead of simulating traffic going both directions.
OK, so you need to solve several design problems before anyone can answer your question about code.
(1) What do you want to display? Do you want just a wider yellow road? Or do you want pretty roads with lines along the sides like in the "Traffic 2 Lanes" model?
(2) Do you want the cars to actually use the two lanes, and include behavior such as changing-lanes and passing, like the "Traffic 2 Lanes" model?
AND ... the "Traffic 2 Lanes" model already includes all the logic and code you need for drawing wider roads, which would solve one of the two related questions you originally posted. Even if you only want fat yellow roads, not fancy roads with lines on them, the same logic could be used and you can just remove the part that draws lines.
This answers your first question:
i want to ... increase the width of each road grid.
BUT ... You actually asked a much harder question in your comment and in your original post's title:
i want to extend the road grids into two way road grid
I am not sure whether your original meaning has survived translation into English.
To me, a "two way road" means one road with two lanes, where there is traffic going both directions on the same road. Some cars would be heading North and some cars would be heading South.
This is far more complicated than the "Traffic Grid" problem in the Model Library In the "Traffic Grid" problem each road is only one lane wide, but it is also "one way".
Finally, I see that you did not give credit to Uri Wilensky or mention the models in the Model Library that is the source of most of the code you posted. It will be obvious to your college teacher that you copied large sections of code from someone else's work -- you should give credit to that person and cite the source of that code. It is still a major effort for your college final project to merge the logic from two models into one more complex model and get it to function.
In setup, I draw a bunch of turtles--as small circles--to display two curves defined by functions. A very simple way to do this is
ask patches with [pycor = (myfunction pxcor)] [sprout 1 [...]]
and that's what my code does at present. It's kind of wasteful, since every patch has to be consulted--in random order--for each curve, but it's simple and easy to read, and it only happens during setup.
However, there's a little bit of a pause as the curves are constructed. If I move the speed slider all the way to the right, the pause is not noticeable. If I wrap the curve display routines in no-display and display, the user doesn't see the curves being constructed, but the speed is unchanged, AFAICS. If I move the slider to the left, it takes a long time to construct the curves even with no-display; the user doesn't see the points being placed one by one, but nevertheless has to wait while twiddling her/his thumbs.
Is there a way to set the model speed programmatically (for normal, "headfull" use)? I don't want to tell users "Move the speed slider to the right, then press setup, then move it back to the center before pressing go.
If not, maybe I'll code the curves properly using loops, but I thought I'd ask. Seems like there would be a way to do this, but I haven't found anything in the dictionary or programming docs so far.
(edit: no-display, if it did help, isn't available in NetLogo Web, which I am targetting along with regular NetLogo.)
I don't believe there is. However, you are asking all patches, when you could simply ask the pxcor values. This should speed it up a lot - square root of the number of iterations if a square world. Something like:
to testme
clear-all
let counter min-pxcor
while [counter <= max-pxcor]
[ let fn-out (function counter)
if fn-out >= min-pycor and fn-out <= max-pycor
[ ask patch counter fn-out [ set pcolor red]
]
set counter counter + 1
]
end
to-report function [#invalue]
report #invalue ^ 2
end
I am trying to create a program in netlogo where there are blocks that come down the screen and when their y-coordinate reaches a certain value they reverse their direction and move in the opposite way.
So far I was able to make them move in one direction and then switch directions when they reach the critical y-coordinate value, but once they take one step in the reverse direction it glitches and they get stuck moving one step forward and one step backward.
I wanted to know if there was an else command in netlogo so I could specify that if the while command wasn't fulfilled it could reverse its direction and move without glitching.
Here is my code.
to maze
while [abs pycor < 16 ] [fd 1 wait .1]
bk 1 wait .1
end
There is no separate else keyword in NetLogo, but the ifelse command allows you to specify two blocks: one that is executed if the condition is true, and another (the "else" block) that is executed if the condition is false.
It seems, however, like you should rethink your general approach to the problem. Turtles in NetLogo always face in a particular direction, and you could take advantage of that: instead of having them "back up", you could have them turn around.
Also, it's generally ill-advised to try to do things in a while loop. If you want your turtles to repeat a behavior, a "forever button" is usually the way to go.
In the following example, you should call the go procedure from a forever button:
to setup
clear-all
ask patches with [ pycor = max-pycor - 1 ] [
sprout 1 [
set heading 180 ; head down
]
]
reset-ticks
end
to go
ask turtles [
if abs pycor = max-pycor [
rt 180 ; turn around!
]
fd 1
]
tick
end
This probably doesn't achieve exactly what you wanted, but there is a good chance that you can modify it to fit your needs.
Also note that this will work better using tick-based updates.