Note: make sure you view this page on this URL with a trailing slash otherwise images won't work. More info.
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
andy_wild
should increase as the years go on as this is what the reveg is trying to achieve
- removing the summer
farm_attribute_table
row does affect the spring results but only they_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 lowery_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 iny_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.
- 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?
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?
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.
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.
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.
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.
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.
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.