IJ indices for stretched grid and bubble up error from MAPL_getHorzIJindex subroutine

[weiyuan-jiang]

Types of change(s)

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Trivial change (affects only documentation or cleanup)

Checklist

• Tested this change with a run of GEOSgcm
• Ran the Unit Tests (make tests)

Description

Stop the program when the grid is not a normal CS grid but computes the IJindex. It partially addresses issue #2850 . Eventually, I think the Grid class should have information about stretch and the ij index is computed according to the info the grid provides

Related Issue

[mathomp4]

The main problem is, if we commit this, then we can't run the stretched grid with GOCART, right? And, well, I'm not sure if that's desired.

We might need to support some sort of "slower"/"dumber" IJ method if running stretched grid.

[mathomp4]

I've drafted this PR until @tclune can have a think on it as well.

[github-actions]

This PR has been automatically marked as stale because it has not had activity in the last 60 days. If there are no updates within 7 days, it will be closed. You can add the ":hourglass: Long Term" label to prevent the stale action from closing this issue.

[mathomp4]

I can confirm this definitely works! I ran a stretched case and failed as expected.

[mathomp4]

Hmm. GNU is not happy:

/root/project/GEOSgcm/src/Shared/@MAPL/base/Base/Base_Base_implementation.F90:3458:33:

 3458 |        latRe = half_pi*sign(1.0, Zz)
      |                                 1
Error: 'b' argument of 'sign' intrinsic at (1) must be the same type and kind as 'a'
make[2]: *** [src/Shared/@MAPL/base/CMakeFiles/MAPL.base.dir/build.make:1094: src/Shared/@MAPL/base/CMakeFiles/MAPL.base.dir/Base/Base_Base_implementation.F90.o] Error 1

[weiyuan-jiang]

The function for reverse Schmidt transform is added and the indices can be calculated now. But I have not run the gcm with stretched grid. How can I do the setup and run? @mathomp4

[mathomp4]

The function for reverse Schmidt transform is added and the indices can be calculated now. But I have not run the gcm with stretched grid. How can I do the setup and run? @mathomp4

@weiyuan-jiang My makeoneday script should work for c270 or c540. Just choose Ostia-CS ocean as well.

[mathomp4]

I just tried a C270 run and:

 accurate_lon:    5.32325421858271
 accurate_lat:  -0.483265549030082
 edge_lat    :   0.350599277377354
 edge point  :           30
 Error: It could be
   1)Grid is NOT gnomonic_ed;
   2)lats lons from MAPL_GridGetCorners are NOT accurate (single precision from
 ESMF)

and I also saw:

 Error: Grid should have pi/18 shift

[tclune]

Oh yes. The pi/18 shift does not happen for the stretched grid. ...

[weiyuan-jiang]

This PR also addresses issue #3060

[mathomp4]

@weiyuan-jiang I just tried building this and running it at C270 and I get:

 NOT using buffer I/O for file: tavg3d_aer_p.rcx
 NOT using buffer I/O for file: HISTORY.rc

 Freq: 00060000  Dur: 00060000  TM:   -1  Collection: geosgcm_prog
forrtl: severe (41): insufficient virtual memory
Image              PC                Routine            Line        Source
libMAPL.pfio.so    000014C936ACD0B9  pfio_variablemod_         139  Variable.F90
libMAPL.base.so    000014C9382C148C  mapl_latlongridfa        1821  MAPL_LatLonGridFactory.F90
libMAPL.griddedio  000014C938AFDFC7  mapl_griddediomod         170  GriddedIO.F90
libMAPL.history.s  000014C93A1533B0  mapl_historygridc        2470  MAPL_HistoryGridComp.F90

and it's dying in parse_dimensions() in Variable. I'll try a debug run to see if maybe my optimized build is doing weird things.

[mathomp4]

Update: maybe this is on me. My Debug build worked. I'm going to nuke my release build and build from scratch.

[mathomp4]

Okay. It was me. I can run C270 now without errors, etc.

[mathomp4]

Oh. I guess I should test with v11. I just did it with v12.

Also, ping @mmanyin that the stretch grid might be okay again...

[tclune]

If it works, it works.

[mathomp4]

For posterity, I ran GEOS at C270 before and after this fix. This is the output of SO2EMVN before the fix:

and then after the fix: