Update fire scheme

[lifang0209]

The Li fire scheme will be developed from the following aspects:
(1) incorporating multi-day fires, the influence of landscape fragmentation on fire spread, and NET Boreal NA canopy fires;
(2) recalibrating parameters for modeling peat, deforestation fires, and socio-economic influences;
(3) updating the fire emission factor file;
(4) updating the fire input data to include a new peatland map, the timing of crop fires, and transitioning from a fixed 2001 GDP/capita to a time-varying GDP/capita.

[wwieder]

Thanks for creating this issue, @lifang0209.

We're under a pretty tight deadline for a capability code freeze in June. It would be helpful to see a draft PR for this so we can scope out how much work will be involved in bringing in your changes.

One hang up is always related to datasets. How are you handling the new input data needed for #(4) on your list above?

[wwieder]

I also see that @samsrabin labeled this with the ctsm6.1 milestone, which is likely more appropriate, as it will let us evaluate and calibrate results more closely.

This timeline also means that the CESM3-esm simulations used in the CMIP7_fasttrack experiments will likely be using the older (CLM5) fire scheme?

[samsrabin]

(In an email thread, Fang mentions that she plans to submit a PR next week.)

[lifang0209]

@wwieder For the peatland map and the timing of crop fires, I need to update them in the surface data. Additionally, the time-varying GDP per capita should be incorporated as time-varying population density.

[ekluzek]

Since, the population density is a separate stream file it will be easy to update it.

Changes to surface datasets is a bigger thing though. Initially we could bring it in with just a few experimental datasets. But, longer term we'll want to make ALL new surface datasets which is a bigger deal and one that means a minor version update (for example from ctsm5.2.XXX to ctsm5.3.0). There is such an update going on right now, but I don't see that we can merge these two efforts together by the end of June. So this part would need to be after the CESM3.0 release. But, could be in one of the follow on releases afterwards.

Another way to do it though would be if this data could be moved off of the surface dataset and onto a stream file for example. If the data is tightly coupled to other surface data we might not be able to do that. But, for example the GDP data likely could be. And it looks like maybe peatf and abm could as well?

[samsrabin]

Of the listed variables, the only one I would be hesitant about moving to a stream file would be crop fire timing. We wouldn't want to allow spatial or temporal interpolation because it's a modulo axis—halfway between Jan. 2 (day 2) and Dec. 31 (day 365) is Jan. 1 (day 1), not July 3 (rounding up from day [365+2]/2 = 183.5). On the other hand, we could use a stream file and just set interpolation to nearest neighbor—depends on what Fang thinks.

[samsrabin]

But @lifang0209, I should say: You don't need to worry yet about moving variables from the surface dataset to stream files. It'd be best to get a PR with the code you have ready; then later we can work out a plan for any changes.

[lifang0209]

@samsrabin Great! In the surface dataset, I use a resolution of f19_g17. If you move variables to stream files, which spatial resolution do you need? I could make that for you, e.g. 0.25 degree.

[samsrabin]

We would probably want the stream files at the finest possible native resolution for each input dataset.

[ekluzek]

Oh, yes thanks for that point @samsrabin. The most important thing is to see the PR as it is, and we'll figure out what needs to be done with it. It really helps to see it as a work in progress earlier rather than later so we can collaborate together on it. I think sometimes people feel uncomfortable with their work being "out there" and want to get it perfect before making a PR. But, really to have the best possible PR that really highlights your contributions having a PR that's worked on with the team gets us there quicker and more efficiently. We recognize and value the work that everyone puts in providing a PR and will work in a team shared-responsibility manner to make it the best possible for CTSM. Sometimes people are unfairly embarrassed by their code that maybe needs some work. But, we all write bad code for many different reasons, but the team work on seeing it early and improving it makes it better for everyone.

And @lifang0209 this is not just an issue with you, it's with almost everyone that contributes code. So I want to emphasize that shared responsibility ethic to everyone. I'm speculating with you a bit here, but it is a common feeling among almost everyone.

[lifang0209]

@ekluzek Thanks for your guidance and support. I'm doing a final check on the update of input data and preparing finer-resolution versions for you to use. I will submit my PRs ASAP. This should help us all collaborate more effectively and achieve the high standards we set for our work at CTSM.

[wwieder]

After further discussing this PR at our SE meeting today I think it's clear that the LMWG will not be able to get this PR onto main by the June 30 code freeze. I'm happy to outline what needs to happen to bring in this work and make it available to the community, but it's a larger discussion about deadlines and priorities for the default configuration of CESM3.

[lifang0209]

@wwieder The PR will be ready by next week. The additional time is being used to enhance the quality of the submission, ensuring that it meets our high standards.