Closed ConnectedSystems closed 2 years ago
Sorry @Rosejoycrocker @KRNA01 forgot to ask during the meeting:
I will be varying the criteria weights within the larger set of runs but for these specific targeted runs I take it we use criteria values from JC (for Moore) and YM (for Brick cluster)?
Hi Takuya,
Brick should be identical to Moore in the sense that they are both clusters with RECOM info. Brick is in the Whitsundays, so well away from (southeast of) Cairns.
Our dance with ReefMod and YM is for the Cairns region. This is the 190 reefs that include reefs in both the Moore cluster and the Hastings cluster. This will be all reef scale, I.e no sites and no RECOMs. I’ll draw this up in a map, because it’s confusing - apologies.
Best, Ken
Get Outlook for iOShttps://aka.ms/o0ukef
From: Takuya Iwanaga @.> Sent: Tuesday, February 15, 2022 4:55:05 PM To: open-AIMS/ADRIA_repo @.> Cc: Ken Anthony @.>; Mention @.> Subject: Re: [open-AIMS/ADRIA_repo] Targeted scenario values for Moore and Cairns (Brick cluster) case (Issue #96)
Sorry @Rosejoycrockerhttps://github.com/Rosejoycrocker @KRNA01https://github.com/KRNA01 forgot to ask during the meeting:
I will be varying the criteria weights during my own runs but for these specific targeted runs I take it we use criteria values from JC (for Moore) and YM (for Brick cluster)?
— Reply to this email directly, view it on GitHubhttps://github.com/open-AIMS/ADRIA_repo/issues/96#issuecomment-1039919764, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AVYCFW74KQ2WJLLXBJQTFF3U3H2ETANCNFSM5ONSUOIA. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you were mentioned.Message ID: @.***>
My bad - geography has never been a strong subject area of mine
@ConnectedSystems and @Rosejoycrocker,
Suggesting a small revision based on the M&DS meeting today.
Specifically, we should now attempt to include fogging. Mark Baird is proposing a recipe (see below). Basically what we're already doing - but with minor adjustments.
Work by Josh Ames (ILA subgroup) finds that 1 fogging unit can cover 5 km2 with 20~40% shade in the Best Case of an ideally placed fogging unit (on a reef long axis with a wind speed of 1 km/hr).
Let's simply apply 1 fogging unit on each of five reefs (our default), which we select through our existing criteria and algorithms.
I will attempt a minor change to how we calculate changes in bleaching mortality. If I fail, we can simply default to our existing method and use DHW equivalents for fogging intensity.
Hi @KRNA01, sounds good. Let me know if you want me to help with any of this. :)
I guess we'd want to add a new uncertain "fog_effectivity" parameter with range of 0.2 - 0.4 (20 to 40%)? Any idea on what the "expected" shade coverage would be? Or do we just use the middle value (0.3)?
@Rosejoycrocker, thank you - I might accept that offer, please :-), @ConnectedSystems, I agree, if we can make this a stochastic variable within that range, that would be great. Questions:
Sure @KRNA01, happy to help :) Takuya should probably have the last word on this but if there's a chance we'll need cooling via delta DHW for cloud brightening later, maybe it's better if we add in percent bleaching mortality reduction as an extra? Just so we don't do the work again later and have to add what we have now back in.
I think we should split the semantic meaning of "SRM" explicitly for fogging and cloud brightening, that will resolve the issue around putting things back in/out and allows us to speak to the expected effect of each intervention.
e.g., instead of "SRM" that currently represents both, have fogging
and brightening
parameters.
Would it be too much to change everything to one representative effect unit? i.e., everything is represented as percent bleaching-mortality reduction
Okay if not. Probably not strictly necessary either given they represent different processes/interventions anyway.
Agree - let's change to fogging and brightening.
@ConnectedSystems, please let me know how you'd prefer we implement this, specifically:
New branch off which branch?
Please branch off "brick-modeling"
New input parameter: fogging.
I will implement changes re fogging/brightening.
Can I add site depth to bleaching function without upsetting structure?
I think we just need to agree on a value that indicates no depth data, and so to exclude it from the calculation.
Keeping in mind the current inputs are negative values (e.g, -5 means 5 meter depth), does a site_depth
value of 0 have any meaning?
@ConnectedSystems, great - thank you.
I think only depths less than e.g. -2 are useful (i.e. deeper than 2m)
@Rosejoycrocker and @ConnectedSystems , can we implement a depth filter on the Brick Reef sites similar to what we did for Moore for IPMF, please?
Hi @KRNA01, if we have depth data for each site we can do depth filtering.
@Rosejoycrocker, great - thank you
New branch off which branch?
Please branch off "brick-modeling"
New input parameter: fogging.
I will implement changes re fogging/brightening.
Can I add site depth to bleaching function without upsetting structure?
I think we just need to agree on a value that indicates no depth data, and so to exclude it from the calculation.
Keeping in mind the current inputs are negative values (e.g, -5 means 5 meter depth), does a
site_depth
value of 0 have any meaning?
Good point @ConnectedSystems about values meaning no depth data is available. If we expect negative values, maybe ones? (or zero, I'm not sure if this would be a possible value or not)
See this from the eReefs webpage. Suggests we should cut out sites that are shallower than 2 m - i.e > - 2 m.
Zero and higher would be above water
The filtering also needs a max depth (through a parameter representing offset in depth from the minimum depth parameter). Do you have a preferred max depth also or should this be set sufficiently high (and negative) so that there is effectively no max depth?
What did we do for Brick? If we didn't have a depth cut-off, I'd suggest using 12 m
For the IPMF data we used depths from 5 to 10m (so min depth =5 and offset =5), but can easily use 12m for max depth.
@ConnectedSystems,
Adding fogging to the bleaching mortality function is so simple that I suggest you simply implement directly in your branch instead of via a PR.
Is that okay?
If so, here it is:
in ADRIA_bleachingmortality
line 1: add fogging
as input variable
Line 40: change
Y = exp(n_p1 * (exp(n_p2 * capped_dhw)));
to
Y = exp(n_p1 * (exp(n_p2 * capped_dhw))).* (1 - fogging);
That should do it.
Am I right that fogging is a vector (or an array) with zero for sites and years that have no fogging, and with stochastic values (0.2-0.4) at selected sites?
@Rosejoycrocker.
For the IPMF data we used depths from 5 to 10m (so min depth =5 and offset =5), but can easily use 12m for max depth.
That's great - lets use the same range, please.
@ConnectedSystems, Adding fogging to the bleaching mortality function is so simple that I suggest you simply implement directly in your branch instead of via a PR.
Is that okay?
If so, here it is: in
ADRIA_bleachingmortality
line 1: addfogging
as input variableLine 40: change
Y = exp(n_p1 * (exp(n_p2 * capped_dhw)));
toY = exp(n_p1 * (exp(n_p2 * capped_dhw))).* (1 - fogging);
That should do it.
If its a simple change you could just push it to the indicated branch, but I'll make an exception just for you, Ken.
Am I right that fogging is a vector (or an array) with zero for sites and years that have no fogging, and with stochastic values (0.2-0.4) at selected sites?
I was thinking something simpler (but not as robust) - have a single scalar that represents the assumed average effectivity of the intervention.
Having a value for each of the selected sites would add another five dimensions. I'm okay with it if you are, but note this will drastically increase the number of samples needed for sensitivity analysis.
@ConnectedSystems,
Thank you - I appreciate the exception :-)
Agree, let's just use 0.3 (30%) as the intervention.
@KRNA01 I had already started a brick-modeling
branch but will consolidate into your Brick_modelling
branch.
Just letting you know so you're aware of incoming changes.
@ConnectedSystems, just saw that - great, thank you. I just added Vero's DHWs to the Brick inputs. Some DHWs are negative, but the Gompertz bleaching function should be immune to that. Hope the format is otherwise right. If not, let me know
@ConnectedSystems, just checked for updates in the Intervention Report. Fogging should now be set to 20%. If you are already running with 30%, then don't worry - these estimates are somewhat arbitrary.
Thanks, I have the range set to 20 - 40% with 30% being the default value.
I'll update to 10-30% instead
Thank you
@ConnectedSystems, please let me know when you're ready to run a set.
@ConnectedSystems and @Rosejoycrocker
An update of intervention modelling specs (from Juan) in 2022 are:
Aquaculture: Five (5) years of deployment of 1 million corals per annum. Assume different levels of thermal enhancement as defined above. This should include zero DHW enhancement.
Only change to plan here is that we don't deploy for 10 years, but only for 5 years. The zero-enhancement option is to simulate larval slicks.
Fogging: Every year deployment of one fogging unit covering 4.5 KM2 of reef area in the Moore Reef cluster, causing 20% reduction in light.
We are not set up to concentrate fogging on preferred sites within a reef, so I suggest we go ahead as is. Maybe we can update when @Rosejoycrocker is back (using the 'priority sites' option), if we have time.
Closing this issue due to impending submission of the March report. Thanks everyone!
Key Intervention parameter values for Moore and Brick clusters.