glemieux / e3sm Goto Github PK

Mode tests:

• lightning_from_data mode
• scalar_lightning mode
• no_fire mode

The following modes are not going to be tested at this time as these are cases specific to clm-fates users. They may be implemented in the future.

• successful_ignitions mode
• anthro_ignitions mode
• anthro_suppression modw

Note that the anthro_suppression test is a simple connectivity test, in which the relevant code must be uncommented to pass gdp data to fates. IIRC I think I need a simple test branch version of fates with the gdp added to the history output interface module.

Project Board: https://github.com/users/glemieux/projects/8/views/1

This project will attempt to run fates with different modes depending on the gridcell location. The initial use case is to allow fates to run in its fully dynamic mode in a specific region (lat/lon defined) while running in reduced complexity satellite phenology mode everywhere else on the globe. This is being developed to help enable global calibration. This takes inspiration from E3SM Atmospheric Regional Refined Mesh capability.

• #12
• #13

During testing of the exact restarts for the seed dispersal code, it was noted that fates should be updated to incorporate the most recent ERS fixes in NGEET/fates#914 and NGEET/fates@9d9c192. This is most directly accomplished by updating elm-fates api to 24.1 given that all these fixes are incorporated up to https://github.com/NGEET/fates/releases/tag/sci.1.59.7_api.24.1.0.

PR location: E3SM-Project#5043

The configuration files need to be changed from what Shijie originally specified for his test cases. This includes reverting the .gitignore change as well:

• Revert configuration changes

Ryan noted that we should ask someone if its ok to add the HRV_DEADSTEMC_TO_PROD... that Shijie added to a set of testmods. It should be noted that these variable predated this pr, but were not in the history output generally. They have also been added to the fates only history output, so this may conflict with that test run. Perhaps we can add a fates-specific test including these variables?

• Ask someone in e3sm about the v1bgc testmod changes and change as necessary.

The default harvest was set as the area fraction originally. Should this be reverted?

• Ask someone about the default harvest option and change as necessary.

The regular seed dispersal update code in elm_drv should be neatly wrapped up into fates code.

• move mpi call into a new elmfates_interface procedure
• refactor bc_in and bc_out assignment wrap_seed_... calls into elmfates_interfaceMod, instead of elm_driver
• create "dispersal" type to replace the elm_driver seed_ local variable
• glemieux/fates#23
• move allocation of seed distribution arrays out of elm_driver into an initialization routine
  - [ ] Add global variable to set the distribution frequency (check against is_beg_curr_...)
• Add fates-side mode selection variable/logic to turn dispersal on or off

Data sources needed: TBD

Currently the default is designated here:

• Review e-folding distance definition
• Review HLM code base for existing great circle distance calculation

Attempt to utilize MPI collective operations and virtual topology to simplify and improve neighborhood communication.

Check confluence to see if there are references available there. Also see: https://gmd.copernicus.org/articles/12/2679/2019/#section4

Subtasks:

• Adapt base type for fates fire data types and method
• Add elmfates_interface initialization code
• refactor existing elm code to make sure cnfire and spitfire are separate
• Incorporate need_lightning_and_popdens
• Pass gdp_lf_col, forc_lnfm, and forc_hdm into fates fire types
• Move need lightnting set function into fates fire base type
  - Add surfacedataread procedure

Branch: lobata_configuration
Issue on fates repo: NGEET/fates#881 (comment)

From email discussion with @ckoven:

I actually think the simplest and most robust solution is to have two new namelist arguments as part of the LUH+nocomp HLM-side developments:

— filename_pft_fraction_by_landuse_dataset, acceptable values are blank or a full file path
— use_fates_potential_vegetation, acceptable values are true or false

with the following logic:

— if filename_pft_fraction_by_landuse_dataset is not blank, then the file is read, parsed, the interface variables are allocated, and all of the data is passed to FATES via the interface. There is no check on whether or not either use_fates_potential_vegetation or use_fates_luh are also true, the dataset will be read and passed no matter what, so long as a filename is given.

Further explanation:

Yes, for now at least, if ‘filename_pft_fraction_by_landuse_dataset' is blank, the existing nocomp PFT data from the surfdata file would be used, so no action need be taken at this point other than to not pass that data if ‘filename_pft_fraction_by_landuse_dataset’ is a valid file.

From ckoven/fates#15 (comment)

Per @ckoven, use the dynHarvestMod.F90 as a guideline for this module.

Tasks

• Initialization subroutine
• Interpolation subroutine
• Module integration into ELM and FATES API
• LUH2 file io
• Test passing information from ELM to FATES
• #23

Currently the seed dispersal code recomputes the nearest neighbor locations every timestep in clm_drv which is inefficient. Setup a mechanism to record this as global or gridcell type vector to be calculated during initialization.

Project board: https://github.com/users/glemieux/projects/9/views/1

This is the super-task for the above project to be included in the project prioritization board: https://github.com/users/glemieux/projects/7/views/1

This is a little complicated by the fact that do_harvest is set in the build namelist code prior to setting any fates namelist variables.

@glemieux no these should both be allowed already. The future goal will be to remove the current reading of the logging rates from the surface dataset entirely and replace them with the same information that is now on the luh2 file.

Originally posted by @ckoven in #21 (comment)

This is for post-V0 luh2 development.

This update will read in data from the file created via glemieux/fates#30 during initialization and pass that infomation to FATES.

Tasklist

• Update dynFATESLandUse code with initialization read of pft x landuse data
• Update elmfates_interfacemod to pass data to fates
• #25

Ryan noted that we do not have the Init2 routine and call in elmfates_interfaceMod.F90: https://github.com/ESCOMP/CTSM/blob/master/src/main/clm_initializeMod.F90#L457-L459

The elm code is setup to recognize the various spitfire mode options and pass them to fates, but we don't have any tests exercising this in e3sm or actual api code to appropriately initialize and read data for these modes.

• Get Charlie and Jennifer's feedback on prioritization
• Double check ctsm test statuses
• #8
• Determine the development timeline for the spitfire updates

What it says in the title. Preview this with relevant elm (and clm-side) people.

• Rough draft
• Feedback from elm-side
• Feedback from clm-side

The current fates landuse code assumes that the user has correctly assigned the landuse data files to be read in that match the grid cell resolution. There is no check to make sure that this is the case. For a similar check, see the following in surfrd_get_data. There may be an existing callable procedure to handle this, so I should check for this before wrapping up the linked code into a new procedure.

• Check if there is an existing function to conduct this check

In a future update, being able to call the fates landuse data tool(s) on the fly during the mksurfdata_map call would avoid this issue.

• Review clm and elm fire model code for comparison of approaches
• Adapt clm design doc to write up design plan
• Preview with Peter Schwarz and Gautam

Currently, we are testing for mass conservation, by plotting the amount of seeds out against the expected amount of seeds in. This is easy enough to visualize as a check for two gridcells, but with a full global run we need a better unit test for this. This will be complicated in the future by the fact that we will want to "lose" mass to non-vegetated land units and will need to keep track of an error term.

I think we need a "seed dispersal mode" option for the namelist so that we can avoid passing information to fates if necessary. Review what data needs there are. On reflection, with the use of #9 this might not be necessary and we could just use a parameter file flag.