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

Integer indexing for sub-regions in diag_table #1209

Closed
kshedstrom opened this issue May 1, 2023 · 7 comments
Closed

Integer indexing for sub-regions in diag_table #1209

kshedstrom opened this issue May 1, 2023 · 7 comments
Labels
enhancement Issue/PR for a modification that increases performance, improves syntax, or adds functionality.

Comments

@kshedstrom
Copy link

I swear I ran my regional Arctic domain with a bunch of cross sections saved, using the i,j indices of the cross sections. It no longer works, giving me the error:
FATAL from PE 0: diag_util_mod::get_index: array NOT monotonously ordered

I get this error with the lat/lon locations as well, since the lat/lon values are indeed not monotonously ordered.

Would it be possible to get the i,j indices working again, for instance like:

"ocean_model_z", "volcello", "volcello", "ocean_Bering_Strait", "all", "mean", "321 330 184 184 -1 -1",2

@kshedstrom kshedstrom added the enhancement Issue/PR for a modification that increases performance, improves syntax, or adds functionality. label May 1, 2023
@thomas-robinson
Copy link
Member

The current diag manager does not support the use of indices for a subregion. It only supports the use of lat/lon. The new diag manager being developed will support the use of indices. If this entry worked in your diag table, I am not sure how.

If you have a problem with a lat/lon subregion, then we will be more concerned with that. What does the diag table entry look like for that?

@kshedstrom
Copy link
Author

The lat/lon examples look much the same:
"ocean_model_z", "volcello", "volcello", "ocean_Bering_Strait", "all", "mean", "176.75 178.1056 67.9 67.9 -1 -1",2

They fail the same way since my domain covers the north pole and latitude is not monotonic across the domain, plus of course longitude wraps around at +/-180.

@nikizadehgfdl
Copy link
Contributor

@kshedstrom Would you be able to provide us with a workdir on gaea to reproduce the error?
I think we need to have your grid to investigate this issue as it appears specific to the ocean_hgrid.nc

FYI , for a small global test case of MOM6-SIS2, when I use the 360 complements of the lons you used in diag_table the test runs:

"ocean_model_z", "thetao","thetao",  "ocean_Bering_Strait",    "all", "mean", "-183.25 -181.8944  67.9 67.9  -1 -1",2

but when I change it to your choice of longitudes I get an error

"ocean_model_z", "thetao","thetao",  "ocean_Bering_Strait",    "all", "mean", "176.75 178.1056  67.9 67.9 -1 -1",2

I get

FATAL from PE    26: diag_util_mod::get_subfield_size: can not find gstart_indx/gend_indx for thetao, check region bounds for axis  1

It could be that FMS diag_manager is looking for bounding longitudes commensurate with the ocean_hgrid bounds (-280 to 80 in this test case).

FYI, in the OM4p125 diag_table for sections Bering Strait bounds appear as:

"ocean_model_z", "volcello", "volcello", "ocean_Bering_Strait",    "all", "mean", "-171.4 -168.7  66.1 66.1 -1 -1",2

@kshedstrom
Copy link
Author

Sure, my most recent run is in /lustre/f2/scratch/gfdl/Katherine.Hedstrom/work/fre/run23

@nikizadehgfdl
Copy link
Contributor

I cannot access the ocean_hgrid.nc and probably the rest of the INPUT files to run your test:

 ncdump: /lustre/f2/scratch/gfdl/Katherine.Hedstrom/work/fre/Arctic_12k/INPUT/ocean_hgrid.nc: Permission denied

@kshedstrom
Copy link
Author

Sorry, did I just fix it for you?

@uramirez8707
Copy link
Contributor

Fixed in #1505
Integer indexing for sub-regions is now available in the diag_table.yaml
https://github.com/NOAA-GFDL/FMS/blob/main/diag_manager/diag_yaml_format.md#26-sub_region-section

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Issue/PR for a modification that increases performance, improves syntax, or adds functionality.
Projects
None yet
Development

No branches or pull requests

4 participants