Skip to content

Instantly share code, notes, and snippets.

@tomsaleeba
Last active November 24, 2020 03:57
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save tomsaleeba/0c880ce515fdd14bd2ed8a60b42dbf64 to your computer and use it in GitHub Desktop.
Save tomsaleeba/0c880ce515fdd14bd2ed8a60b42dbf64 to your computer and use it in GitHub Desktop.
Pollin8 model tuning

Note: make sure you view this page on this URL with a trailing slash otherwise images won't work. More info.

What is this?

An attempt to get the model reporting the kinds of numbers that we'd expect to see based on expert opinion.

All of these runs are done including the "children inherit parent LULC" feature.

Goal:

  • crops should be dependent on wild pollinators, so pdep_y_w should be a decent number
  • the y_tot is the result so we should see it start lower and end higher
  • p_abund and y_wild should increase as the years go on as this is what the reveg is trying to achieve

General findings

  • removing the summer farm_attribute_table row does affect the spring results but only the y_tot column. It makes it much smaller in the example we explored.
  • higher half_sat values mean lower yields for a given pollinator abundance.
  • higher half_sat values mean a smaller amplitude change in yield.
  • a lower p_managed value means a lower y_tot output when all other values are kept constant.
  • with all else constants, p_managed simply moves the results up and down. The amplitude of the change stays the same.
  • drops in foraging_activity_... values mean drops in all outputs
  • large-ish movements (0.084 to 0.019) in p_abund only mean smaller movements in y_tot (0.122 to 0.104)
  • area of reveg is very important. More reveg means more pollination! It’s not just about quality, you also need enough of it.
  • we can achieve pollinator abundance of a slightly better level than 117 LULC by pushing nesting and floral resources all the way up.

Questions

  • what changes do we need to make to our CSVs to get the results we want?
  • do we only want to touch half_sat or are other values up for debate?
  • when we say we want 4% increase, do we want that as % or pp?
  • is a pdep of 0 for summer apples ok? Why even run the model if it’s not dependent on pollination?
  • how do we treat the two seasons? We probably can’t combine them. Is it even the right thing to do to have two rows for a single crop?

a baseline

The run:

  • apples
  • default tester vectors
  • 25 years
  • CSVs and reveg curve as per 4f64ed98e2faeea3723d1543056b417fc1a1e18c

At year 1, looking at the total_pollination_abundance_spring.tif raster:

  • the reveg is ~0.0011
  • the farm has 0.077-0.088 where it touches the reveg
  • model run results of:
    p_abund, pdep_y_w, y_tot, y_wild
    summer 0     0.10  1 0
    spring 0.079 0.10  1 0.100
    

Then, looking at year 25 (same raster as above):

  • the reveg has a value of ~0.0848 at the red dot (reveg blends in with the farm)

  • the reveg is not the highest value on the map. That goes to 117 (other conserved area)

  • the farm has 0.0775-0.089 where it touches the reveg; a very slight increase. Side note: on the previous default vectors, it was a more noticable increase, but only just.

  • model run results of:

    p_abund, pdep_y_w, y_tot, y_wild
    summer 0     0.100 1    0
    spring 0.081 0.100 1    0.100
    

The fact that we have y_tot already at 1 in year 1 makes me worried. How can we improve the yield if it's already as high as it can go?

increasing half_sat

The run:

  • same as above, but
  • farm attribute table CSV modified to (summer row removed, spring half_sat increased significantly)
    half_sat,p_managed,season,fr_spring,fr_summer,n_cavity,n_ground,p_dep
    -0.1,0,summer,1,0,0,0.2,0
    -0.1,0.9,spring,1,0,0,0.2,1
    +0.8,0.9,spring,1,0,0,0.2,1

At year 1, looking at the total_pollination_abundance_spring.tif raster:

  • model run results of:
    p_abund, pdep_y_w, y_tot, y_wild
    spring 0.080 0.021 0.921 0.021
    

Then, looking at year 25 (same raster as above):

  • model run results of:
    p_abund, pdep_y_w, y_tot, y_wild
    spring 0.081 0.021 0.921 0.021
    

We managed to bring the y_tot down (by the amount that wild pollination dropped), but were also unable to make it move due to our reveg curve. The p_abund is unchanged, which makes sense as nothing related to pollinators has changed. The pdep_y_w and y_wild are still the same as each other but the value has dropped. Therefore having a higher half_sat means a lower yield for a given pollinator abundance.

Tweaking the reveg curve

What about if we change the reveg curve. We'll make it change over a shorter period for quicker runs but let's ignore summer to focus just on spring. If we try this curve, with the same modified CSV as above:

--- a/reveg_alg/alg.py
+++ b/reveg_alg/alg.py
@@ -8,6 +8,32 @@ See the README.md in this directory for where the formulae came from.
 """
 from math import sin

+lookup = [
+    {
+        'nesting_cavity': 0,
+        'nesting_ground': 1,
+        'fr_summer': 0,
+        'fr_spring': 0
+    },
+    {
+        'nesting_cavity': 0.1,
+        'nesting_ground': 1,
+        'fr_summer': 0.5,
+        'fr_spring': 0.3
+    },
+    {
+        'nesting_cavity': 0.3,
+        'nesting_ground': 0.7,
+        'fr_summer': 0.5,
+        'fr_spring': 0.6
+    },
+    {
+        'nesting_cavity': 1,
+        'nesting_ground': 0.3,
+        'fr_summer': 0.5,
+        'fr_spring': 1
+    },
+]

 def compute_fr(year, magic):
     if year > 25:
@@ -16,9 +42,12 @@ def compute_fr(year, magic):

 def get_values_for_year(year):
-    return {
-        'nesting_cavity': compute_fr(year, 3.2),
-        'nesting_ground': 0.31 + (3 / ((year / 0.9) + 6)),
-        'fr_summer': compute_fr(year, 2.4),
-        'fr_spring': compute_fr(year, 2),
-    }
+    try:
+        return lookup[year]
+    except IndexError:
+        return {
+            'nesting_cavity': compute_fr(year, 3.2),
+            'nesting_ground': 0.31 + (3 / ((year / 0.9) + 6)),
+            'fr_summer': compute_fr(year, 2.4),
+            'fr_spring': compute_fr(year, 2),
+        }

...then we get

year 	season 	p_abund 	pdep_y_w 	y_tot 		y_wild
0 	spring 	0.079554482 	0.02115294585 	0.92115295749 	0.02115294585
1 	spring 	0.08121136508 	0.02162173759 	0.92162172102 	0.02162173759
2 	spring 	0.08118655192 	0.02161473399 	0.92161472624 	0.02161473399
3 	spring 	0.08298522047 	0.02212523004 	0.92212523286 	0.02212523004

Which is essentially the same as the previous run. Let's tweak the curve again but this time we'll leave nesting_ground at 1 for the whole time. In case gains from nesting_cavity are offset by losses from the ground. The results:

year 	season 	p_abund 	pdep_y_w 	y_tot 		y_wild
0 	spring 	0.079554482 	0.02115294585 	0.92115295749 	0.02115294585
1 	spring 	0.08121136508 	0.02162173759 	0.92162172102 	0.02162173759
2 	spring 	0.08183949976 	0.02179984905 	0.92179980604 	0.02179984905
3 	spring 	0.0845201108 	0.02256201288 	0.92256195576 	0.02256201288

They aren't very different. We picked up 0.2pp in p_abund but we want larger changes.

Back to farm attributes: p_managed

Let's try reducing the "proportion of pollination required on the farm provided by managed pollinators" (p_managed) significantly.

-0.1,0.9,spring,1,0,0,0.2,1
+0.8,0.1,spring,1,0,0,0.2,1

We still have the modified reveg curve from before, here's the results:

year 	season 	p_abund 	pdep_y_w 	y_tot 		y_wild
0 	spring 	0.079554482 	0.02115294761 	0.12115295185 	0.02115294761
1 	spring 	0.08121136508 	0.02162173759 	0.12162174359 	0.02162173759
2 	spring 	0.08183949976 	0.02179984905 	0.12179985681 	0.02179984905
3 	spring 	0.0845201108 	0.02256201288 	0.12256200653 	0.02256201288

It's only the y_tot that's dropped. Effectively we've said that the farm still requires the same amount of pollination but we have less provided by managed pollinators.

Guild table foraging_activity_spring_index

The values were 1 for all species with apples, so what if we cut that in half?

 SPECIES,nesting_suitability_cavity_index,nesting_suitability_ground_index,foraging_activity_spring_index,foraging_activity_summer_index,alpha,relative_abundance
-Apis,1,0,1,1,1000,1
-Halictines,0,1,1,0.5,300,0.2
-Exoneura,1,0,1,1,200,0.1
+Apis,1,0,0.5,1,1000,1
+Halictines,0,1,0.5,0.5,300,0.2
+Exoneura,1,0,0.5,1,200,0.1

We still have all the changes as per the last run too. We get:

year 	season 	p_abund 	pdep_y_w 	y_tot 		y_wild
0 	spring 	0.05650301385 	0.01475183713 	0.11475184048 	0.01475183713
1 	spring 	0.05766462795 	0.01506866413 	0.11506866483 	0.01506866413
2 	spring 	0.05810186559 	0.01518809906 	0.11518810505 	0.01518809906
3 	spring 	0.05993091069 	0.01568861942 	0.11568862718 	0.01568861942

Pollinator abundance drops and so the yield from wild pollinators drops too, which makes sense. Total yield only drops 1.1pp, which shows that total yield isn't all that sensitive to changes in pollinator abundance. What if we dropped the foraging_activity... even further?

year 	season 	p_abund 	pdep_y_w 	y_tot 		y_wild
0 	spring 	0.01808115206 	0.00458248706 	0.10458248512 	0.00458248706
1 	spring 	0.01835916487 	0.00465392317 	0.10465392784 	0.00465392317
2 	spring 	0.01849829556 	0.00468968552 	0.10468968446 	0.00468968552
3 	spring 	0.01904126412 	0.00482932256 	0.1048293193 	0.00482932256

The drop we see in p_abund is not linear. The first change in the input was 0.5 and the second was 0.4 but the second saw a change 166% as large. The drop in the y_tot seems fairly linear though.

more m2 of reveg

Is the problem that we have awesome reveg, but just not enough of it? Let's try surrounding the farm in a thick band of reveg:

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "properties": {},
      "geometry": {
        "type": "Polygon",
        "coordinates": [
          [
            [ 138.83957147598267, -34.93755769866769 ],
            [ 138.8333702087402, -34.933793245565816 ],
            [ 138.83191108703613, -34.93085544485662 ],
            [ 138.83206129074097, -34.92724901870849 ],
            [ 138.83306980133057, -34.926105484633226 ],
            [ 138.83834838867188, -34.927847168645386 ],
            [ 138.83961439132688, -34.93738179349233 ],
            [ 138.84137392044067, -34.93810300231374 ],
            [ 138.84042978286743, -34.92682679259814 ],
            [ 138.8329839706421, -34.92453969674121 ],
            [ 138.83010864257812, -34.9278119834757 ],
            [ 138.83021593093872, -34.93326550468784 ],
            [ 138.83392810821533, -34.936924438270765 ],
            [ 138.84109497070312, -34.939580581067794 ],
            [ 138.84165287017822, -34.93854276067772 ],
            [ 138.83957147598267, -34.93755769866769 ]
          ]
        ]
      }
    }
  ]
}

And the same time, we've reset all the CSV changes (but left the summer row out) so we're only running the modified reveg curve:

year 	season 	p_abund 	pdep_y_w 	y_tot 		y_wild
0 	spring 	0.079554482 	0.10000001833 	1 	0.10000001833
1 	spring 	0.09241415789 	0.10000001833 	1 	0.10000001833
2 	spring 	0.09954793087 	0.10000001833 	1 	0.10000001833
3 	spring 	0.12721142443 	0.10000001833 	1 	0.10000001833

We're seeing a 4.7pp increase in p_abund, which probably isn't enough but at least we're getting it to move more.

Let's go nuts and cover the whole map in reveg:

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "properties": {},
      "geometry": {
        "type": "Polygon",
        "coordinates": [
          [
            [ 138.83965730667114, -34.937416974557586 ],
            [ 138.83345603942868, -34.933652514997014 ],
            [ 138.8319969177246, -34.93071470924782 ],
            [ 138.83214712142944, -34.92710827691313 ],
            [ 138.83315563201904, -34.925964740876346 ],
            [ 138.83843421936035, -34.927706427876075 ],
            [ 138.83970022201535, -34.9372410690804 ],
            [ 138.85929107666016, -34.9416034135726 ],
            [ 138.85336875915527, -34.91591853170241 ],
            [ 138.82633209228516, -34.91204750996963 ],
            [ 138.81525993347168, -34.931822995631464 ],
            [ 138.8232421875, -34.95201581392009 ],
            [ 138.8418674468994, -34.957080827826566 ],
            [ 138.85645866394043, -34.95954287430728 ],
            [ 138.8605785369873, -34.942306995791405 ],
            [ 138.83965730667114, -34.937416974557586 ]
          ]
        ]
      }
    }
  ]
}

Which gives us these results:

year 	season 	p_abund 	pdep_y_w 	y_tot 	y_wild
0 	spring 	0.079554482 	0.10000001833 	1 	0.10000001833
1 	spring 	0.10214489357 	0.10000001833 	1 	0.10000001833
2 	spring 	0.1761094973 	0.10000001833 	1 	0.10000001833
3 	spring 	0.42012737507 	0.10000001833 	1 	0.10000001833

Now that's a decent change in p_abund. Too bad it's from an unrealistic amount of reveg. Also, the yield is already stuck at 1 from the start so let's use what we've learnt to drop that y_tot value down. We'll drop the p_managed to bring the y_tot down.

 half_sat,p_managed,season,fr_spring,fr_summer,n_cavity,n_ground,p_dep
-0.1,0.9,spring,1,0,0,0.2,1
+0.1,0.4,spring,1,0,0,0.2,1
year 	season 	p_abund 	pdep_y_w 	y_tot 		y_wild
0 	spring 	0.079554482 	0.43735993503 	0.83735998016 	0.43735993503
1 	spring 	0.10214489357 	0.50537476037 	0.90537469268 	0.50537476037
2 	spring 	0.1761094973 	0.59999995487 	1 		0.59999995487
3 	spring 	0.42012737507 	0.59999995487 	1 		0.59999995487

Now we can see the change our crazy amount of reveg makes. It's at least 16.3pp increase in total yield before it tops out at 1. Let's do another run but this time we'll raise the half_sat, which will reduce y_tot so we can see further gains from our reveg.

 half_sat,p_managed,season,fr_spring,fr_summer,n_cavity,n_ground,p_dep
-0.1,0.9,spring,1,0,0,0.2,1
+0.5,0.4,spring,1,0,0,0.2,1
year 	season 	p_abund 	pdep_y_w 	y_tot 		y_wild
0 	spring 	0.079554482 	0.079554482 	0.47955452008 	0.079554482
1 	spring 	0.10214489357 	0.10214490062 	0.50214491754 	0.10214490062
2 	spring 	0.1761094973 	0.1761094973 	0.57610948601 	0.1761094973
3 	spring 	0.42012737507 	0.42012737507 	0.82012736379 	0.42012737507

That's what we've been wanting to see! Big increases in pollinator abundance that correspond with big increases in total yield. Too bad it's from such a crazy amount of reveg.

What if we run a thin encircling reveg vector, which is more modest but still unrealistic, with the tweaked half_sat and p_managed values?

year 	season 	p_abund 	pdep_y_w 	y_tot 		y_wild
0 	spring 	0.079554482 	0.079554482 	0.47955452008 	0.079554482
1 	spring 	0.09241415789 	0.09241416494 	0.49241415366 	0.09241416494
2 	spring 	0.09954793087 	0.09954793087 	0.49954793369 	0.09954793087
3 	spring 	0.12721142443 	0.12721142443 	0.52721141315 	0.12721142443

That's looking pretty good. A 4.7pp (9.04%) increase in total yield, which all comes from the wild pollinators. The reveg is still pretty big though, so let's try something smaller. This vector is reveg about 20m thick around the whole farm:

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "properties": {},
      "geometry": {
        "type": "Polygon",
        "coordinates": [
          [
            [ 138.83957147598267, -34.93755769866769 ],
            [ 138.8333702087402, -34.933793245565816 ],
            [ 138.83191108703613, -34.93085544485662 ],
            [ 138.83206129074097, -34.92724901870849 ],
            [ 138.83306980133057, -34.926105484633226 ],
            [ 138.83834838867188, -34.927847168645386 ],
            [ 138.83961439132688, -34.93738179349233 ],
            [ 138.83987188339233, -34.937452155607744 ],
            [ 138.83857369422913, -34.92768003895494 ],
            [ 138.83302688598633, -34.92591196190525 ],
            [ 138.83184671401978, -34.92724022235333 ],
            [ 138.83172869682312, -34.9310225680785 ],
            [ 138.83318781852722, -34.93389879333398 ],
            [ 138.83981823921204, -34.937909507886594 ],
            [ 138.8400113582611, -34.937592879657494 ],
            [ 138.83957147598267, -34.93755769866769 ]
          ]
        ]
      }
    }
  ]
}

...which gets us the following results:

year 	season 	p_abund 	pdep_y_w 	y_tot 		y_wild
0 	spring 	0.079554482 	0.079554482 	0.47955452008 	0.079554482
1 	spring 	0.08050257882 	0.08050257882 	0.48050259574 	0.08050257882
2 	spring 	0.08083854012 	0.08083854012 	0.48083851474 	0.08083854012
3 	spring 	0.0822269207 	0.0822269207 	0.48222692352 	0.0822269207

We're back in the realms that we started with only having a small increase, but at least we know why. 0.47pp or 0.55% increase.

I'm interested to know how important proximity of the reveg to the farm is. That is, does the reveg need to encircle the farm or can we have the same area of reveg but all to one side of the farm? We'll use this reveg vector:

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "properties": {},
      "geometry": {
        "type": "Polygon",
        "coordinates": [
          [
            [ 138.83965730667114, -34.93755769866769 ],
            [ 138.8453221321106, -34.93738179349233 ],
            [ 138.84420633316037, -34.92559528736588 ],
            [ 138.83824110031128, -34.92578881084073 ],
            [ 138.83965730667114, -34.93755769866769 ]
          ]
        ]
      }
    }
  ]
}

...and the results are:

year 	season 	p_abund 	pdep_y_w 	y_tot 		y_wild
0 	spring 	0.079554482 	0.079554482 	0.47955452008 	0.079554482
1 	spring 	0.08938941321 	0.08938941321 	0.48938935962 	0.08938941321
2 	spring 	0.09731674899 	0.09731674899 	0.49731670951 	0.09731674899
3 	spring 	0.12569949279 	0.12569949279 	0.52569952381 	0.12569949279

That's pretty good. We see a 4.61pp increase in both pollinator abundance and total yield. That's exactly what we want to see :D That reveg has an area of 675m x 1675m (1,130,625m2 or 113ha). The question is: is this a realistic amount of reveg? I suspect not seeing as it roughly the same size as the farm.

We want to see if we can get the same yield changes from a smaller area of reveg, which means amplifying the effect reveg has on pollinator abundance. Let's try reducing the p_managed further from 0.4 to 0.1:

 half_sat,p_managed,season,fr_spring,fr_summer,n_cavity,n_ground,p_dep
-0.5,0.4,spring,1,0,0,0.2,1
+0.5,0.1,spring,1,0,0,0.2,1

The results we get are:

year 	season 	p_abund 	pdep_y_w 	y_tot 		y_wild
0 	spring 	0.079554482 	0.079554482 	0.17955448623 	0.079554482
1 	spring 	0.08938941321 	0.08938941321 	0.18938941039 	0.08938941321
2 	spring 	0.09731674899 	0.09731674899 	0.19731674617 	0.09731674899
3 	spring 	0.12569949279 	0.12569949279 	0.22569948997 	0.12569949279

We're seeing the exact same amount of change of 4.61pp. We've just shifted the number down closer to zero. For completeness, let's do another run but with p_managed at a higher number to see if its only effect is to shift the base we work from:

 half_sat,p_managed,season,fr_spring,fr_summer,n_cavity,n_ground,p_dep
-0.5,0.1,spring,1,0,0,0.2,1
+0.5,0.8,spring,1,0,0,0.2,1

...and that gets us these results:

year 	season 	p_abund 	pdep_y_w 	y_tot 		y_wild
0 	spring 	0.079554482 	0.079554482 	0.87955450879 	0.079554482
1 	spring 	0.08938941321 	0.08938941321 	0.88938940475 	0.08938941321
2 	spring 	0.09731674899 	0.09731674899 	0.89731675464 	0.09731674899
3 	spring 	0.12569949279 	0.12569949279 	0.92569951253 	0.12569949279

There's our 4.61pp again. That confirms out theory that p_managed doesn't change the amplitude of the change.

We've been running with a reveg curve that provides the maximum nesting, which is not what our normal curve does. Let's change that so we'll still run the curve compressed into 3 years but the values will mimic the curve we use. It just makes testing faster. We'll adjust the curve from above to use this lookup:

# ignore the summer values, we aren't even using them
lookup = [
    {
        'nesting_cavity': 0,
        'nesting_ground': 0.8,
        'fr_summer': 0,
        'fr_spring': 0
    },
    {
        'nesting_cavity': 0.1,
        'nesting_ground': 0.7,
        'fr_summer': 0.5,
        'fr_spring': 0.3
    },
    {
        'nesting_cavity': 0.3,
        'nesting_ground': 0.55,
        'fr_summer': 0.5,
        'fr_spring': 0.6
    },
    {
        'nesting_cavity': 0.62,
        'nesting_ground': 0.4,
        'fr_summer': 0.5,
        'fr_spring': 1
    },
]

The rendered curve looks like this:

Running with the same vector and farm attributes as before, we get these results:

year 	season 	p_abund 	pdep_y_w 	y_tot 		y_wild
0 	spring 	0.079554482 	0.079554482 	0.87955450879 	0.079554482
1 	spring 	0.08505112935 	0.0850511364 	0.88505111384 	0.0850511364
2 	spring 	0.09015186613 	0.09015186613 	0.89015183652 	0.09015186613
3 	spring 	0.10001740658 	0.10001740658 	0.90001736287 	0.10001740658

That's a 2.05pp increase.

Next let's see if the changes caused by reveg area are linear. We'll try this vector that is roughly twice the size of the previous one.

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "properties": {},
      "geometry": {
        "type": "Polygon",
        "coordinates": [
          [
            [ 138.83967876434326, -34.93755769866769 ],
            [ 138.851158618927, -34.9372058879397 ],
            [ 138.8500213623047, -34.92538417032731 ],
            [ 138.83824110031128, -34.925806403861266 ],
            [ 138.83967876434326, -34.93755769866769 ]
          ]
        ]
      }
    }
  ]
}

...which looks like:

...and get the results:

year 	season 	p_abund 	pdep_y_w 	y_tot 		y_wild
0 	spring 	0.079554482 	0.079554482 	0.87955450879 	0.079554482
1 	spring 	0.08594976203 	0.08594976203 	0.88594977472 	0.08594976203
2 	spring 	0.0958245325 	0.09582452545 	0.89582455224 	0.09582452545
3 	spring 	0.11399800412 	0.11399800412 	0.91399802386 	0.11399800412

That's a change of 3.44pp, which is not double the previous run despite being double the area. I'm guessing that proximity is playing a role in the lower result.

We know higher half_sat values mean lower yield numbers but we didn't check if changing the half_sat changes the amplitude of the yield result. First we'll raise the value:

-0.5,0.8,spring,1,0,0,0.2,1
+0.95,0.8,spring,1,0,0,0.2,1

That gets the result:

year 	season 	p_abund 	pdep_y_w 	y_tot 		y_wild
0 	spring 	0.079554482 	0.0045290315 	0.80452904551 	0.0045290315
1 	spring 	0.08594976203 	0.00492512849 	0.80492509711 	0.00492512849
2 	spring 	0.0958245325 	0.0055474997 	0.80554752033 	0.0055474997
3 	spring 	0.11399800412 	0.00672759278 	0.80672760856 	0.00672759278

That's a change of 0.22pp in the y_tot but p_abund has stayed the same, it just has less effect on the yield.

Now we'll go the other way and make half_sat as low as possible before y_tot tops out:

-0.95,0.8,spring,1,0,0,0.2,1
+0.33,0.8,spring,1,0,0,0.2,1

The result:

year 	season 	p_abund 	pdep_y_w 	y_tot 		y_wild
0 	spring 	0.079554482 	0.14926641045 	0.94926635968 	0.14926641045
1 	spring 	0.08594976203 	0.1602965124 	0.96029657445 	0.1602965124
2 	spring 	0.0958245325 	0.17705802424 	0.97705800168 	0.17705802424
3 	spring 	0.11399800412 	0.19984916927 	0.99984916081 	0.19984916927

That's a change of 5.06pp. So to answer our question, adjusting half_sat does change the amplitude of the y_tot change.

Does that mean we can reduce the reveg area but still try to get decent changes in yield by shifting the yield down, away from 1, with a lower p_managed and amplifying the change with a tiny half_sat?

-0.33,0.8,spring,1,0,0,0.2,1
+0.005,0.00001,spring,1,0,0,0.2,1

I don't think so. We went back to the standard reveg vector and we had to reduce p_managed a lot to keep the y_tot away from 1 but even with a tiny half_sat, these are the results we're seeing:


year 	season 	p_abund 	pdep_y_w 	y_tot 		y_wild
0 	spring 	0.079554482 	0.9449677247 	0.94497782201 	0.9449677247
1 	spring 	0.08056216143 	0.94568452112 	0.94569450562 	0.94568452112
2 	spring 	0.08086007448 	0.94589103656 	0.94590113388 	0.94589103656
3 	spring 	0.0815998578 	0.94639894835 	0.94640898925 	0.94639894835

That's only a change of 0.15pp. Going further doesn't achieve anything either as I think the effects of our changes are beind drowned out by everything else in the model.

Do farm_attribute_table row affect each other?

First we're running with only a row for spring:

half_sat,p_managed,season,fr_spring,fr_summer,n_cavity,n_ground,p_dep
0.9,0.9,spring,1,0,0,0.2,1

The values don't matter so much as we're just looking for a change. We're using apples, a modified reveg curve and a the standard reveg vector but again, that doesn't matter. Here's the results:

year 	season 	p_abund 	pdep_y_w 	y_tot 		y_wild
0 	spring 	0.079554482 	0.00951332085 	0.90951329371 	0.00951332085
1 	spring 	0.08056216143 	0.00964298707 	0.90964297931 	0.00964298707
2 	spring 	0.08110088694 	0.00971246162 	0.90971241949 	0.00971246162
3 	spring 	0.0815998578 	0.00977686813 	0.90977683922 	0.00977686813

Now we'll add a summer row:

 half_sat,p_managed,season,fr_spring,fr_summer,n_cavity,n_ground,p_dep
 0.9,0.9,spring,1,0,0,0.2,1
+0.9,0,summer,1,0,0,0.2,0.9

...and here's the results:

year 	season 	p_abund 	pdep_y_w 	y_tot 		y_wild
0 	spring 	0.079554482 	0.00951332085 	0.00951332085 	0.00951332085
0 	summer 	0 		0.00951332085 	0.10856198877 	0.00856198877
1 	spring 	0.08056216143 	0.00964298707 	0.00964298707 	0.00964298707
1 	summer 	0 		0.00964298707 	0.10867868836 	0.00867868836
2 	spring 	0.08110088694 	0.0097124625 	0.0097124625 	0.0097124625
2 	summer 	0 		0.0097124625 	0.10874121625 	0.00874121625
3 	spring 	0.0815998578 	0.00977686901 	0.00977686901 	0.00977686901
3 	summer 	0 		0.00977686901 	0.10879918211 	0.00879918211

Yep, that had an effect. It's seriously dropped the value of our spring rows but only the y_tot column, the rest are untouched.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment