How are the offset longitude values handled between JRA55-do and MOM5/MOM6?

I’m starting to look at some output from the regional EAC MOM6 run that I started from 1990-01-01, forced by ACCESS-OM2-01. This has run for 5 years, and before I continue this on any further, I just wanted to make sure it’s being forced by the correct surface forcing. My concerns are around the different longitude coordinate values that are used by the ocean and atmosphere, i.e.,

  • The ocean uses the -280 to +80 degrees longitude; So the EAC region lies somewhere around -218 degrees east.
  • The JRA atmosphere uses the 0 to 360 degrees longitude; So the EAC region lies somewhere around 140 degrees east.

Not only are the actual values different, but the “seams” are different as well - ocean seam in Indian Ocean, atmosphere seam in Atlantic Ocean.

My question is how does the regional MOM6 know what longitudinal range to pull out of the global JRA55 datasets when they have completely different longitude ranges? Was this something dealt with by YATM in ACCESS-OM2? These lines from the mom6.out file give some hints as to what happens, but I’ve looked at those methods in the FMS scripts and can’t see how it would deal with the mismatch. It looks to use the gridspec.nc file.

 atmos model domain decomposition
whalo =    1, ehalo =    1, shalo =    1, nhalo =    1
  X-AXIS =   14  14  14  14  14  14  14  14  14  14  14  14  14  14  14  14  14  14  14  14  14  13  13  13
             13  13  13  13  13  13  13  13  13  13  13  13  13  13  13  13  13  13  13  13  13  13  13  13
  Y-AXIS =   10  10  10  10  10  10  10  10  10  10  10  10  10  10  10  10  10  10  10  10  10  10  10  10
              9   9   9   9   9   9   9   9   9   9   9   9   9   9   9   9   9   9   9   9   9   9   9   9
              9   9   9   9   9   9   9  10  10  10  10  10  10  10  10  10  10  10  10  10  10  10  10  10
             10  10  10  10  10  10  10
NOTE from PE     0: grid2_mod/get_grid_cell_vertices domain is not present, global data will be read
NOTE from PE     0: grid2_mod/get_grid_cell_centers domain is not present, global data will be read

Below I’ve plotted the SST for the first day of the mom6-eac run, compared to the same snapshot from the ACCESS-OM2-01 run. I’ve taken the difference between these, expecting things to be almost identical for the first day of the run (considering it was initialised with the 3D fields from the ACCESS-OM2-01 model). There’s some strange “synoptic” scale patterns that I suspect are imprints from the mismatched atmospheric forcing but keen to get others thoughts on this?


Thanks!

2 Likes

Not sure about the seam-related questions you posted above. Perhaps others have something to say?

But let me comment a bit on the comparison plot you show. So this is a snapshot after you run the MOM6 regional model for 1 day?
How does it look before you even run (e.g. compare the initial condition, is it spot on 1e-16 difference)?

Given that the initial condition is exactly the same then would you expect the flow to be the same 1 day later? I wouldn’t necessarily expect that. There are differences in the staggered grid first of all…

The two models you are comparing above also have different resolutions (if I presume the 003 is the resolution of the regional model, e.g., 1/30th degree?). So what do you actually plot in the last difference plot? Do you interpolate the 003 SST onto the ACCESS-OM2-01 grid? What sort of interpolation you do? Different choices might matter here…

Thanks for the comments Navid!

My thoughts are that the surface should not have diverged too much (note this is the average SST over the first day). That coherent diagonal blue band in the right-hand figure looks very atmospheric to me.

Yep, I regridded the 30th degree to the 10th degree grid. I’ll check the initial conditions and get back to you on that. Just tried running it with files that only had the regional area, (subsetted all jra files to the regional domain) but received warning/error combo’s like the following:

WARNING from PE    40: MOM_diabatic_driver.F90, applyBoundaryFluxesInOut(): Mass created. x,y,dh=      -2.194E+02     -3.900E+01            NaN

MOM_forcing_type, forcing_SinglePointPrint: Called from applyBoundaryFluxesInOut (grounding)
MOM_forcing_type, forcing_SinglePointPrint: lon,lat =      -2.194E+02     -3.900E+01
MOM_forcing_type, forcing_SinglePointPrint: ustar =             NaN
MOM_forcing_type, forcing_SinglePointPrint: buoy is not associated.
MOM_forcing_type, forcing_SinglePointPrint: sw =       8.029E+02
MOM_forcing_type, forcing_SinglePointPrint: sw_vis_dir =       2.288E+02
MOM_forcing_type, forcing_SinglePointPrint: sw_vis_dif =       2.288E+02
MOM_forcing_type, forcing_SinglePointPrint: sw_nir_dir =       1.726E+02
MOM_forcing_type, forcing_SinglePointPrint: sw_nir_dif =       1.726E+02
MOM_forcing_type, forcing_SinglePointPrint: lw =      -9.515E+01
...
FATAL from PE     2: NaN in input field of reproducing_EFP_sum(_2d).

I’ve just now shifted the longitude values in all jra files (lon = lon-360) and it’s running so I’ll take a look at the output of the first day tomorrow and hopefully have some answers!

Note: I don’t understand the error you printed out… (I don’t understand where it’s coming from nor what did you do to get it.)

But regardless of that, I second your concern about the blue stripe.

I guess, to phrase the question in different words, you are asking whether it matters that the seam in the forcing is at -80 or 0 or anywhere, right? I don’t know because I don’t know the inner-workings of MOM6. Somebody might have a solid answer; hint hint @angus-g.

Could you save the surface stress as a diagnostic? If I remember correctly you can do that in MOM6. What I’d do in your shoes is to just run for 1hr and output the surface stress. Then shift the forcing seam by e.g. 20 degrees and run again, then shift by another 20 degrees and run again. If MOM6 actually reads the lon, lat values from the forcing input you should get the same exact output (this is the sane outcome in which case where the seam is in your forcing is irrelevant). If you get different outcomes it hints that it matters for MOM6 how your forcing coords are, in which case you might have to think harder to find the right way to have your input coords.

1 Like

So I’ve got some answers after doing what you suggested @navidcy. (sorry for posting this on the weekend, I don’t expect anyone to respond anytime soon!). So, I ran 4 different test experiments for only one hour, saving zonal and meridional wind stress from the model diagnostics. The first three experiments have a 10 degree longitude shift in the JRA forcing (0 shift, 10 shift, 20 shift). The zonal (\tau_x) and meridional (\tau_y) wind stress for the first hour are shown in the first three columns of the figure. This was a good sanity check, as shifting the JRA forcing has definitely imprinted on the surface wind stress in the model output - see the outline of NZ shift towards Tassie for example. Then I decided to shift the JRA forcing 280 degrees - ignore this test (I realised this doesn’t make sense as it is just shifting the longitude values, not the physical “seam” so the result was atmospheric forcing from over some open ocean region).

The last column shows the raw JRA zonal (top) and meridional (bottom) velocities. These clearly match the wind stress patterns from the first column (0 shift), hence I can conclude that as @angus-g already mentioned, MOM6 can handle the mismatch internally. This doesn’t entirely answer the question around the figure from my first post though regarding the difference in SST between the global and regional models. Why is there this almost instantaneous difference (from model initialisation) between the global and regional SST (>1degC), that aligns with this band of intense south-eastward wind stress? Maybe I’m overthinking it, and should compare transports and other metrics once the model has spun-up but I just don’t want to run 30 years for it to be wrong :sweat_smile:

First of all, as a general point: most probably at some point in your life you will run 30 years of simulation that will be wrong – it’s OK. Delete and rerun.

But your concerns are valid. I don’t think you are overthinking it.

So just to clarify, your regional model is forced with the ACCESS-OM2 on the boundaries and with the the JRA reanalysis at the surface, right?

I don’t understand what you were shifting in the different experiments. Were you shifting:

(a) the actual longitude values of the forcing (e.g. you made a pattern the corresponded to 100E then correspond to 110E) or

(b) were you changing where the seam was in the forcing?

I was suggesting you did (b)… but whatever you did is informative! But we need to know before we interpret and conclude. For example, if you were doing the latter then how did you conclude that MOM6 matches the mismatch internally?

1 Like

Another question (in an attempt to rectify the SST difference and blue pattern at the top). The forcing provides U_air, V_air and then either models compute the stresses.

  1. Do the ACCESS-OM2 (i.e., MOM5) and MOM6 models compute the stresses the same way?
  2. Do MOM5 and MOM6 assume that the forcing is given on the A-grid or MOM5’s B-grid or MOM6’s C-grid? (Still this blue pattern looks much bigger than 0.1degree wide so I doubt that can explain it… but it may explain it partly?)

Is it possible that the difference is just due to the model physics differences between MOM6 and ACCESS-OM2? e.g. different surface mixing schemes affecting SST quite rapidly?

1 Like

Now that I know the model is being forced by the correct atmospheric forcing, I’m thinking that it’s most likely due to the different vertical coordinates plus the different model physics as you’ve both suggested. The regional model has 100 layers, with a pretty high density of layers near the surface compared to the global model with 75 layers, and consequently, coarser resolution at the surface. I’ve plotted the same figure as in my first post, but for the nearest depth layer to 5m. The diagonal blue bias seen at the surface has almost disappeared.

Whereas at the nearest layer to 1m shown below, even though the global model layer is shallower, it might be possible that the surface mixing can transmit that atmospheric signal faster through the multiple, thinner layers of the regional model (but this is a wild guess as I haven’t spent much time understanding the model physics yet).

And, as a final sanity check, plotting the snapshot of JRA winds, with the surface wind stress from ACCESS-OM2-01 and the regional model output from the first day of the run confirms that everything matches up.

I’ll continue running the model out and start some evaluation this week, more confident things are set up correctly. Thanks for the help and suggestions!

1 Like

This has been a really interesting read @john_reilly! A very thorough investigation, thanks.

It provides a really useful template for diagnosing the effects of forcing on models in general, and some interesting insights into the effects of nesting a a model within another model that may differ in physics as well as resolution.

(I added a few more tags to help people discover this in the future)

1 Like