wind effect and bareground

[rgknox]

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]

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:

fates/main/FatesInterfaceMod.F90

Lines 496 to 500 in f0185f7

	allocate(bc_in%lightning24(maxpatch_total))
	allocate(bc_in%pop_density(maxpatch_total))
	allocate(bc_in%wind24_pa(maxpatch_total))
	allocate(bc_in%relhumid24_pa(maxpatch_total))
	allocate(bc_in%precip24_pa(maxpatch_total))

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.