search

NGEET / fates

repository for the Functionally Assembled Terrestrial Ecosystem Simulator (FATES)
Other
93 stars 90 forks source link

wind effect and bareground #1201

Open rgknox opened 2 months ago

rgknox commented 2 months ago

I'm doing an audit on how we filter out patches with the classification nocomp_bareground from loops. I was curious about the intent of this piece of code:

https://github.com/NGEET/fates/blob/sci.1.76.3_api.35.1.0/fire/SFMainMod.F90#L140-L144

It looks like the intent is to get the patch-level index from an hlm bc input structure (bc_in%wind24_pa(iofp)) that is not associated with a fates bareground patch. Why are we doing this though? Isn't the wind-speed populated in that patch's index?

glemieux commented 2 months ago

This was a hack to deal with the fact that we are providing a patchno of zero for bareground patches with fbg+nocomp, but not providing a specific allocation for these bc_in variables for that run mode since at the time of the update (PR #976) there wasn't interest in running spitfire on these bareground patches: https://github.com/NGEET/fates/blob/f0185f7c7033fa69c80d1ddb07cbcbf1f8be1adc/main/FatesInterfaceMod.F90#L496-L500

So we needed to add a way to make sure that when we do run in fbg+nocomp with spitfire on we skip over the oldest patch (i.e. bareground patch) and start with using the next youngest patch (which sets iofp to the patchno of one). The reason for updating the patchno logic itself to include fbg+nocomp and not just during sp mode came out of issue #973, which the above PR also addresses.

~That said, we should be able to strike out all occurances of this usage with integration of PR #1116.~ UPDATE: I originally misspoke here; we will still be carrying around bareground patches for landuse.