fv3 needs to export the 1-ice fraction that it used in calculating fluxes for export to the coupled model

[DeniseWorthen]

Description

FV3 needs to export the open-water fraction to CMEPS so that CMEPS can properly normalize the fluxes imported from FV3 which are sent to other components (ocean,ice).

Solution

A new export variable can be added in setup_exportdata

[junwang-noaa]

Denise, do you have a standard field name for this open water fraction field? I will use "open_water_faction" for now. I think the same name needs to be used in nems field dictionary and CMEPS.

[DeniseWorthen]

Yes, it will need to be the same. My working branch is here. I've called it openwater_frac_in_atm. This will be aliased in CMEPS to the name "Sa_ofrac".

This branch also contains a minor bugfix for when dumpfields=true.

[junwang-noaa]

Your code changes look good. So in the coupled mode, since fv3 sends the available fields to mediator before model start integration, the open water frac in this case is from atmos ICs, it may not be consistent with the ice fraction from the ice model, will it cause some issue in mediator?

…

On Thu, Jan 21, 2021 at 3:52 PM Denise Worthen ***@***.***> wrote: Yes, it will need to be the same. My working branch is here <https://github.com/DeniseWorthen/fv3atm/tree/feature/sa_ofrac>. I've called it openwater_frac_in_atm. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#230 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AI7D6TJZY5X3RELRA5LXFV3S3CHYJANCNFSM4WBAY37A> .

[DeniseWorthen]

Thats a good point but I haven't seen any differences in the exchanged fields until after a few timesteps. The field that FV3 is sending back is meant to be identical to the field it received. Implementing it this way is much simpler than having CMEPS keep two time-levels.

[SMoorthi-emc]

Why do you need this? Open_water=(1-ice_frac)*ocean_frac. Moorthi

…

Sent from my iPhone

On Jan 21, 2021, at 3:45 PM, Jun Wang ***@***.***> wrote: Denise, do you have a standard field name for this open water fraction field? I will use "open_water_faction" for now. I think the same name needs to be used in nems field dictionary and CMEPS. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[DeniseWorthen]

because cmeps needs the open water fraction to re-normalize and it no longer has that value available since it would need to be the previous timestep.

[junwang-noaa]

@DeniseWorthen Is there any update on committing the code changes?

[DeniseWorthen]

I was going to update the ufs-weather issue #366 today. Yesterday we got Bob Oehmke from ESMF involved in the ancillary issue which arose as part of adding this feature to try to determine if that ancillary issue is an ESMF or CMEPS bug.

I've tested the export field I've created for the open water fraction and it is nearly identical to the imported open water fraction from at the previous timestep. This is the expected behaviour.

As long as this field is not connected, I believe the change could be added to FV3 at any time with no impact on baselines. The FV3 branch I am using for adding this feature is here.