Use explicit regrid method in HISTORY

[mathomp4]

This PR updates HISTORY.AGCM.rc.tmpl to use the new regrid_method option for MAPL History. This essentially adds:

collection.regrid_method: 'BILINEAR',

for most collections as the default regridding method for History is bilinear. For conservatively regridded collections we go from:

conscoll.conservative: 1,

to:

conscoll.regrid_method: 'CONSERVE'

In a way this is not exactly "important" and it is zero-diff. But I at least think it is good to have the regridding method explicit for each collection.

Still, I'll keep this draft until @sdrabenh can weigh in. And maybe @bena-nasa can add his opinion.

[mathomp4]

Note: perhaps @wmputman or @sdrabenh would prefer some/all of the collections here to be BILINEAR_MONOTONIC and/or CONSERVE_MONOTONIC similar to efforts being explored by @rtodling in GEOS-IT work?

If so, this would go from zero-diff to non-zero-diff, so might be best done in two PRs? 🤷🏼 (@bena-nasa can explain more if there are questions in re MONOTONIC regridding.)

[sdrabenh]

Note: perhaps @wmputman or @sdrabenh would prefer some/all of the collections here to be BILINEAR_MONOTONIC and/or CONSERVE_MONOTONIC similar to efforts being explored by @rtodling in GEOS-IT work?

If so, this would go from zero-diff to non-zero-diff, so might be best done in two PRs? 🤷🏼 (@bena-nasa can explain more if there are questions in re MONOTONIC regridding.)

Yes, @bena-nasa what is the monotonic constraint and why is it being used for GEOSIT?

[bena-nasa]

Note: perhaps @wmputman or @sdrabenh would prefer some/all of the collections here to be BILINEAR_MONOTONIC and/or CONSERVE_MONOTONIC similar to efforts being explored by @rtodling in GEOS-IT work?
If so, this would go from zero-diff to non-zero-diff, so might be best done in two PRs? 🤷🏼 (@bena-nasa can explain more if there are questions in re MONOTONIC regridding.)

Yes, @bena-nasa what is the monotonic constraint and why is it being used for GEOSIT?

@sdrabenh They are using out of an over abundance (in my opinion) of caution. This option forces the the calculation of a destination point to go through a custom dynamic mask that as it is summing the product of the source points * weights for the destination keeps track of the minimum and maximum source points for each destination point. After the destination value is computed, it checks, is the destination greater or less than the maximum source values. If so it sets the destination point to that value. This was implemented because of numerical issues with the esmf regridding layer, it was found that all source points were identical, (like say you have a value that represents a fraction and all the source points are one) it is possible due to the vagaries of floating point math, the fact that our fields are single precision, but the weights they store are double that maybe the destination is not quite 1 but a very small amount like a few machine epsilons greater than 1. Now they were putting this through QUADS which apparently has no tolerance when checking values so even though the values were 1 for all practical purposes QUADS flagged them as out of bounds.

So this just prevents that from happening.