Refactor spitfire fuel calculations #1247
Conversation
|
Okay so I've tracked down this error. And it seems to originate from a negative value in the sum of fine leaf litter. (leaf_fines -2.3394756489679232E-006) This exists in I am going to file an issue. |
We can ignore this per #1249. |
adrifoster
changed the title
|
Okay I think I have fixed all the overflow and divide-by-zero issues. I am re-running testing but I think this is now ready for a review. |
|
fates test suite tests are in /glade/derecho/scratch/afoster/tests_0924-151742de all tests PASS or FAIL due to a BASELINE DIFF, as expected will run through and make sure all DIFF's are round off |
|
All DIFFs are due to roundoff - this is ready for a review. |
|
|
||
| integer function dead_leaves(this) | ||
| class(fuel_classes_type), intent(in) :: this | ||
| dead_leaves = this%dead_leaves_i |
There was a problem hiding this comment.
@adrifoster , I'm curious, why do we have a function call to report an integer constant? I've seen this type of thing before, but wasn't sure why it was done. It always seemed straightforward to just reference the integer constant directly in the code where its used.
There was a problem hiding this comment.
it's just a getter function. This is a (Fortran-limited) way of carrying the fuel class indices around in a class (rather than having to read each of them in), but still protecting their values.
You unfortunately can't have a protected class variable, only private - which means you have to use a method to get the value.
The setter/getter pattern is fairly common in object-oriented programming. It's a little clunky in Fortran, unfortunately. I was trying it out here but can go back to what we had before if people don't like it. I just found it a lot nicer to just use the fuel_classes class rather than each parameter
There was a problem hiding this comment.
The other option would be to just have a module with just the fuel classes as constants/parameters in it and allow the use of the whole module, which is effectively the same idea, but goes against our convention of having the use, : only, and obfuscates the origin of each of the constants.
There was a problem hiding this comment.
I am continually frustrated that Fortran doesn't have an enumerator type....
There was a problem hiding this comment.
I think since they are constants, they can be defined as "integer, parameter :: ", which makes them immutable. I have no problem with getters/setters though. It adds one small extra step when someone who is reading the code is tracking what the value, but that's trivial.
There was a problem hiding this comment.
@rgknox you unfortunately can't have a "parameter" attribute for a class variable. it's really frustrating...
There was a problem hiding this comment.
whoa, I can't believe I never ran into that. weird
|
@rgknox asked for some functional testing plots: Plot of Nesterov Index over time using driver data from an interior Alaska site
Corresponding fuel moisture for above NI values, for 3 different synthetic fuel models (see module
Fuel loading for fuel types:
Fractional loading
Fuel bulk density
Fuel SAV
|
| ! There are six fuel classes: | ||
| ! 1) twigs, 2) small branches, 3) large branches 4) trunks | ||
| ! 5) dead leaves, 6) live grass | ||
| integer, private :: twigs_i = 1 ! array index for twigs pool |
There was a problem hiding this comment.
I like the verbose convention of implying the index with the trailing i
| this%total_loading = 0.0_r8 | ||
| do i = 1, nfsc | ||
| if (i /= fuel_classes%trunks()) then | ||
| this%total_loading = this%total_loading + this%loading(i) |
There was a problem hiding this comment.
Should this be called "non_trunk_loading" or "non_trunk_total_loading" ?
There was a problem hiding this comment.
good idea - it is a bit confusing. I can do that.
|
One general comment. This is something that was already in the code that kind of bothered me. We all know we break up litter into component groups for both decomposition and fire. Both modules use almost the same groups, which are governed by size and location (above and below ground). In general, I'd like this to be a little cleaner, where the super-set of all delineations is contained in a process agnostic module, and decomposition and fire could inherit those delineations and group/use them how they see fit. I don't see this as in-scope for this PR necessarily, but I'm curious how you see all this, and if its still a problem. |
There was a problem hiding this comment.
Definite improvement, @adrifoster has already addressed my comments. Thanks!
Totally agree. I wanted to try to merge them somehow but they are slightly different in terms of how they are grouped and used, so I wasn't sure how to do it efficiently for this PR. I think it warrants a small group of us sitting down to discuss. If we merged them it would also make further discretizing the litter/fuel easier (i.e. PFT-specific, etc.). I also don't love that the litter is decayed in one spot, the fuel is combusted in another, etc. And seemingly we do (?) make sure these things align? |
Refactors the SPITFIRE fuel calculation subroutine and adds a fuel class
Description:
Major changes to the way fuel characteristics are calculated in the SPITFIRE module. Changes are not B4B, but should be round off.
Expectation of Answer Changes:
Round off differences due to order of operation changes. Testing in progress...
Checklist
Contributor
Integrator
Test Results:
Testing ongoing... currently having issues with some divide by zero errors (in rate_of_spread) for only some tests... I'm not sure why this is happening since the code should check and not let SAV, bulk density, etc. equal zero.
/glade/derecho/scratch/afoster/tests_0912-094039de
CTSM (or) E3SM (specify which) test hash-tag:
CTSM (or) E3SM (specify which) baseline hash-tag:
FATES baseline hash-tag:
Test Output: