Switching to Symmetric MOM6

[helenmacdonald]

Regional MOM6 needs to run on a symmetrical executable whilst access-om3 is running on a non-symmetrical executable. Switching access-om3 to symmetrical will reduce the number of executables that need to be supported.

The difference between symmetric and non-symmetric mom6 is that there is some overlap of grid cells on adjacent tiles. This uses a very small amount of extra memory but may make some gradient calculations easier. The central version of MOM6 runs tests to ensure that switching between symmetrical on non-symmetrical does not change the model solution but we may need to test on the access-om3 models to ensure that this is still the case with our parameterisations.

The suggestion is that we should compare a test case of access-om3 run in symmetrical and non-symmetrical mode to check that there are no issues before switching over

[access-hive-bot]

This issue has been mentioned on ACCESS Hive Community Forum. There might be relevant details there:

https://forum.access-hive.org.au/t/cosima-twg-meeting-minutes-2025/4067/2

[anton-seaice]

I built with mom_symmetric and the normal repro test passes. .

In my view that is enough to make the change ?

[chrisb13]

Agreed and good timing!

[anton-seaice]

Yay - it only impacts the deployment, so ill put the change in deployment repo (probably ACCESS-NRI/ACCESS-OM3#33)

[chrisb13]

Yeah, makes sense. I just noticed that it's already there, though isn't it? Here, specifically.

[anton-seaice]

Yes - I was predicting the future there ;-)

[anton-seaice]

This has been implemented in ACCESS-NRI/ACCESS-OM3@6ef4337

[anton-seaice]

The original test of this didn't actually demonstrate reproducibility due to ACCESS-NRI/model-config-tests#100. Just that the model ran.

Now that the repro test has been fixed, I've rerun the test with the 0.4.0 build and it failed. See ACCESS-NRI/access-om3-configs#187 (comment). Ill dig further.

i.e. as mom symmetric is now the default, the test is for historical repro with the mom not-symmetric build.

[dougiesquire]

Yeah, I think changing to/from symmetric changes answers

[anton-seaice]

Ah Angus thought the opposite - have your tried with MOM standalone ?

[dougiesquire]

I thought I did - let me check

[angus-g]

Ah Angus thought the opposite - have your tried with MOM standalone ?

That's right, there's test.grid in the MOM6 regression suite that compares symmetric and asymmetric. It's only disabled for the cases including OBCs that can't run with asymmetric.

[dougiesquire]

Hmmm... that doesn't seem to be the case for ACCESS-OM3: ACCESS-NRI/access-om3-configs#173 (comment)

[anton-seaice]

I ran the latest 1deg iaf config with latest build except without mom_symmettric for one day, and looked at the restart files created after one day.

Looking at random vector field (u), and the difference between symmettric and non-symmettric are not zero:

With symmettric, there are also differences between the mediator u values and the mom u values. (The mom restart x dimension for u is one larger than the mediator, and the mom u values are on vertical cell edges compared the mediator values on the centre points. So i linearly average adjacents edges to get the centre points for comparison)

The differences in the tripole are expected, as the mediator and mom use different reference direction for angles. The differences in vertical lines (presumably at block boundaries) are interesting. Redoing this plot with non symmetric outputs shows all zero differences south of 65N

Anyway, maybe the second issue is unrelated to the first.

[anton-seaice]

Calculating the difference between coupler and mom v shows the striping as well - mostly zeros except for some horiztonal stripes

Possibly that is expected ...

the surface state exported from nuopc does not have any halo fields. The coupler fields are on the centre points and mom uses the right hand and top edge points for vectors. So how does MOM know what the vector term are for the right hand edges and top edges on each block? Turning on mom_symmetric means it also needs left and bottom edges for each block? Which are presumably found through interpolation and may mean results may be different

[anton-seaice]

I guess ill try running without coupling to see if that confirms my hypothesis its coupling related