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
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.
I am running my Netlogo model in behavior space. In my model, I created a turtles-own variable called consumption-rate. I want to export the consumption-rate of each turtle for every tick of my run. From my understanding of behavior space, I would somehow put consumption-rate in the box that says "Measure runs using these reporters" in order for it to be exported, but I keep getting different errors every time I try. For instance I mostly get an error that says "Experiment aborted due to syntax error: Expected reporter". I also need to export a patches-own variable I created called quality for every patch in my model at each tick, and I have the same issue. All the examples for this part of behavior space online just show "count turtles" or something similar. Am I able to export a turtle or patch variable there? If so, what code would I use?
I took a shot into the blue and tried using primitives like "show consumption-rate" or "report consumption-rate". I am unsure of the format of code I would even begin to use to give me those exports. Any advice or help? I also tried just typing in "consumption-rate" or "quality" in the "Measure runs using these reporters" box, but got an error saying I can't use a turtle or patch variable in an observer context, how can I make those into the observer context? Anyway around that?
patches-own [ quality ]
turtles-own [ consumption-rate ]
to setup-patches
ask patches
[set quality (2 + random 8)
set pcolor scale-color green quality 1 10 ]
end
to Go
ask turtles
[ calculate-consumption ]
end
to calculate-consumption
set consumption-rate ( [ quality ] of patch-here ) / ( strength-of-competition * count turtles-here )
end
You have a conceptual mismatch. There is no problem in exporting a turtle or patch variable in BehaviorSpace, but you haven't told NetLogo which variable to export. You need to specify whether it's that variable for all turtles, or only some turtles or whatever.
Here's a modified version of your code so that it is complete and self-contained.
globals [strength-of-competition]
patches-own [ quality ]
turtles-own [ consumption-rate ]
to setup
set strength-of-competition 0.4
ask patches
[ set quality (2 + random 8)
set pcolor scale-color green quality 1 10
]
create-turtles 300 [setxy random-xcor random-ycor]
end
to go
ask turtles
[ calculate-consumption ]
end
to calculate-consumption
set consumption-rate quality / ( strength-of-competition * count turtles-here )
end
Run this with a BehaviourSpace setup that has [consumption-rate] of turtles as the reporter. Also put 2 in the time limit. You will get the output you requested.
A good tip for working with BehaviorSpace when you are new to it, is to set up a monitor on your interface for each value that you want to save in your output. Get the monitors showing what you want to export and then simply take the code that you ended up with and put it in the reporter box. The advantage of doing the monitor step is that it forces you to get your thinking right without going down the rabbit hole of whether it is a BehaviorSpace issue.
I am trying to build a model in which turtles decide to change colour depending on their environment in a network.
The approach would be to "check" the colour of the surrounding turtles and then set an if statement for the turtle in question to switch colour (there will only be 2 colours).
Specifically I would like to know how can a turtle "see" or check other turtles' colour (or other properties).
If possible I would also like to create a slider for "how many links away" can turtles see their neighbouring turtles' (or neighbours of neighbours, etc) colour.
I am new to both Netlogo and Stackoverflow, so please let me know if I should make any modifications to my model and/or question.
Thanks!
Welcome to Stack Overflow! Typically you'll want to stick to a single question per post, both for simplicity and for the benefit of future users with similar questions. As well, in cases where its applicable you should try to include some code to show what you've tried so far, as well as any setup necessary- you want to make a minimal, complete, and verifiable example. In this case, I think you're okay since your questions are clear and well explained, but if you have more complex questions in the future you will be more likely to get useful answers by following those guidelines.
For your first question, it looks like you want the of primitive- check out the dictionary entry for details. of can be used in a few ways, including allowing agents to check the value of a variable (such as color) of another agent. Check out this example code:
to setup
ca
reset-ticks
crt 10 [
setxy random 30 - 15 random 30 - 15
create-link-with one-of other turtles
]
end
to go
ask turtles [
set color [color] of one-of link-neighbors
]
end
Every time the go procedure is called, one of the turtles changes its color to the color of one of its link-neighbors. If you run it long enough, all connected turtles should end up with the same color.
For your second question, I suggest you check out the Nw extension, which is an extension built to deal more easily with Netlogo networks. Specifically, have a look at nw:turtles-in-radius, which should work with your slider approach. To get it working, include the extension using
extensions [ nw ]
at the start of your code. Then, assuming the same setup as above, you can play around with something like
to network-radius
ask one-of turtles [
set color red
ask other nw:turtles-in-radius 2 [
set color white
]
]
end
When you call the network-radius procedure above, you should see one turtle turn red, and any turtles within 2 links of that turtle turn white. To switch to a slider, just swap the "2" out for your slider variable. Hope that helps!
I'm relatively new to NetLogo, and I'm working to model moose density in New Hampshire and its correlation to winter tick parasitism.
I'd like to program my moose agents to move randomly within a set home range (~5km2), that originates from the randomly chosen patch they first enter the model on.
I'm not really sure how to bound agents based on area, rather than just patch color... Any suggestions on how to do this would be most appreciated!
Thank you!
General stackoverflow tip: typically, stackoverflow encourages specific programming questions. So including the code you've actually tried so far is generally preferred.
Alright, on to your problem.
One really simple way to do this is, first, store the mooses' starting patch. Second, when the moose is moving around, check the distance to the starting patch. If the distance exceeds the starting amount, have the moose towards the starting patch. Here's some template code to give you ideas:
breed [ mooses moose ]
mooses-own [
starting-patch
]
to setup
clear-all
;; only using one moose as it's easier to see the behavior
create-mooses 1 [
setxy random-xcor random-ycor
set starting-patch patch-here
]
reset-ticks
end
to go
ask mooses [
move
]
tick
end
to move
;; If farther than 10 patches from starting patching, take a step towards starting patch, otherwise, move randomly
ifelse distance starting-patch > 10 [
face starting-patch
] [
rt random 90
lt random 90
]
fd 1
end
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.