Possible changes for having create_crop_landunit always true

[billsacks]

Bill Sacks < [email protected] > - 2016-12-05 15:07:27 -0700
Bugzilla Id: 2385
Bugzilla CC: [email protected], [email protected],

Here are some notes from March 28, 2013, about what I thought would need to change once we were ready to set create_crop_landunit to true always. I'm not sure how much here is still correct, relevant, or necessary. I can dig up my other notes that are referenced here if they would be helpful:

Once dynamic landunits are in place, we can always use create_crop_landunit=true. So far this hasn't been possible, because we need to maintain create_crop_landunit=false when doing transient landcover change (because otherwise changing crop area would imply changing landunit areas, which so far hasn't been allowed).

Here are some things that will need to be done to accomplish this:

• In mkpftMod: mkpftInit: Change setting of num_natpft & num_cft in the case numpft == numstdpft

  • we will now ALWAYS have num_natpft = numstdpft - numstdcft, and num_cft = numpft - num_natpft.
  • so we can get rid of the conditional that sets num_natpft and num_cft
  • see May 14, 2013 notes in Changing weights specification in surface dataset for diffs needed for this (mkpftMod.F90 changes under "Making surface datasets for running with my new code")

  I'm not sure if we're still allowing the use of raw datasets with just the 16 standard PFTs. I know we're allowing that for the transient pft dataset, but I'm not sure about the static-in-time dataset. But it might be irrelevant... with the above change, we might be handling things the same in the code regardless of the number of PFTs on the dataset, at least with respect to the static-in-time datasets (see below for notes on the transient dataset)

• Need PCT_CROP to be time-varying on the pftdyn dataset.

  When transient pft info comes from a file with just the 17 pfts (as it currently does), this would be interpreted as: PFTs 0-14 treated as before. Assuming that PFT problem with the bounds of some history fields #16 is always 0%, then PCT_CFT can stay fixed in time (for surface datasets with generic crop: always 100% PFT duplicate definitions of a few functions in CanopyFluxesMod.F90 #15; for surface datasets with specific crops: whatever is determined from the raw data file); PFT duplicate definitions of a few functions in CanopyFluxesMod.F90 #15 will determine PCT_CROP through time.

  To summarize: We'll have the following on the pftdyn dataset:

  • PCT_NATVEG: no time dimension (essentially ignored for transient runs -- that's the whole point of my refactoring)
  • PCT_CROP: varies in time
  • PCT_PFT: varies in time
  • PCT_CFT: no time dimension, at least for now

• Making sure transient pfts are handled right with respect to crops

  • Make sure that the new formulation creates transient datasets correctly.
    • In particular: it sounds like the transient raw dataset format won't change. So, I think we can interpret the % crop in the transient raw dataset to be the crop landunit area -- and then have the individual crop areas (as % of landunit) stay fixed (see also Surface dataset meeting 6-15-12)

  NOTE: there may be conflicts between this bullet and notes in the previous bullet... need to figure out how exactly we should handle transient pfts now:

  • can we have the case where the static dataset has 24 pfts but transient has 16?
  • If so, confirm how this should be handled

[billsacks]

I'm closing this old issue: I think much of this has been done, some I don't understand any more, and the first bullet ("In mkpftMod: mkpftInit"), while perhaps not done yet, doesn't seem that important (it's just a minor code cleanup that we can do whenever we're finally able to remove create_crop_landunit=.false. for good).