Read in full LUH2 dataset for use by FATES

[ekluzek]

FATES is going to use the area option for harvest variables from a streams file rather than the mass option (on the landuse.timeseries files). Hence, we'll need to support both variables on the new landuse.timeseries files.

It looks like what we really need is to read in the raw LUH2 harvest data for FATES as a stream file. In the landuse.timeseries files harvest is per PFT, but what FATES needs is the total, rather than resolved by PFT.

Definition of Done: CTSM/FATES reads in full LUH2 data and uses it in FATES

[ekluzek]

So mksurfdata_map will need to add both variables to the files. And CTSM will need a namelist option to select if you want to use area or mass

@ckoven

See PR #1040

EDIT: We aren't going to do this but will do separate streams files..

[ekluzek]

Another potential wrinkle is that FATES really wants the totals and not allocated out by PFT.

[dlawrenncar]

In fact, at the end of discussion today, we started thinking that maybe what is really needed is to generate a direct regridded mapping of LUH2 data for use in FATES, including other transition information outside of harvest. Any chance that streams could be utilized? Would require conservative remapping.

…

On Tue, Jul 7, 2020 at 5:19 PM Erik Kluzek ***@***.***> wrote: Another potential wrinkle is that FATES really wants the totals and not allocated out by PFT. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1077 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFABYVEJVK46EHGDMGOU6SLR2OUPFANCNFSM4OTZYKNQ> .

[ekluzek]

Streams in the MCT coupler can't do conservative mapping. But, I'm pretty sure the NUOPC coupler can do conservative. And I would think it should be easy to add even if isn't. Since, the NUOPC coupler is the next version for CESM, if it would be OK to have these two happen at the same time, that would be one way forward. Or we could start with bilinear with the MCT coupler, and add conservative when it's available for NUOPC.

[mvertens]

The streams are not in the MCT coupler. They are in the data models. The MCT data models cannot do conservative mapping UNLESS you create offline mapping files and point to them as part of the input namelist. The new NUOPC data models (which are being tested right now) can do online conservative remapping from the stream mesh to the model mesh very easily. They can also be called directly from CLM to do this mapping. I am happy to provide more details if needed.

…

On Tue, Jul 7, 2020 at 8:12 PM Erik Kluzek ***@***.***> wrote: Streams in the MCT coupler can't do conservative mapping. But, I'm pretty sure the NUOPC coupler can do conservative. And I would think it should be easy to add even if isn't. Since, the NUOPC coupler is the next version for CESM, if it would be OK to have these two happen at the same time, that would be one way forward. Or we could start with bilinear with the MCT coupler, and add conservative when it's available for NUOPC. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1077 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB4XCEZLJ3OP64ZFA4M2UJTR2PIZ7ANCNFSM4OTZYKNQ> .

-- Mariana Vertenstein CESM Software Engineering Group Head National Center for Atmospheric Research Boulder, Colorado Office 303-497-1349 Email: mvertens@ucar.edu

[ekluzek]

OK, plan is we'll bring in Charilie's PR as is, which will be using data that isn't really correct for how it's used. We'll bring in the LUH2 data (that @lawrencepj1 must have downloaded already) as streams data. For the MCT coupler we'll do this with a conservative mapping file. We'll be able to get this working in the NUOPC coupler without the need for mapping files.

[ekluzek]

The rawdata files that we already list in the XML database has the total harvest NOT segregated out by PFT so this might be what we want to use. It is stored in units of mass rather than area, so we might need to convert it.

        double HARVEST_VH1(lat, lon) ;
                HARVEST_VH1:long_name = "harvest from primary forest" ;
                HARVEST_VH1:units = "gC/m2/yr" ;
                HARVEST_VH1:_FillValue = -9999. ;
        double HARVEST_VH2(lat, lon) ;
                HARVEST_VH2:long_name = "harvest from primary non-forest" ;
                HARVEST_VH2:units = "gC/m2/yr" ;
                HARVEST_VH2:_FillValue = -9999. ;
        double HARVEST_SH1(lat, lon) ;
                HARVEST_SH1:long_name = "harvest from secondary mature-forest" ;
                HARVEST_SH1:units = "gC/m2/yr" ;
                HARVEST_SH1:_FillValue = -9999. ;
        double HARVEST_SH2(lat, lon) ;
                HARVEST_SH2:long_name = "harvest from secondary young-forest" ;
                HARVEST_SH2:units = "gC/m2/yr" ;
                HARVEST_SH2:_FillValue = -9999. ;
        double HARVEST_SH3(lat, lon) ;
                HARVEST_SH3:long_name = "harvest from secondary non-forest" ;
                HARVEST_SH3:units = "gC/m2/yr" ;
                HARVEST_SH3:_FillValue = -9999. ;
        double GRAZING(lat, lon) ;
                GRAZING:long_name = "grazing of herbacous pfts" ;
                GRAZING:units = "gC/m2/yr" ;
                GRAZING:_FillValue = -9999. ;

[ckoven]

Hi @ekluzek, see the metadata for the input4mips land use data that I pasted into an old FATES comment a while ago -- they have it by area too I think? NGEET/fates#491 (comment)

[ekluzek]

One, thing I wasn't sure about was if we could have multiple filenames for streams files in CTSM as we haven't done that before. But, I just checked and it asks for an array of filenames, we just always only give it a single one. So we will be able to do that. It's just we'll have to have a namelist that has a long list of filenames. We can make the filenames list separate from the directory, but it will still be a long list. But, since we use build-namelist to make the namelist for us, and these files are already listed in the XML database, it won't be hard to do.

So we just need to make sure the rawdata files have both mass and area units on them.