I am wondering how to, after a number of ticks, create 10% more of the charging-poles and how to put that in code.
I now have
if ticks = (4032 + 4032)
[ask n-of (count aantal-laadpalen * 0.1) [create-laadpalen] ]
where aantal-laadpalen and create-laadpalen translated to English is the number-of-chargingpoles and create-chargingpoles.
This doesn't seem to work. Hope you can help me out!
Replace the whole ask n-of part with just:
create-laadpalen (count aantal-laadpalen * 0.1)
That's if you want the new agents to be created with default values. If you want the new agents to begin their lives as clones of their parents, then follow Alan's suggestion to use hatch:
ask n-of (count aantal-laadpalen * 0.1) laadpalen [ hatch 1 ]
Alan's suggestion to use sprout might also be appropriate if you want to place the new agents on random patch centers, instead of starting them at the center as create-laadpalen would do.
Related
Thank you for the help you provide on the community. So I am trying to create links between agents that come within a radius of 1 of each other. If the turtles do not come within a radius of 1 of each other for 16 ticks, the link automatically dies. So technically, one link might start at tick 200 and has to die at tick 216 unless it is "renewed" however another link can start at tick 250 and has to die at link 266. However, if I use ask links it changes for all the links.
So my question is how to say something like : ask the link that was formed at tick xx set die time at xx+16 if ticks = xx+16 [die].
Also how do I renew the links so when two agents with a link come in contact again they set a new start and die time for the link between them?
Thank you very much. I know I should only ask one question at a time but I guess they might be related and can be solved together. Thanks in advance.
Two equivalent ways come to my mind.
One way mimics the logic that you expressed in your question:
links-own [
time-to-die
]
to create-links
ask one-of turtles [
create-links-with one-of other turtles [
set time-to-die (ticks + 16)
]
]
end
to check-condition
ask links [
if (link-length <= 1) [
set time-to-die (ticks + 16)
]
if (time-to-die = ticks) [die]
]
end
The other way creates a counter where each link keeps track of how long its two ends have been apart:
links-own [
time-apart
]
to check-condition
ask links [
ifelse (link-length > 1)
[set time-apart time-apart + 1]
[set time-apart 0]
if (time-apart = 16) [die]
]
end
If we want to be precise, the first approach will be a bit lighter because links will not have to set the value of time-to-die at every tick (while, in the second approach, links set the value of time-apart at every tick), but I guess this advantage might be so small that you should probably just prefer the one that best fits the overall logic of your model.
In any case, the key point is that there is no problem in asking all links to update & check their condition: each link will perform its calculations and checks based on its own situation, so there is no problem in handling different links being born and having to die at different points in time.
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.
The model I am working on simulates a group of workers working on a team project. I am trying to add a on/off switch titled "replacement." The intended outcomes are:
When it is on:
30% of existing turtles of breed employees die, and equal number of new turtles are introduced.
When it is off:
No turtles die, and all turtles generated at setup will work on the project from start to finish.
The purpose of killing off the turtles is the turtle-own variable "skills." I am trying to simulate a scenario where people resign from a company and new people are hired, which will result in a change of skill level.
If it is easier to change the skill level of 30% of turtles every 20 ticks instead of killing/regenerating, that would be perfect, but I was unable to figure it out.
My attempt at this problem is shown below. It runs without any errors, but I confirmed that it's not killing/respawning 30% of turtles every set number of ticks. Any helpful guidance will be much appreciated.
to go
if all? patches [ workload = 0 ] [ stop ]
ifelse replacement [hire] [continue]
recolor
tick
end
to hire
if ticks > 0 and ticks mod 20 = 0 [
ask n-of (count employees * 0.30) employees [die]
create-turtles number_of_workers * 0.30 [
set breed employees
setxy random-xcor random-ycor
set shape "person"
set color black
set size 1
set skills random-float 1]
]
ask employees [move]
ask leaders [move]
end
to continue
ask employees [move]
ask leaders [move]
end
I ended up finding the answer on my own. Removing "ticks > 0 and" from the hire function solved it :)
From your description of the problem, I am not sure why removing the if ticks > 0 and solved it. I am wondering if you perhaps had the "replacement" variable set to false, and the hire procedure would not have been called.
Regardless, you also asked about just changing the skill set every 20 ticks. You could do this:
to go
if all? patches [ workload = 0 ] [ stop ]
if replacement? and ticks mod 20 = 0 [hire]
move-people
recolor
tick
end
to hire
ask n-of (count employees * 0.30) employees
[ set breed employees
set skills random-float 1
]
end
to move-people
ask employees [move]
ask leaders [move]
end
I also reorganised slightly in a way that is intended to make it easier to debug. You had the moving in both the "hire" and "continue" procedures. Clearly you want that to always happen, so that is now explicit in the "go" procedure (and I changed the name to be more descriptive).
Now the "hire" procedure simply changes the skills of existing employees. Note, however, that any other variables (such as leader, size, colour and position) are not affected. If you go this approach, you may want to indicate in some way that they are new hires.
The "hire" procedure is now clearly called when the "replacement?" switch is on and also a multiple of 20 ticks. If you have part of the condition in the calling procedure ("go") and part in the procedure itself ("hire") then it's easy to forget the existence of whichever half you are not looking at.
I am trying to change a variable (score) of a particular agent in the agent set if it meets the specific condition of a patch. This is called by an another agent. To be more clear. My idea is for instance if there is a breed (horse) and it sees the patch (grass) and it is standing on another breed (vertices - since horse move along a path connected by nodes represented by vertices) - a score variable to added to vertices-own where if the grass quality <=3, it would add a score to the vertex on which it stands.
ask horses[
ask patches in-cone 50 60 [
if grass-quality <= 3 ask vertices with [min-one-of vertices in-radius 0 [distance myself] [set vertex-score vertex-score + 1 ]]]]
I know something is wrong with this code logic. I am trying to convert my mentioned thought into codes. Kindly suggest me.
Thank you all.
Regards,
Heng wah
NetLogo agent (turtle) positions are continuous numbers so it is generally wrong to try and say something like 'if another turtle is where I am'. While you may have got there using move-to, it's probably safer to have the horse identify a vertex that is very close to it rather than in the exact position. You have used radius 0 but I'm going to change that to 0.001 to allow for potential errors in position.
ask horses
[ if any? patches in-cone 50 60 with [ grass-quality <= 3 ]
[ let my-vertex min-one-of vertices in-radius 0.001 [distance myself]
ask my-vertex
[ set vertex-score vertex-score + 1 ]
]
]
]
This is not tested, but I have simply reorganised your code. You had some bracketing issues and you were also asking vertices to find the closest vertex (which would have been itself), rather than having the horse find the closest vertex.
It's also not necessary to separate the let and the ask but I thought that would be easier for you to see how it works.
This question is built off my previous 2. I've been working to get a rank-ordered list for my turtles, ranked by an owned factor. They're then required to move in ranked order. That part works perfectly fine, and the code can be found at: Assigning turtles a ranked number in netlogo
The problem: using that code, they're moving in the correct order but instead of moving once, the program seems to be continuously re-running it for every turtle in the list so the first turtle in a world of 10 ends up moving 10 times, the second moves 9 times, etc.
I'm completely stumped on this, but I need it to stop. They're supposed to move once and be done for that tick. Ideas?
The list creation code is:
let rank-list sort-on [sociability] turtles
let ranks n-values length rank-list [ ? ]
(foreach rank-list ranks [ask ?1 [set social_rank ?2] ] )
;;you can replicate the problem with this movement proc, or the full code in the link above
ask turtles [foreach rank-list [ask ? [set heading 270 forward 1]]]
In the line:
ask turtles [foreach rank-list [ask ? [set heading 270 forward 1]]]
You're asking each turtle to execute a command for each turtle in your rank-list.
Just drop the ask turtles part.
As a more general note: foreach is to lists what ask is to agentsets. They both do the same basic thing, which is to perform a command for each item of a "collection". Agentsets are unordered collections of unique agents. Lists are ordered collections of possibly duplicated items of any type.