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: [email protected]

[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.

[dlawrenncar]

The metadata that @ekluzek pointed to is from data that has been post-processed by Peter in some manner. We want to use the raw LUH2 data as noted in the FATES issue #491 that @ckoven pointed to. For each scenario (e.g., scenario, SSP, alternate scenario), there are 3 files (transitions.nc, states.nc, and management.nc )

See here for examples: /glade/p/cesm/sdwg_dev/thesis/data/cesm_tools/lumipfinallcc
cd historicLUH2_181217.

Here are the harvest variables including both area and mass based harvest.

ncdump -h transitions.nc | grep harvest
primf_harv:long_name = "wood harvest area from primary forest land" ;
primn_harv:long_name = "wood harvest area from primary non forest land" ;
secmf_harv:long_name = "wood harvest area from secondary mature forest land" ;
secyf_harv:long_name = "wood harvest area from secondary young forest land " ;
secnf_harv:long_name = "wood harvest area from secondary non forest land " ;
primf_bioh:long_name = "wood harvest biomass carbon from primary forest land" ;
primn_bioh:long_name = "wood harvest biomass carbon from primary non forest land" ;
secmf_bioh:long_name = "wood harvest biomass carbon from secondary mature forest land" ;
secyf_bioh:long_name = "wood harvest biomass carbon from secondary young forest land" ;
secnf_bioh:long_name = "wood harvest biomass carbon from secondary non forest land" ;

All the transitions are in that file as well. Just listing 10 or so here (there are 50+ transitions). I believe that included in these are the transitions required to be able to do a full land cover / use change implementation (i.e., deforestation for crop or pastureland). Obviously, this is a lot of data so will need to carefully consider what FATES and/or CTSM needs, but if we can read in and regrid via streams it will hopefully be relatively straightforward to add required transitions.

ncdump -h transitions.nc | grep transition
primf_to_secdn:standard_name = "transition from forested primary land to potentially non-forested secondary land" ;
primf_to_urban:standard_name = "transition from forested primary land to urban land" ;
primf_to_c3ann:standard_name = "transition from forested primary land to C3 annual crops" ;
primf_to_c4ann:standard_name = "transition from forested primary land to C4 annual crops" ;
primf_to_c3per:standard_name = "transition from forested primary land to C3 perennial crops" ;
primf_to_c4per:standard_name = "transition from forested primary land to C4 perennial crops" ;
primf_to_c3nfx:standard_name = "transition from forested primary land to C3 nitrogen-fixing crops" ;
primf_to_pastr:standard_name = "transition from forested primary land to managed pasture" ;
primf_to_range:standard_name = "transition from forested primary land to rangeland" ;
primn_to_secdf:standard_name = "transition from non-forested primary land to potentially forested secondary land" ;
primn_to_urban:standard_name = "transition from non-forested primary land to urban land" ;

EDIT: These files are still there as of Dec/1/2022. The management file is 1.4GB, states is 5.8GB, and transitions is 16GB.

[ekluzek]

OK, it looks like with a small amount of processing we could use those datasets for streams into CTSM/FATES. There's only two things I noticed. One is that we need a creation date on the filenames, and we'd need to enter them into CESM inputdata. The other thing is that time is in units of "years since ...", we'd need to convert that to "days since ...".

The other thing to do for these datasets would be to enter all of these datasets into the XML database. That was one reason I was interested in the rawdata files that @lawrencepj1 processed, because we already have all those entered in. But, since these datasets have multiple years on single files, there still wouldn't be that many datasets to enter in. And of course we'd just enter the ones that are important at the time.

Finally as Dave points out this dataset has a whole ton more of variables, whereas the rawdata files are processed down into just a few. But, yes it looks like we could read in and regrid these datasets using streams without too much work.

[dlawrenncar]

I think this is clear, but I'll restate anyway in case it isn't. One of the benefits of using the LUH2 source data is that it DOES include all these extra fields that will be needed in LUH2 but are not needed in CTSM big leaf. Plus, it will also be easier to update to LUH3 or if other new SSPs are created, for example. No extra processing (other than modifying time units, etc) would be required.

…

On Thu, Jul 9, 2020 at 3:30 PM Erik Kluzek ***@***.***> wrote: OK, it looks like with a small amount of processing we could use those datasets for streams into CTSM/FATES. There's only two things I noticed. One is that we need a creation date on the filenames, and we'd need to enter them into CESM inputdata. The other thing is that time is in units of "years since ...", we'd need to convert that to "days since ...". The other thing to do for these datasets would be to enter all of these datasets into the XML database. That was one reason I was interested in the rawdata files that @lawrencepj1 <https://github.com/lawrencepj1> processed, because we already have all those entered in. But, since these datasets have multiple years on single files, there still wouldn't be that many datasets to enter in. And of course we'd just enter the ones that are important at the time. Finally as Dave points out this dataset has a whole ton more of variables, whereas the rawdata files are processed down into just a few. But, yes it looks like we could read in and regrid these datasets using streams without too much work. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1077 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFABYVFNVB2LUA4LMBIPUDDR2YZH5ANCNFSM4OTZYKNQ> .

[lawrencepj1]

One thing that you might consider is that there is no land mask or land frac data on the LUH2 data sets and the indexing for latitude is the opposite direction to the raw data 89.875 ... -89.875 rather than -89.875 ... 89.875 -- Dr Peter Lawrence Terrestrial Science Section National Center for Atmospheric Research 1850 Table Mesa Drive Boulder Colorado 80305 Work: 1-303-497-1727 Cell: 1-303-956-6932 On Thu, Jul 9, 2020 at 3:42 PM David Lawrence <[email protected]> wrote:

…

I think this is clear, but I'll restate anyway in case it isn't. One of the benefits of using the LUH2 source data is that it DOES include all these extra fields that will be needed in LUH2 but are not needed in CTSM big leaf. Plus, it will also be easier to update to LUH3 or if other new SSPs are created, for example. No extra processing (other than modifying time units, etc) would be required. On Thu, Jul 9, 2020 at 3:30 PM Erik Kluzek ***@***.***> wrote: > OK, it looks like with a small amount of processing we could use those > datasets for streams into CTSM/FATES. There's only two things I noticed. > One is that we need a creation date on the filenames, and we'd need to > enter them into CESM inputdata. The other thing is that time is in units of > "years since ...", we'd need to convert that to "days since ...". > > The other thing to do for these datasets would be to enter all of these > datasets into the XML database. That was one reason I was interested in the > rawdata files that @lawrencepj1 <https://github.com/lawrencepj1> > processed, because we already have all those entered in. But, since these > datasets have multiple years on single files, there still wouldn't be that > many datasets to enter in. And of course we'd just enter the ones that are > important at the time. > > Finally as Dave points out this dataset has a whole ton more of variables, > whereas the rawdata files are processed down into just a few. But, yes it > looks like we could read in and regrid these datasets using streams without > too much work. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <#1077 (comment)>, or > unsubscribe > < https://github.com/notifications/unsubscribe-auth/AFABYVFNVB2LUA4LMBIPUDDR2YZH5ANCNFSM4OTZYKNQ > > . > — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1077 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC3OJOMSHOVDI6FXPEJAJ63R2Y2TNANCNFSM4OTZYKNQ> .

[ekluzek]

In ctsm5.1.dev022 we started allowing FATES to run for transient cases.

[ekluzek]

In order to use conservative remapping for these streams we will need to resolve #1912.

[ekluzek]

In our meeting today, @lawrencepj1 talked about the need to clean up some of the data, so it's cleaned and more CTSM-ified. So there's probably pre-processing that needs to happen before we read it into CTSM. We can use his scripts that clean and process the data to just do the first part.

The difference in latitudes shouldn't be a problem, we just need a mesh file that describes what the mesh is and that the latitudes go the opposite directions from other grids.

[ekluzek]

OK, in the meeting we went back to the idea of adding this to the landuse.timeseries files again. @lawrencepj1 could you lay out what the raw data files would look like for this method, and how it would appear on the landuse.timeseries files? I think having that would really help so I could picture what this would look like.

[lawrencepj1]

Hi @ekluzek

Thanks for capturing this. My suggested framework would be to add an extra level of detail on the surface and landuse timeseries files such that we keep the information that is specified in the LUH2 data. Currently we lose that in the combination of data to put it in CTSM/CLM format of only having a single set of PFTs for all natural vegetation. This could look like this:

PCT_NAT_VEG
-> PCT_PRIMARY_FOREST
-> PCT_PRIMF_PFT (0 .. 14)
-> PCT_SECONDARY_FOREST
-> PCT_SECDF_PFT (0 .. 14)
-> PCT_PRIMARY_NONFOREST
-> PCT_PRIMN_PFT (0 .. 14)
-> PCT_SECONDARY_NONFOREST
-> PCT_SECDN_PFT (0 .. 14)
-> PCT_PASTURE
-> PCT_PASTR_PFT (0 .. 14)
-> PCT_RANGELAND
-> PCT_RANGE_PFT (0 .. 14)

We already have the Wood Harvest carbon amount divided out into primf, primn, secmf, secyf, secnf.

[lawrencepj1]

And the other element we would like to have is a method of incorporating hillslope hydrology connectivity aspect and slope into these datasets

[wwieder]

I'd love to be able to bring hillslope into this, but can we focus on getting FATES what it needs first to avoid dragging this out too long?

[lawrencepj1]

@wwieder ha ha ha yes just wanted to put that out as a longer term goal

[ckoven]

Hi all, thanks for continuing this discussion. @lawrencepj1 you list out the state data but I'm curious about the relative pros and cons of using the transitions data rather than the state data (or both). In principle I think that the way that FATES will actually use this is as a rate rather than a change in states, so wouldn't that be the more natural data to drive the model with? Dumping out the LUH2 transitions netcdf metadata gives the following. Would it make sense to include that data either in addition to or instead of the state data? Obviously some of the transitions (e.g. to/from urban) won't be something that FATES knows what to do with but for others it will.

	float primf_to_secdn(time, lat, lon) ;
		primf_to_secdn:standard_name = "transition from forested primary land to potentially non-forested secondary land" ;
	float primf_to_urban(time, lat, lon) ;
		primf_to_urban:standard_name = "transition from forested primary land to urban land" ;
	float primf_to_c3ann(time, lat, lon) ;
		primf_to_c3ann:standard_name = "transition from forested primary land to C3 annual crops" ;
	float primf_to_c4ann(time, lat, lon) ;
		primf_to_c4ann:standard_name = "transition from forested primary land to C4 annual crops" ;
	float primf_to_c3per(time, lat, lon) ;
		primf_to_c3per:standard_name = "transition from forested primary land to C3 perennial crops" ;
	float primf_to_c4per(time, lat, lon) ;
		primf_to_c4per:standard_name = "transition from forested primary land to C4 perennial crops" ;
	float primf_to_c3nfx(time, lat, lon) ;
		primf_to_c3nfx:standard_name = "transition from forested primary land to C3 nitrogen-fixing crops" ;
	float primf_to_pastr(time, lat, lon) ;
		primf_to_pastr:standard_name = "transition from forested primary land to managed pasture" ;
	float primf_to_range(time, lat, lon) ;
		primf_to_range:standard_name = "transition from forested primary land to rangeland" ;
	float primn_to_secdf(time, lat, lon) ;
		primn_to_secdf:standard_name = "transition from non-forested primary land to potentially forested secondary land" ;
	float primn_to_urban(time, lat, lon) ;
		primn_to_urban:standard_name = "transition from non-forested primary land to urban land" ;
	float primn_to_c3ann(time, lat, lon) ;
		primn_to_c3ann:standard_name = "transition from non-forested primary land to C3 annual crops" ;
	float primn_to_c4ann(time, lat, lon) ;
		primn_to_c4ann:standard_name = "transition from non-forested primary land to C4 annual crops" ;
	float primn_to_c3per(time, lat, lon) ;
		primn_to_c3per:standard_name = "transition from non-forested primary land to C3 perennial crops" ;
	float primn_to_c4per(time, lat, lon) ;
		primn_to_c4per:standard_name = "transition from non-forested primary land to C4 perennial crops" ;
	float primn_to_c3nfx(time, lat, lon) ;
		primn_to_c3nfx:standard_name = "transition from non-forested primary land to C3 nitrogen-fixing crops" ;
	float primn_to_pastr(time, lat, lon) ;
		primn_to_pastr:standard_name = "transition from non-forested primary land to managed pasture" ;
	float primn_to_range(time, lat, lon) ;
		primn_to_range:standard_name = "transition from non-forested primary land to rangeland" ;
	float secdf_to_secdn(time, lat, lon) ;
		secdf_to_secdn:standard_name = "transition from potentially forested secondary land to potentially non-forested secondary land" ;
	float secdf_to_urban(time, lat, lon) ;
		secdf_to_urban:standard_name = "transition from potentially forested secondary land to urban land" ;
	float secdf_to_c3ann(time, lat, lon) ;
		secdf_to_c3ann:standard_name = "transition from potentially forested secondary land to C3 annual crops" ;
	float secdf_to_c4ann(time, lat, lon) ;
		secdf_to_c4ann:standard_name = "transition from potentially forested secondary land to C4 annual crops" ;
	float secdf_to_c3per(time, lat, lon) ;
		secdf_to_c3per:standard_name = "transition from potentially forested secondary land to C3 perennial crops" ;
	float secdf_to_c4per(time, lat, lon) ;
		secdf_to_c4per:standard_name = "transition from potentially forested secondary land to C4 perennial crops" ;
	float secdf_to_c3nfx(time, lat, lon) ;
		secdf_to_c3nfx:standard_name = "transition from potentially forested secondary land to C3 nitrogen-fixing crops" ;
	float secdf_to_pastr(time, lat, lon) ;
		secdf_to_pastr:standard_name = "transition from potentially forested secondary land to managed pasture" ;
	float secdf_to_range(time, lat, lon) ;
		secdf_to_range:standard_name = "transition from potentially forested secondary land to rangeland" ;
	float secdn_to_secdf(time, lat, lon) ;
		secdn_to_secdf:standard_name = "transition from potentially non-forested secondary land to potentially forested secondary land" ;
	float secdn_to_urban(time, lat, lon) ;
		secdn_to_urban:standard_name = "transition from potentially non-forested secondary land to urban land" ;
	float secdn_to_c3ann(time, lat, lon) ;
		secdn_to_c3ann:standard_name = "transition from potentially non-forested secondary land to C3 annual crops" ;
	float secdn_to_c4ann(time, lat, lon) ;
		secdn_to_c4ann:standard_name = "transition from potentially non-forested secondary land to C4 annual crops" ;
	float secdn_to_c3per(time, lat, lon) ;
		secdn_to_c3per:standard_name = "transition from potentially non-forested secondary land to C3 perennial crops" ;
	float secdn_to_c4per(time, lat, lon) ;
		secdn_to_c4per:standard_name = "transition from potentially non-forested secondary land to C4 perennial crops" ;
	float secdn_to_c3nfx(time, lat, lon) ;
		secdn_to_c3nfx:standard_name = "transition from potentially non-forested secondary land to C3 nitrogen-fixing crops" ;
	float secdn_to_pastr(time, lat, lon) ;
		secdn_to_pastr:standard_name = "transition from potentially non-forested secondary land to managed pasture" ;
	float secdn_to_range(time, lat, lon) ;
		secdn_to_range:standard_name = "transition from potentially non-forested secondary land to rangeland" ;
	float urban_to_secdf(time, lat, lon) ;
		urban_to_secdf:standard_name = "transition from urban land to potentially forested secondary land" ;
	float urban_to_secdn(time, lat, lon) ;
		urban_to_secdn:standard_name = "transition from urban land to potentially non-forested secondary land" ;
	float urban_to_c3ann(time, lat, lon) ;
		urban_to_c3ann:standard_name = "transition from urban land to C3 annual crops" ;
	float urban_to_c4ann(time, lat, lon) ;
		urban_to_c4ann:standard_name = "transition from urban land to C4 annual crops" ;
	float urban_to_c3per(time, lat, lon) ;
		urban_to_c3per:standard_name = "transition from urban land to C3 perennial crops" ;
	float urban_to_c4per(time, lat, lon) ;
		urban_to_c4per:standard_name = "transition from urban land to C4 perennial crops" ;
	float urban_to_c3nfx(time, lat, lon) ;
		urban_to_c3nfx:standard_name = "transition from urban land to C3 nitrogen-fixing crops" ;
	float urban_to_pastr(time, lat, lon) ;
		urban_to_pastr:standard_name = "transition from urban land to managed pasture" ;
	float urban_to_range(time, lat, lon) ;
		urban_to_range:standard_name = "transition from urban land to rangeland" ;
	float c3ann_to_secdf(time, lat, lon) ;
		c3ann_to_secdf:standard_name = "transition from C3 annual crops to potentially forested secondary land" ;
	float c3ann_to_secdn(time, lat, lon) ;
		c3ann_to_secdn:standard_name = "transition from C3 annual crops to potentially non-forested secondary land" ;
	float c3ann_to_urban(time, lat, lon) ;
		c3ann_to_urban:standard_name = "transition from C3 annual crops to urban land" ;
	float c3ann_to_c4ann(time, lat, lon) ;
		c3ann_to_c4ann:standard_name = "transition from C3 annual crops to C4 annual crops" ;
	float c3ann_to_c3per(time, lat, lon) ;
		c3ann_to_c3per:standard_name = "transition from C3 annual crops to C3 perennial crops" ;
	float c3ann_to_c4per(time, lat, lon) ;
		c3ann_to_c4per:standard_name = "transition from C3 annual crops to C4 perennial crops" ;
	float c3ann_to_c3nfx(time, lat, lon) ;
		c3ann_to_c3nfx:standard_name = "transition from C3 annual crops to C3 nitrogen-fixing crops" ;
	float c3ann_to_pastr(time, lat, lon) ;
		c3ann_to_pastr:standard_name = "transition from C3 annual crops to managed pasture" ;
	float c3ann_to_range(time, lat, lon) ;
		c3ann_to_range:standard_name = "transition from C3 annual crops to rangeland" ;
	float c4ann_to_secdf(time, lat, lon) ;
		c4ann_to_secdf:standard_name = "transition from C4 annual crops to potentially forested secondary land" ;
	float c4ann_to_secdn(time, lat, lon) ;
		c4ann_to_secdn:standard_name = "transition from C4 annual crops to potentially non-forested secondary land" ;
	float c4ann_to_urban(time, lat, lon) ;
		c4ann_to_urban:standard_name = "transition from C4 annual crops to urban land" ;
	float c4ann_to_c3ann(time, lat, lon) ;
		c4ann_to_c3ann:standard_name = "transition from C4 annual crops to C3 annual crops" ;
	float c4ann_to_c3per(time, lat, lon) ;
		c4ann_to_c3per:standard_name = "transition from C4 annual crops to C3 perennial crops" ;
	float c4ann_to_c4per(time, lat, lon) ;
		c4ann_to_c4per:standard_name = "transition from C4 annual crops to C4 perennial crops" ;
	float c4ann_to_c3nfx(time, lat, lon) ;
		c4ann_to_c3nfx:standard_name = "transition from C4 annual crops to C3 nitrogen-fixing crops" ;
	float c4ann_to_pastr(time, lat, lon) ;
		c4ann_to_pastr:standard_name = "transition from C4 annual crops to managed pasture" ;
	float c4ann_to_range(time, lat, lon) ;
		c4ann_to_range:standard_name = "transition from C4 annual crops to rangeland" ;
	float c3per_to_secdf(time, lat, lon) ;
		c3per_to_secdf:standard_name = "transition from C3 perennial crops to potentially forested secondary land" ;
	float c3per_to_secdn(time, lat, lon) ;
		c3per_to_secdn:standard_name = "transition from C3 perennial crops to potentially non-forested secondary land" ;
	float c3per_to_urban(time, lat, lon) ;
		c3per_to_urban:standard_name = "transition from C3 perennial crops to urban land" ;
	float c3per_to_c3ann(time, lat, lon) ;
		c3per_to_c3ann:standard_name = "transition from C3 perennial crops to C3 annual crops" ;
	float c3per_to_c4ann(time, lat, lon) ;
		c3per_to_c4ann:standard_name = "transition from C3 perennial crops to C4 annual crops" ;
	float c3per_to_c4per(time, lat, lon) ;
		c3per_to_c4per:standard_name = "transition from C3 perennial crops to C4 perennial crops" ;
	float c3per_to_c3nfx(time, lat, lon) ;
		c3per_to_c3nfx:standard_name = "transition from C3 perennial crops to C3 nitrogen-fixing crops" ;
	float c3per_to_pastr(time, lat, lon) ;
		c3per_to_pastr:standard_name = "transition from C3 perennial crops to managed pasture" ;
	float c3per_to_range(time, lat, lon) ;
		c3per_to_range:standard_name = "transition from C3 perennial crops to rangeland" ;
	float c4per_to_secdf(time, lat, lon) ;
		c4per_to_secdf:standard_name = "transition from C4 perennial crops to potentially forested secondary land" ;
	float c4per_to_secdn(time, lat, lon) ;
		c4per_to_secdn:standard_name = "transition from C4 perennial crops to potentially non-forested secondary land" ;
	float c4per_to_urban(time, lat, lon) ;
		c4per_to_urban:standard_name = "transition from C4 perennial crops to urban land" ;
	float c4per_to_c3ann(time, lat, lon) ;
		c4per_to_c3ann:standard_name = "transition from C4 perennial crops to C3 annual crops" ;
	float c4per_to_c4ann(time, lat, lon) ;
		c4per_to_c4ann:standard_name = "transition from C4 perennial crops to C4 annual crops" ;
	float c4per_to_c3per(time, lat, lon) ;
		c4per_to_c3per:standard_name = "transition from C4 perennial crops to C3 perennial crops" ;
	float c4per_to_c3nfx(time, lat, lon) ;
		c4per_to_c3nfx:standard_name = "transition from C4 perennial crops to C3 nitrogen-fixing crops" ;
	float c4per_to_pastr(time, lat, lon) ;
		c4per_to_pastr:standard_name = "transition from C4 perennial crops to managed pasture" ;
	float c4per_to_range(time, lat, lon) ;
		c4per_to_range:standard_name = "transition from C4 perennial crops to rangeland" ;
	float c3nfx_to_secdf(time, lat, lon) ;
		c3nfx_to_secdf:standard_name = "transition from C3 nitrogen-fixing crops to potentially forested secondary land" ;
	float c3nfx_to_secdn(time, lat, lon) ;
		c3nfx_to_secdn:standard_name = "transition from C3 nitrogen-fixing crops to potentially non-forested secondary land" ;
	float c3nfx_to_urban(time, lat, lon) ;
		c3nfx_to_urban:standard_name = "transition from C3 nitrogen-fixing crops to urban land" ;
	float c3nfx_to_c3ann(time, lat, lon) ;
		c3nfx_to_c3ann:standard_name = "transition from C3 nitrogen-fixing crops to C3 annual crops" ;
	float c3nfx_to_c4ann(time, lat, lon) ;
		c3nfx_to_c4ann:standard_name = "transition from C3 nitrogen-fixing crops to C4 annual crops" ;
	float c3nfx_to_c3per(time, lat, lon) ;
		c3nfx_to_c3per:standard_name = "transition from C3 nitrogen-fixing crops to C3 perennial crops" ;
	float c3nfx_to_c4per(time, lat, lon) ;
		c3nfx_to_c4per:standard_name = "transition from C3 nitrogen-fixing crops to C4 perennial crops" ;
	float c3nfx_to_pastr(time, lat, lon) ;
		c3nfx_to_pastr:standard_name = "transition from C3 nitrogen-fixing crops to managed pasture" ;
	float c3nfx_to_range(time, lat, lon) ;
		c3nfx_to_range:standard_name = "transition from C3 nitrogen-fixing crops to rangeland" ;
	float pastr_to_secdf(time, lat, lon) ;
		pastr_to_secdf:standard_name = "transition from managed pasture to potentially forested secondary land" ;
	float pastr_to_secdn(time, lat, lon) ;
		pastr_to_secdn:standard_name = "transition from managed pasture to potentially non-forested secondary land" ;
	float pastr_to_urban(time, lat, lon) ;
		pastr_to_urban:standard_name = "transition from managed pasture to urban land" ;
	float pastr_to_c3ann(time, lat, lon) ;
		pastr_to_c3ann:standard_name = "transition from managed pasture to C3 annual crops" ;
	float pastr_to_c4ann(time, lat, lon) ;
		pastr_to_c4ann:standard_name = "transition from managed pasture to C4 annual crops" ;
	float pastr_to_c3per(time, lat, lon) ;
		pastr_to_c3per:standard_name = "transition from managed pasture to C3 perennial crops" ;
	float pastr_to_c4per(time, lat, lon) ;
		pastr_to_c4per:standard_name = "transition from managed pasture to C4 perennial crops" ;
	float pastr_to_c3nfx(time, lat, lon) ;
		pastr_to_c3nfx:standard_name = "transition from managed pasture to C3 nitrogen-fixing crops" ;
	float pastr_to_range(time, lat, lon) ;
		pastr_to_range:standard_name = "transition from managed pasture to rangeland" ;
	float range_to_secdf(time, lat, lon) ;
		range_to_secdf:standard_name = "transition from rangeland to potentially forested secondary land" ;
	float range_to_secdn(time, lat, lon) ;
		range_to_secdn:standard_name = "transition from rangeland to potentially non-forested secondary land" ;
	float range_to_urban(time, lat, lon) ;
		range_to_urban:standard_name = "transition from rangeland to urban land" ;
	float range_to_c3ann(time, lat, lon) ;
		range_to_c3ann:standard_name = "transition from rangeland to C3 annual crops" ;
	float range_to_c4ann(time, lat, lon) ;
		range_to_c4ann:standard_name = "transition from rangeland to C4 annual crops" ;
	float range_to_c3per(time, lat, lon) ;
		range_to_c3per:standard_name = "transition from rangeland to C3 perennial crops" ;
	float range_to_c4per(time, lat, lon) ;
		range_to_c4per:standard_name = "transition from rangeland to C4 perennial crops" ;
	float range_to_c3nfx(time, lat, lon) ;
		range_to_c3nfx:standard_name = "transition from rangeland to C3 nitrogen-fixing crops" ;
	float range_to_pastr(time, lat, lon) ;
		range_to_pastr:standard_name = "transition from rangeland to managed pasture" ;
	float primf_harv(time, lat, lon) ;
		primf_harv:standard_name = "area_fraction" ;
	float primn_harv(time, lat, lon) ;
		primn_harv:standard_name = "area_fraction" ;
	float secmf_harv(time, lat, lon) ;
		secmf_harv:standard_name = "area_fraction" ;
	float secyf_harv(time, lat, lon) ;
		secyf_harv:standard_name = "area_fraction" ;
	float secnf_harv(time, lat, lon) ;
		secnf_harv:standard_name = "area_fraction" ;
	float primf_bioh(time, lat, lon) ;
		primf_bioh:standard_name = "vegetation_carbon_content" ;
	float primn_bioh(time, lat, lon) ;
		primn_bioh:standard_name = "vegetation_carbon_content" ;
	float secmf_bioh(time, lat, lon) ;
		secmf_bioh:standard_name = "vegetation_carbon_content" ;
	float secyf_bioh(time, lat, lon) ;
		secyf_bioh:standard_name = "vegetation_carbon_content" ;
	float secnf_bioh(time, lat, lon) ;
		secnf_bioh:standard_name = "vegetation_carbon_content" ;```

[ckoven]

Also, we should probably include the info from the LUMIP added-tree-cover file as well, so that we can start thinking about how to handle afforestation in FATES ? Or is that information redundant to the various _to_secdf fields in the transition matrix?

	float added_tree_cover(time, lat, lon) ;
		added_tree_cover:standard_name = "added tree cover that should be planted in each grid cell each year" ;

[lawrencepj1]

Thanks @ckoven

Yes the transitions in and out of each of the LUH2 states could be explicitly captured. The gross changes would have to be maintained as the dataset was regridded to different resolutions by mksrf which may require some assumptions. The number of states in the transition matrix could be rationalized down to just having in and out of crop rather than the c3ann, c3per, c3nfx, c4ann and c4per. The individual crop type information could be captured as the transitions between the crops within the crop land unit if needed. At present we are capturing the added-tree-cover as additional secdf so yes the _to_secdf transitions would cover this.

Peter

[ckoven]

Thanks @lawrencepj1, could you say more what you mean by

The gross changes would have to be maintained as the dataset was regridded to different resolutions by mksrf which may require some assumptions

So does this mean that the information pipeline is that the land use data tool is run once at high resolution and then regridded to the various lower resolutions? How would the transitions regridding logic differ from the state regridding logic?

[lawrencepj1]

Hi @ckoven

Yes I was thinking pretty high level without details but the resolution that we produce the data for and the resolution the model is run at can be different. With simple aggregation you can keep track of biomass or area but transition may not be conservative at different resolutions was all I was trying to point towards.

[ckoven]

@lawrencepj1 I was thinking more about how FATES will actually process this info, and had a few other questions that you would know the answers to:

1. Is the assumption that all primf_harv is directly equivalent to a primary forest -> secondary forest transition rate (i.e. an otherwise missing primf_to_secdf rate, or is there (a) some assumed amount of non-clearcut harvest of primary forest that results in degraded primary forest and/or (b) all of the other primf_to_xxx rates are also included in primf_harv as well, so you have to subtract those out to get a primf_to_secdf rate? If the answer to b is no, then is the carbon lost in those other transitions still also considered harvested or does it go somewhere else?
2. likewise for secmf_harv and secyf_harv: is the carbon that is lost during all the other secdf_to_xxx transitions harvested as well, and if so does that mean it needs to be subtracted from the sum of secmf_harv + secyf_harv or is the total carbon harvested from secondary forests the sum of both the harvest rates and the other transitions away from secondary forests?
3. I notice that there isn't a carbon-based harvest flux reported directly in the LUH2 data. Are the values that CLM has been using equal to the product of, e.g., the area-based primf_harv andprimf_bioh, or is there more to it that that?

Thanks!

[lawrencepj1]

Hi @ckoven

Great questions.

1. Yes in the LUH2 data the primf_harv is the only mechanism for directly transitioning from primf to secdf. There are other pathways that could transition from primf_to_secdn then in a future transition from secdn_to_secdf but those actions would happen on different years and would not involve wood harvest amounts from the bioh fluxes.

For other transitions between PFTs or land units there is an associated fraction of the wood carbon being transferred to product pools as well as litter and coarse woody debris. This is accounted for separately from the explicit wood harvest amounts.

   this%dwt_wood_productc_gain_patch(begp:endp) = spval
   call hist_addfld1d (fname='DWT_WOOD_PRODUCTC_GAIN_PATCH', units='gC/m^2/s', &
        avgflag='A', &
        long_name='patch-level landcover change-driven addition to wood product pools' // &
        '(0 at all times except first timestep of year) ' // &
        '(per-area-gridcell; only makes sense with dov2xy=.false.)', &
        ptr_patch=this%dwt_wood_productc_gain_patch, default='inactive')

With the fraction of the wood conversion to product pools defined at the PFT level (1-pconv) in:

call patch_state_updater%update_patch_state_partition_flux_by_type(bounds, &
     num_soilp_with_inactive, filter_soilp_with_inactive, &
     flux1_fraction_by_pft_type = pftcon%pconv, &
     var = this%deadstemc_patch(begp:endp), &
     flux1_out = conv_cflux(begp:endp), &
     flux2_out = wood_product_cflux(begp:endp), &
     seed = seed_deadstemc_patch(begp:endp), &
     seed_addition = dwt_deadstemc_seed(begp:endp))

Additionally the conversion fluxes include increased fire fluxes in the CTSM fire model which are not included in the DWT fluxes.

For CTSM/ELM/FATES I suggest that we explicitly prescribe the primf_to_secdf along with the carbon amounts extracted through wood harvest. This would be the same for the primn_harv and transitions to primn_to_secdn which would need to be calculated.

2. For the secyf_harv and secmf_harv there is no change in the area of secdf (or secdn) so these are purely extraction of carbon through harvest. This means these values are not added or subtracted from the explicit transitions in and out of the secdf and secdn land units.

3. The primf_bioh is a total amount of carbon removed from the LUH2 gridcell in kgC/year. For CTSM this is converted to gC/m2/yr amount based on the area of tree PFTs in the CTSMlandusedata tool.

Hope that clarifies the process a little.
Peter

[ckoven]

Thanks @lawrencepj1, that is very helpful!

[wwieder]

Also linking this to FATES wood harvest #869

[sshu88]

@wwieder Thank you!

[ckoven]

Hi All, just wanted to give a brief update. @glemieux and I have been working on this and have made a lot of progress. Following the design of the FATES LUH2 design document that several of us discussed a few weeks ago, we are working towards initial versions of all of the steps in various repositories:

• data tools for regridding LUH2 data into new netcdf file: https://github.com/glemieux/fates/tree/tools/fates-luh2_data
• FATES branch to handle land use change: https://github.com/ckoven/fates/tree/luh2
• E3SM branch with logic to read LUH2 data file and pass info to FATES (which should serve as basis for CTSM code as well): https://github.com/glemieux/E3SM/tree/lnd/fates-luh2

Code is not ready yet but most of the pieces are in place to drive patch-level changes to land use types in FATES with the LUH2 data directly.

[ekluzek]

I changed the title and definition of done for this, since the original thought was to read in the original data as a streams file, but now we are reading it from the landuse.timeseries file.

[ckoven]

Hi @ekluzek thanks! Just two slight things:

1. it isn't the harvest data that we are ingesting, it is the full set of LUH2 data (which includes transition matrix, state vector, and management). So suggest changing title to "Read in full LUH2 dataset for use by FATES",
2. at least for now we are not putting this information into the landuse.timeseries file, instead we are making an entirely new FATES-specific file and putting it there.

[ekluzek]

@glemieux does #2076 resolve this one? I think it effectively does...

[glemieux]

@ekluzek yep it meets the definition of completeness noted in the first comment.