Closed ConnectedSystems closed 2 years ago
Hi @ConnectedSystems, does this only happen in growthODE4_KA for multiple simulations, or its just when you change default parameters?
Thanks @ConnectedSystems and @Rosejoycrocker,
A few quick questions:
coralScenario()
function, or elsewhere?At least one factor that produces values > 1 is setting the seed values to something much higher than defaults (e.g., 100,000)
Same issue does not present itself if seed values are ~10,000
Hi @KRNA01
Can growth rates (r
) be values > 1?
Hi @ConnectedSystems, does this only happen in growthODE4_KA for multiple simulations, or its just when you change default parameters?
@Rosejoycrocker both :)
Currently I'm tracing the effect seed values has on calculations.
@ConnectedSystems and @Rosejoycrocker I think I found the issue. Seeding values of 100,000 corals per year takes us well above 100% coral cover each year. The size of the reef arena that we're simulating seeding in is only 10 m by 10 m. Suggest we set the default range for seeding between 100 corals per year (1 coral per m2) and 1000 corals per year (10 corals per m2). This is consistent with recent advice by Pete Mumby, and likely what the business case will adopt.
I was about to say that the max_cover
value does not appear to be respected by growthODE4_KA()
.
Currently the Yout
values are constrained on a per species basis. If I understand correctly, this should be on a site basis, with the species cover values adjusted proportionally.
@Rosejoycrocker
Does the MCDA discount/disregard sites that are at or close to their maximum coral cover?
Agree, this is a problem - and not sure how we fix it. I'm not worried about going slightly over 1 because coral reefs are 3D, but getting coral cover values of 2 is a problem.
If seeding rates are causing the problem, then I suggest we simply lower the high end of the seed1 and seed2 range.
Good point @ConnectedSystems. I've left all the pre-filtering in the MCDA as it was in the original code, but I don't think theres anything that checks if sites are 'full'... I can add something like this
@ConnectedSystems and @Rosejoycrocker,
Just realised that my diameters for 1 year-old are too big (5 cm). Have now reduced in coralScenario()
to 2 cm diameter. This will allow room for higher seeding rates without risking cover going above 1.
@ConnectedSystems, suggest we move this variable (size of seeded corals) to somewhere in the ParameterHandler
functions, but not sure where.
@ConnectedSystems and @Rosejoycrocker,
I just corrected the size of 1 year old corals (see previous post) to 2 cm diameter in 40corals. This updates the relationship between numbers deployed and coral cover added to the following:
In summary, adding 100,000 baby corals per year from two species in successive years could still push coral cover well above 1.
Still suggest we use seeding rates of 100 as the lower and 1000 as the upper bounds (equivalent of 1 and 10 corals seeded per taxon per year).
@ConnectedSystems and @Rosejoycrocker
... per m2
Thanks for the table @KRNA01. @ConnectedSystems, I just added a line in the MCDA that removes sites where proportional coral cover>=1... I'll push after I've made sure it's all working
I've made an adjustment in coralScenario
as well which proportionally reduces the cover to its maximum for each site.
% Run ODE for all species and sites
[~, Y] = ode45(@(t, X) growthODE4_KA(X, e_r, e_P, e_mb, rec, e_comp), tspan, Yin1, non_neg_opt);
Y = Y(end, :); % get last step in ODE
% If any sites are above their maximum possible value,
% proportionally adjust each entry so that their sum is < P
Y = reshape(Y, nspecies, nsites);
if any(sum(Y, 1) > e_P)
idx = find(sum(Y, 1) > e_P);
Ys = Y(:, idx);
Y(:, idx) = (Ys ./ sum(Ys)) * e_P;
end
@KRNA01 I've also pulled your recent change vis-à-vis coral diameters.
Simulation with values of 100,000 for both seed1 and 2.
Mean results of a monte carlo run over 8 scenarios, 3 replicates each (24 simulations in total, note shelterVolume
needs to be adjusted):
Agree we should reduce the seeding range though
@Rosejoycrocker
I just added a line in the MCDA that removes sites where proportional coral cover>=1... I'll push after I've made sure it's all working
Cool - I was also wondering if we are weighting away from sites close to their maximum cover.
E.g., if the maximum cover is 1.0, and the site is currently at 0.98 seems like a waste to add 10,000 more coral there.
Brilliant, thanks @ConnectedSystems
Seeding 100,000 per year for both species pushes the system. Your fix helps it not to break :-)
@Rosejoycrocker,
Agree entirely. Suggest we should favour seeding in places with low coral cover but high P (or k values).
Also, @ConnectedSystems and @Rosejoycrocker, suggest we lower the 100,000 upper seeding boundary to 1000 (or 10,000 at the very highest) - see my previous comments.
@Rosejoycrocker,
Agree entirely. Suggest we should favour seeding in places with low coral cover but high P (or k values).
Also, @ConnectedSystems and @Rosejoycrocker, suggest we lower the 100,000 upper seeding boundary to 1000 (or 10,000 at the very highest) - see my previous comments.
Yes, have made the necessary changes to bound at 10,000. I will merge directly into 40corals
in a few minutes.
@ConnectedSystems and @KRNA01 , sounds good. I'll push the changes that remove full sites and then I'll add in a weighting for 'how full' each site is
@KRNA01 does the level of coral cover effect the shading priorities in the opposite way? for example, if low coral cover means I should weight a site for seeding more highly, would the corresponding shading matrix have a lower weighting because its not worth shading when theres not much coral there?
Also by high P, are you referring to the parameter e_P?
@Rosejoycrocker
e_P
is P
yes.
This is also sometimes referred to as k
.
Be aware that there is a change incoming. P
is currently a constant "universal" value applied to all sites, but we are moving towards running ADRIA for all sites within a reef/cluster.
As part of this, spatial data will be provided which includes maximum cover values for each site, so this will be applied on a per site basis rather than as a single constant.
This issue addressed by changes in commit 853906e5ae7433bc39e84c0dae58cfa420abb188
Suggest moving related discussion for P
/k
to #65
Thanks for clarifying @ConnectedSystems. I'll try and make it generic enough to incorporate a non-scalar e_P
PS: #50 is the relevant issue.
@KRNA01 does the level of coral cover effect the shading priorities in the opposite way? for example, if low coral cover means I should weight a site for seeding more highly, would the corresponding shading matrix have a lower weighting because its not worth shading when theres not much coral there? Also by high P, are you referring to the parameter e_P?
@Rosejoycrocker. Yes, if we're also shading, then that intervention should ideally be favouring sites that have high coral cover because we'd be helping to protect the standing stock. Later we can think about whether shading places where we have already invested $$ in deploying enhanced corals should be part of our criteria - so protect natural corals or deployed corals or both. Definitely for later :-) .
Yes, as @ConnectedSystems explained, e_P is P and also 'k' referred to by the IPMF team as a site's carrying capacity.
@Rosejoycrocker .. unless you are already tackling this in your trade-off analyses
Thanks @KRNA01, I'll add this to shading also then, so the MCDAvars will have a new variable called 'maxcover' which will be e_P. In terms of trade offs, I'm thinking I'll leave in the wtlocover and wthicover weights in this part of the decision matrix as this will allow for future trade off analyses- e.g. letting wtlocover =0 takes this criteria out of the decision process and a BBN analysis including the variable wthicover will suggest how important this criteria is in giving high coral cover as an output... but anyway thanks Ken :)
@KRNA01
@Rosejoycrocker and I are seeing strange total cover values (i.e., non-proportional results with values reaching ~30) when running across multiple simulations.
At first I thought I had tracked it down to how
coralTaxaCover
deals with multiple simulations (e.g., an incorrect summation or something, see my comment here) but I now see that these values occur before the metrics are calculated.There's something that pushes
growthODE4_KA()
to produce values well above 1.0 when parameters are varied, as the issue does not occur when using default values insingle_scenario.m