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.
Related
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.
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?
I have a problem with following the nearest candida (breed) by another turtle - neutrophil (breed). Candidas can't move and neutrophil looks for the nearest candida in the area, face to him and go forward. Everything is fine when world is allowed to wrap. Then neutrophils go througt the "walls" and chase candida.
BUT the point is that world can't wrap.
So I created condidion with help another model, which bounce the neutrophil, when they reach one of the max coordinates. But now they keep bouncing from the walls and don't looking for another target.
I will be very thankful for help.
to lookfor ;;if meet candida in near area - chase, if not - continue looking for
ifelse any? candidas [ chase ] [ move ]
end
to chase ;;set the target on the nearest candida, face to them and move one step to him
set nearest-candidas min-one-of candidas [ distance myself ]
face nearest-candidas
bounce fd 1
end
to move
bounce
fd 2
end
to bounce
if abs pxcor = max-pxcor [ set heading (- heading) ] ;; bounce off top and bottom walls
if abs pycor = max-pycor [ set heading (180 - heading) ]
if abs pzcor = max-pzcor [ set heading (- heading) ]
set nearest-candidas max-one-of candidas [ distance myself ]
end
edit: Oh, you are in NetLogo 3D. That changes everything, unfortunately. Without being able to prevent the world from wrapping, there is no easy way of doing this. If you're feeling adventurous, you could try to find a way of ensuring that the nearest turtle is on the "right side of the wall" by triangulating with other turtles in the world. It wouldn't be easy though, but I could see that working. Good luck.
Outdated response:
I think the problem might be that in your bounce procedure, you have
set nearest-candidas max-one-of candidas [ distance myself ]
Using max-one-of sets the candidas to the one furthest AWAY from the neutrophil. You have it correctly in your chase procedure in which you set it to min-one-of (that is min one of, not max one of). Does changing that give you the behavior you were expecting?
Imagine a city with streets that people move around the city and streets. How can i say to the turtles that move just in a certain ways or don't move in some ways(patches)?
Some relevant models in the Code Examples section of the Models Library that I suggest you look at and study:
Look Ahead Example: turtles look ahead of them before moving so they don't step on blue patches
Wall Following Example: turtles treat brown patches as "walls", walking alongside them
In Look Ahead Example, the crucial snippet of turtle code is:
ifelse [pcolor] of patch-ahead 1 = blue
[ lt random-float 360 ] ;; We see a blue patch in front of us. Turn a random amount.
[ fd 1 ] ;; Otherwise, it is safe to move forward.
In Wall Following Example, the behavior of the turtles is more complicated, so the code is a more complicated, too.
I am using an existing model in netlogo called Chemical Equilibrium and am adding some more code. I want to add turtles (catalyst) which have no effect on the reaction/other turtles but speeds up the FORWARD reaction, which has been defined as follows:
to react-forward [t]
ask t [ set color red ]
set color green
rt random-float 360
jump 2
end
I was thinking that I should put a switch and a slider, make the turtles into whitemols or I do a turtles-own [catalyst] and then define that like I have done with temperature and pressure. I tried the following but it didnt work.
turtles-own [speed catalyst]
crt whitemols
[ set color white
randomize
set speed 1
]
I know the above code is incorrect but am not sure how to code this particular feature.
There are many ways to do this, of course. I can't tell what is going on in your program from the little snipped you include.
One way would be to have the catalyst be of a different breed:
breed [catalysts catalyst]
breed [chemical-x chemical-x]
;and so on
;then the forward reaction is sped up by the existence of catalysts
to react-forward
let num-catalysts count catalysts
;speed up by num-catalysts
;...
end