create flux correction factor in component caps

[mvertens]

Most component caps have meshes read in and independently the component itself will generate its internal grid. In cpl7, area correction factors were applied in the coupler to account for differences between areas obtained from the mapping files and areas that the component itself were using. A similar correction factor needs to be implemented in the component caps for fluxes. This can simply be done by extracting the areas from the mesh file and creating a scaling factor from that.

[billsacks]

#137 seems to be a duplicate of this. I am closing #137 and copying the comments from #137 below:

Based on discussions with @mvertens , CMEPS is not yet doing area correction for conservative mapping - i.e., correcting for differences between a component's internal areas and the areas computed by ESMF when generating mapping weights. According to @oehmke in a discussion this morning, area correction could be applied automatically by ESMF by specifying the add_user_areas argument when creating the mesh. (Then we wouldn't need to do a manual area correction like we do in CPL7.)

Things get messy for glc <-> lnd mapping, though (which is what I've been discussing with @mvertens ): For the glc -> lnd mapping, we map some states conservatively, and do not want to apply area correction to those; in fact, I believe that it's important that we not apply the area correction to the ice fraction (and I think we don't want to do so for the topographic height either). However, we still want fluxes from glc to use the area correction.

Similar complications may exist for the mapping of component fractions – for example, ocean fraction mapped to the atmosphere grid. My intuition is that we do not want to apply an area correction to these.

So to handle this all correctly, we may need to specify which fields do (not) get the area correction – either by applying this area correction only to fluxes (as is done for mct) or using some other, more field-by-field approach.

I'm not positive, but I think it's also important that area correction only be applied to fields that are expressed per-unit-area (as is typically the case for fluxes). I don't think you want to do area correction on a state like temperature, even if you're mapping it conservatively, because it could lead to an increase or decrease in temperature in the receiving component relative to the sending component. (In contrast, doing the area correction on fluxes just adjusts for the fact that "per-m^2" means something different in the two places.)

[mvertens]

@billsacks - CMEPS is definitely doing area correction for conservative mapping and this has been carefully validated across the system. I'm not sure what to say about the glc->lnd mapping. I thought we had discussed this a while ago and decided that we were handling this in CMEPS correctly.

[billsacks]

Checking some components, it looks to me like this might have been partially implemented. I see area correction factors applied in some places in CAM's atm_import_export, but I don't see anything like that in CTSM's lnd_import_export or CISM's glc_import_export. I'm wondering if some other changes are still needed here.

[mvertens]

@billsacks - there is no flux correction for clm since the mesh and the internal grid are the same for nuopc. In mct you were obtaining the grid from the domain file - here you are obtaining it from the mesh.

…

On Wed, Nov 3, 2021 at 10:38 PM Bill Sacks ***@***.***> wrote: Checking some components, it looks to me like this might have been partially implemented. I see area correction factors applied in some places in CAM's atm_import_export, but I don't see anything like that in CTSM's lnd_import_export or CISM's glc_import_export. I'm wondering if some other changes are still needed here. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#84 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB4XCE3J4EMUWVS3SNGCFDTUKIL6HANCNFSM4POHVLRQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

-- Dr. Mariana Vertenstein CESM Software Engineering Group Head National Center for Atmospheric Research Boulder, Colorado Office 303-497-1349 Email: ***@***.***

[billsacks]

From talking with @mvertens it sounds like the only remaining need is for CISM. So I'm going to close this issue and open an issue in the CISM-wrapper repository.