To assign path cost to polygons in a buffer

Question

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.

Answer 1

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

Answer 2

1. Yes

2. 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.

3. 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.