Change latitude dependence of critical daylength onset to is_cold_type PFT dependence

[ekluzek]

The current implementation of triggering for critical daylength for CTSM5.1 depends on latitude rather than plant type. It uses 15 hours for higher latitudes and goes down to about 11 hours. We think that it would be better if this was handled so that it was higher for arctic plant types (like needleleaf_evergreen_boreal_tree, needleleaf_deciduous_boreal_tree, broadleaf_deciduous_boreal_tree, broadleaf_deciduous_boreal_shrub, and c3_arctic_grass), This could be handled by adding a "is_cold_type" parameter on the parameter files that define the above list as .true. and others as .false.

This was originally suggested here...

#947 (comment)

@wwieder notes that the current implementation can be seen in plots with a line along latitude. As such this is something that should be fixed.

Because PFT's don't neatly fall into only high latitude or temperate, this will change answers and will need to be assessed scientifically.

[wwieder]

@olyson let's talk about this when you're back. Should be pretty straightforward.

[olyson]

Yep, back on the 6th.

[ekluzek]

Since, this occurs in seasonal_decidious in CNPhenology, that means it doesn't apply to evergreen, so needleleaf_evergreen_boreal_tree is dropped off the list.

[olyson]

@wwieder let me know when you want to talk about this.

[ekluzek]

@wwieder and @olyson I have a start at an option for this in terms of an option. I'll need you to tune parameters, calibrate and test it scientifically. Could the three of us meet to discuss? Can someone propose a time for the three of us to talk?

[wwieder]

here's a suggested list of is_cold_type.
We can also discuss the critical day length parameterization.

[ekluzek]

It turns out Leah already has this, but in reverse. All of the seasonal_decidious types are arctic or boreal -- except for the one that's marked as seasonal_decidious_temperate. So we don't really need a new type -- we just use the existing ones.

[ekluzek]

The three of us met and talked this over. The plan is for me to add an additional option that only does the latitude dependence over the non-temperate seasonal deciduous plants. So we'll have four options like this:

-- constant
-- latitude dependence
-- One constant for temperate and another for arctic
-- latitude dependence for arctic and constant for temperate

What Will remembered was that the line he saw was at something like 45 degree's and we think it was because the latitude dependence for temperate trees. So we think that last option will the right way to handle this.

[ekluzek]

OK I have a namelist item (min_crtical_dayl_method) in place on PR #1164 that looks like this...

Method for determining what the minimum critical day length for seasonal decidious leaf onset depends on
Constant ----------- constant value of crit_dayl from parameter file
DependsOnLat ------- Higher values at high latitudes down to value from parameter file for temperate and equatorial regions
DependsOnVeg ------- Arctic vegetation with higher value and temperate vegetation with crit_dayl from parameter file
DependsOnLatAndVeg - Arctic vegetation depends on latitude as above, but temperate vegetation fixed at crit_dayl value from parameter file
(only used when CN is on)

[wwieder]

I think this makes sense, @ekluzek . When Cheyenne is back up and Erik has a tag ready can you run tests with these 4 options, Keith? Here's are my questions for this testing:

• Are we OK to do this with the sparse grid and/or sasu?
• Do we need full transient runs, or just spinup for an i2000 case?
• Which option is the 'baseline' case that we're using now for comparison?
• Do we need any higher frequency output to look at differences in phenology between each option?
• What tag does Keith use for testing?

[wwieder]

@ekluzek are you also wanting us to review the changes you made to CNPhenology in #1164?

[ekluzek]

Not, yet although I'm close to that point. So I'll let you know. And I'll let you know when I have a tag. I figure you don't need one until cheyenne is up, so I'll postpone until then. The baseline case for clm5_1 as we have it now is DependsOnLat. clm5_0 and previous use Constant. These give identical results to previous versions. DependsOnVeg and DependsOnLatAndVeg are the two new experimental options. I'm also putting some of the parameters on the paramsfile so you could tune some of the "depends on latitude" configurations.

If you want to run this with SASU, I'll need to create a branch that has CN-Matrix merged in. Which I should be able to do. But, it would be an extra step.

This should work with the sparse grid. I imagine that phenology has been changing and likely will change even more into the future, so you might want a transient case just to make sure behavior is reasonable for that.

The PPE branch is based off an older CTSM version, so you might need to redo the control.

[olyson]

We have an "official" CLM5.1 set of simulations that used the cesm2_3_alpha02c tag combined with PPE.n08_ctsm5.1.dev030 which has all of the CLM5.1 science in it (including Leah's changes and SASU-capability). It would be nice to build off of that. So could the PPE branch be updated with the new master tag that has these new functions once it's done?

These simulations used SASU for spinup and I ran a full-grid historical, so I'd suggest doing the same thing here.

[wwieder]

This seems like a good suggestion, @olyson

[ekluzek]

OK, what I can do is to create a new branch where I rebase it to ctsm5.1.dev030, and then I'll be able to add it to the end of the PPE branch. It'll take some extra work to do that, but I can do it. Then the PPE branch will have these changes on top of the CN-Matrix and everything else. I won't be able to do that Monday, but I can probably get that done next week.

[olyson]

Actually, what I was wondering about was waiting until PR #1164 was put on master (looks like it will be part of the planned hardcodep tag) and then update the PPE tag with that new master tag. That wouldn't be extra work would it?

[ekluzek]

OK, I can do that. And that would be less work. But, that does mean the latest PPE branch would give different answers than the one used previously and currently being used. @djk2120 wanted to try to avoid that if possible. There's been some answer changes since ctsm5.1.dev030 so it might require you redoing your control experiments. If we want to keep the PPE branch fixed at ctsm5.1.dev030 we need to go with my first suggestion. It shouldn't be too hard to do nor take too much time, but it will be greater than zero. So it depends on how important it is to keep the PPE branch fixed at ctsm5.1.dev030. Note, also that one solution makes software work for me, but the other creates additional science work for you all (since answers change). There's no solution that minimizes work for all. But, I'm inclined to think that the science might be best served to being fixed to ctsm5.1.dev030 for the PPE branch.

[olyson]

Got it, thanks for the clarification, I wasn't aware of the requirement for the PPE branch.
Not sure what's best then, I'll leave it up to those who have knowledge of the overall strategy for the workflow.

[wwieder]

we can discuss this on Thursday, but if you're wanting to make progress sooner @ekluzek, would it be helpful to have brief discussion with @dlawrenncar? I have to admit my head is kind of spinning with all the branches you're having to maintain particular developments on.

[dlawrenncar]

In general, I think we should strive to keep the workload as small as possible. I don't know that we absolutely need the ppe branch to be fixed at ctsm5.1.dev030, especially if the changes are going to be small to possibly almost undetectable. So, in this instance, I would go with the smallest workload option.

…

On Mon, Aug 2, 2021 at 7:17 AM will wieder ***@***.***> wrote: we can discuss this on Thursday, but if you're wanting to make progress sooner @ekluzek <https://github.com/ekluzek>, would it be helpful to have brief discussion with @dlawrenncar <https://github.com/dlawrenncar>? I have to admit my head is kind of spinning with all the branches you're having to maintain particular developments on. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1409 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFABYVB7UZTF5LYNFO2F5FTT22LGFANCNFSM47I3CCDA> .