Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not using mesh areas #240

Open
anton-seaice opened this issue Nov 1, 2024 · 12 comments
Open

Not using mesh areas #240

anton-seaice opened this issue Nov 1, 2024 · 12 comments
Assignees

Comments

@anton-seaice
Copy link
Contributor

In our ESMF mesh files for the mediator, we include a grid cell area field (elementArea) calculated from the MOM6 supergrid.

We are not using this area, and instead NUOPC is calculating the grid cell areas internally. (see ESMF_MeshCreate in the model caps cice6 mom6 cdeps where it would need an additional argument addUserArea)

The caps compare the model areas and the mediator areas and creates the mod2med and med2mod variables to correct the areas for fluxes (per CMEPS docs)

The internally calculated areas are not bad, for example the ocn.log file shows this:

(MOM_cap:InitializeRealize) :  min_mod2med_areacor, max_mod2med_areacor   0.979070197811820       1.06555533734542    MOM6
(MOM_cap:InitializeRealize) :  min_med2mod_areacor, max_med2mod_areacor   0.938477772999814       1.02137722324197    MOM6

The areas which are different are those along the midline of x (which is landmasked) and the areas adjacent close to the true poles (probably related to how the areas are calculated e.g. the rotate-poly option in FreNCTools)

Screenshot 2024-11-01 at 12 53 33 PM

It's not clear that we need to do anything - although when calculating global mediator fluxes, we do need to be aware that the areas are different. (ping @kieranricardo @MartinDix)

@anton-seaice
Copy link
Contributor Author

Its possible this impacts the run-off conserving issues #231 also

@anton-seaice anton-seaice self-assigned this Nov 1, 2024
@ofa001
Copy link

ofa001 commented Nov 1, 2024

Hi @anton-seaice, Not clear of full implications of this for the coupling fluxes, but there is clearly an anomaly in the Arctic at i=180, also at i=80 and i=260 which are from across the Tripole, do you know the causes. I guess closest to the tripole the gridboxes would be smallest would this effect the different measurements the internal and mediator area calculations have given?

@anton-seaice
Copy link
Contributor Author

anton-seaice commented Nov 1, 2024

Not clear of full implications of this for the coupling fluxes,

I believe its minimal. Each component cap has a correction between the component and the mediator area.

but there is clearly an anomaly in the Arctic at i=180, also at i=80 and i=260 which are from across the Tripole, do you know the causes.

Im not too concerned about at i=180 - this is all land masked. It might be something about these cells have two identical corner points as its one of the tripoles.

The other two locations are the real geographic poles, and my guess is its related to ESMF using a different method to calculate areas at these points compared to the method used in our current (i.e. the om2) grid. We are moving to using --rotate-poly for the new grid and this might be the difference.

I guess closest to the tripole the gridboxes would be smallest would this effect the different measurements the internal and mediator area calculations have given?

Possibly/probably yes

@anton-seaice
Copy link
Contributor Author

The main issue here is the diagnostic outputs are confusing ...

An area correction is applied for fluxes in the model caps, but not for quantities.

e.g.

For a quantity, the value by cell is the same in the mediator and the model output. e.g. Sea ice concentration has an exact match:

Screenshot 2024-11-04 at 4 07 23 PM

If you wanted to calculate a global sea ice area - strictly, it would be different from the mediator and the model output, because they use different grid areas.

However for a flux, a correction is applied for areas, and so the values by cell are different between the mediator and model output. e.g. snowfall:

Screenshot 2024-11-04 at 4 09 35 PM

Kieran and Martin also found this for the MOM evap flux when comparing mediator & model fields.

@anton-seaice
Copy link
Contributor Author

@MartinDix may be correct about the Radius of the earth being inconsistent:

We seem to be using the MOM6 default, e.g:

call get_param(param_file, mdl, "RAD_EARTH", G%Rad_Earth_L, & "The radius of the Earth.", units="m", default=6.378e6, scale=US%m_to_L)

https://github.com/mom-ocean/MOM6/blob/05d8cc395c1c3c04dd04885bf8dd6df50a86b862/src/initialization/MOM_grid_initialize.F90#L402-L403

But CICE6 & Mediator use the radius from CESM share:

real(R8),parameter :: SHR_CONST_REARTH = 6.37122e6_R8 ! radius of earth ~ m

https://github.com/ESCOMP/CESM_share/blob/3dd7edb12d3fc109914f922f3131711cf0d7fbd4/src/shr_const_mod.F90#L20

I can test tomorrow to see if that is impacting the MOM to mediator area corrections

@anton-seaice
Copy link
Contributor Author

anton-seaice commented Nov 7, 2024

Comparison of rain flux from the mediator and mom, shows rain flux is slightly smaller in MOM:

Screenshot 2024-11-07 at 2 29 18 PM

And setting

RAD_EARTH = 6.37122E6 in MOM_input shows only differences around the tripole:

Screenshot 2024-11-07 at 2 31 34 PM

Again : this is accounted for in the coupling by the med2mod term, however it is also confusing

@MartinDix
Copy link

MOM's 6.378e6 is the equatorial radius which seems an odd choice to me.

The UM uses 6.371229e6, so slightly larger than CICE & CESM. https://en.wikipedia.org/wiki/Earth_radius suggests this is the average distance from the center to the surface.

@anton-seaice
Copy link
Contributor Author

Should we use the UM radius in all components then ?

@MartinDix
Copy link

The relative difference between 6.371229e6 and 6.37122e6 is 1e-6 which is small enough that I don't think it matters. I think MOM and CICE should match though.

@ofa001
Copy link

ofa001 commented Nov 11, 2024

Yes MOM looks like the one furthest out.

@aekiss
Copy link
Contributor

aekiss commented Nov 11, 2024

Good catch - sounds like Earth's radius is another thing to add to our list of inter-model parameter consistency checks. It would be nice to automate this, e.g. via payu - see #109 - but are these set at compile time in CICE6 and mediator?

@aekiss
Copy link
Contributor

aekiss commented Nov 11, 2024

@MartinDix 1e-6 is indeed a small factor, but if we're adjusting these, why not make them exactly identical? It may save some head-scratching down the road.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants