Skip to content

Commit

Permalink
Allow FATES-SPITFIRE to read lightning data from file
Browse files Browse the repository at this point in the history 
I replicated code used in CLM's BGC to read Fang Li's or FMEC's
lightning data for use in Fang Li's fire model.

I also turned on fates_seed_suppl in fates_params_default.cdl.
Initially I turned this on as a test because the model was crashing as a
result of the first way that I chose to pass the lightning data to
SPITFIRE. Turning on fates_seed_suppl didn't help, but I left it on
anyway.
  • Loading branch information
@slevis-lmwg
slevis-lmwg committed Aug 5, 2019
1 parent 0b13454 commit c1903de
Show file tree
Hide file tree
Showing 3 changed files with 371 additions and 9 deletions.
Loading

6 comments on commit c1903de

@slevis-lmwg
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is my first commit with code changes related to NGEET/fates#562

Keep in mind that I had to also make changes on the CLM side of the code for things to work.

@slevis-lmwg
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pinging @rgknox @jkshuman @lmkueppers @pollybuotte
to make sure that you also have the link to my first commit.

@rgknox
Copy link
Contributor

@rgknox rgknox commented on c1903de Aug 14, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@slevisconsulting , thanks for the update. It looks like the objective is to use the lightning strike dataset, used in this line:

c1903de#diff-c9ea8667acccc19523f68989530ca2a4R1124

It looks like you are trying out two ways of creating that array. I see some modifications to the spitfire code with some code that does reading and buffer updates , and then I see some code that suggests the lightning strike data is part of the "bc_in%" structure. Ultimately, if these changes are to be integrated into our master branch, we will have to go with the second approach, thereby reading the dataset in on the CLM side of the code, and passing the arrays to FATES via the "bc_in%" structure, somewhere in this module:

https://github.com/ESCOMP/ctsm/blob/master/src/utils/clmfates_interfaceMod.F90

Is that lightning dataset already read-in by CLM?

@slevis-lmwg
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the CLM reads the same dataset for its fire model. First I tried but then gave up untangling the CLM code that reads the lightning data. It's embedded within the biogeochemistry code, and I found myself spending time and not making progress disentangling it from that code. So instead I repeated that code in SFMainMod.F90. I am in favor of cleaning all this up, but Lara will have to approve how I use my time since I'm paid by the hour.

@jkshuman
Copy link
Contributor

@jkshuman jkshuman commented on c1903de Aug 19, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@slevisconsulting so then you are reading lightning data with the code in within Spitfire? Can you explain more about why it needs to be disentangled from CLM? Why we can't use the existing structure...
@rgknox is the rationale that the HLM reads in data associated with site level details? FATES does not read in any data (pardon my naive question)?
At least we know this implementation works, and we can read the data.

@slevis-lmwg
Copy link
Owner Author

@slevis-lmwg slevis-lmwg commented on c1903de Aug 20, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jkshuman , yes, the lightning data is currently read with code that I copied from the CLM to SPITFIRE. The alternative would have been to use the CLM code in its original location without copying to SPITFIRE. To do that I would have had to enable that code to run for FATES, which requires disentangling from CLM's requirements determining when that section of code is allowed to run. Since you're asking, I'm taking a look again to remind myself what I found:

It all starts in clm_initializeMod.F90 with:
if (use_cn) then
call bgc_vegetation_inst%Init2(bounds_proc, NLFilename)
Init2 then calls
call CNDriverInit(bounds, NLFilename, this%cnfire_method)
which calls
call SoilBiogeochemCompetitionInit(bounds)
call CNPhenologyInit(bounds)
call cnfire_method%CNFireInit(bounds, NLFilename)
CNFireInit then says
if ( this%need_lightning_and_popdens ) then
and we're there.

Since CN and FATES are mutually exclusive, I tried in clm_initializeMod.F90 - a few lines down where use_fates is true - to directly
call cnfire_method%CNFireInit(bounds, NLFilename)
but all my attempts failed. I kept bumping up against requirements/variables/derived types and who knows what else that CN codes expect that FATES codes don't and vice versa.

One thing I did not try that just occurred to me is repeating the same call to Init2 - again, in clm_initializeMod.F90 a few lines down where use_fates is true. Then I would have needed if (.not. use_fates) around the first and second calls listed above in CNDriverInit. I expect that other contradictory CN vs. FATES requirements/etc would still need resolving, but maybe this would have eventually worked.

Lara and I are operating on a tight time-budget so, when I started feeling over my head in conflicting CN vs. FATES requirements, I prioritized getting this done over getting it done elegantly :-)

Please sign in to comment.