RE: Converting GOFS 3.1 meanstd .ab files to netCDF
Jon Cusick
How can I request a subregion from the 3z program?
I’ve been trying to map u and v components from the netCDF (obtained from the original .ab file) into lonlat in order to do further analysis. When using the hycom_lonlat2xy tool to get an appropriate bound of x and y values that I can subset with, the resulting array of x values returns the expected 0.08 degrees longitude for each cell.
However, when taking the same approach with y values (in the range of 0-46 degrees north), I come up with each y cell in the array measuring ~0.07… degrees instead of the expected 0.08. When then trying to plot this subset along with known land boundaries, etc, the HYCOM data appears warped.
Stepping back, it seems that I might be better served by trying to subset each archive file during the 3z conversion to netCDF. That way, each file would have a 1-d lat and lon and I could directly index those attributes for further analysis instead of trying to work backwards using x and y indices.
I took a look at archv2data3z.f and it didn’t look like there was a way to request a subset as part of that. I took a look also at the scripts in the subregion directory, though it looked like I’d need to provide a custom grid for some of them and I’m not sure how to make that.
What do you think the best process is to convert the .ab files into netCDF where they are indexable directly by lat lon? In my case, the area of interest would be in the rectilinear grid (specifically 0 – 46 degrees north). Any guidance or documentation from a similar example would be much appreciated.
Thanks,
Jon
From: Alan Wallcraft <alan.wa...@hycom.org>
Sent: Thursday, July 3, 2025 06:00
To: HYCOM.org Forum <fo...@hycom.org>
Cc: Jon Cusick <JCu...@aphysci.com>; Alan Wallcraft <alan.wa...@hycom.org>
Subject: Re: Converting GOFS 3.1 meanstd .ab files to netCDF
A uniform lon,lat grid (like GLBy0.08) has zero gird size at the North pole and so can't be used as the native grid for an ocean model.
GOFS and ESPC-D use a "tripole" or "tripolar" grid that has two "north" poles that have been shifted over land.
The figure is showing the model array as a rectangle. It is rectilinear south of 47N (parallel lat and lon lines), but curvilenear (2d lat lon) north of 47N. The grid spacing goes to zero at the top corners and top center but this if over land and so does not matter to the running model.
If you only care about points below 47N, I think you will get 1-d lon lat axes in the netCDF file if you output a subregion south of 47N from the 3z program.
Alan.
On Wednesday, July 2, 2025 at 1:59:51 PM UTC-4 Jon Cusick wrote:
Gotcha, thanks. When running hycom_NaN, I get the same results as you do for 930_archMN.2022_12.a which is good.
It turns out that I was incorrectly indexing the generated netCDF files in post-processing on my end.
The “Latitude” and “Longitude” values in the netCDF files seem to be 2-d arrays, each indexed by both X and Y (which I still don’t fully understand – I would have expected each one to be a 1-d array).
I found some XY and ij to lonlat conversion scripts in same bin/ directory as the hycom_NaN too and those were very helpful. Using those to work backwards and then interact with the netCDF XY values instead of lat/lon enabled me to get things looking good on my end.
I appreciate the quick responses the last few days, thanks Alan!
From: Alan Wallcraft <alan.wa...@hycom.org>
Sent: Monday, June 30, 2025 15:25
To: HYCOM.org Forum <fo...@hycom.org>
Cc: Jon Cusick <JCu...@aphysci.com>; Alan Wallcraft <alan.wa...@hycom.org>
Subject: Re: Converting GOFS 3.1 meanstd .ab files to netCDF
The archive depth mismatch range message is normal and millimeters is OK.
The NaN checker is hycom_NaN
There are no NaN's in the archive file:
narwhal07 204> hycom_NaN 930_archMN.2022_12.a 4500 3298
306 FIELDS PROCESSED, 0 CONTAINED NaNs and/or Infs
What i,j locations are exhibiting this? You can use hycom_profile to see what the archive file has at such a location. At a shallow location there will only be five non-zero layers:
narwhal07 209> hycom_profile 930_archMN.2022_12.a 3010 24
## expt idm jdm kdm iloc jloc lonloc latloc yrflag
## 930 4500 3298 41 3010 24 314.9 -77.9 3
## model-day srfhgt surflx dpbl dpmixl tmix smix thmix umix vmix ubavg vbavg steric nsterc oneta E-P
# 44530.0000 -177.25 -16.9 1.010 1.206 -1.8184 34.2002 36.9702 0.98 0.44 0.10 -0.20 -144.20 -33.05 1.0000 0.000
## model-day covice thkice temice
# 44530.0000 94.75 0.47 -4.19
# k utot vtot p.temp saln p.dens thkns dpth
1 0.98 0.44 -1.8184 34.2002 36.9702 1.000 0.500
2 0.43 0.24 -1.7016 34.2769 37.0205 1.000 1.500
3 -0.19 -0.42 -1.6565 34.3186 37.0495 1.000 2.500
4 -0.41 -0.86 -1.6290 34.3463 37.0689 1.000 3.500
5 -0.42 -0.86 -1.6286 34.3461 37.0687 1.000 4.500
6 -0.42 -0.86 -1.6286 34.3461 37.0687 0.000 5.000
7 -0.42 -0.86 -1.6286 34.3461 37.0687 0.000 5.000
The utot and vtot columns are usually interpolated to the p-grid, which is what the 3z program does as well.
I think the "3z" version would have data void for levels below 5 m.
Alan.
On Monday, June 30, 2025 at 2:22:22 PM UTC-4 Jon Cusick wrote:
Thanks Alan, I seemed to have just grabbed the wrong topo files by mistake. Using the correct GLBb0.08 files seemed to do the trick. There was a message about archive depth mismatch range, but it was on the order of millimeters, so I don’t expect it to be a major deal.
When reading in a few of the converted netCDF files, it seemed like ~55% of the u component values were filled in with NaNs (at least for 930_archMN.2022_11.a and 930_archMN.2022_12.a so far).
I saw a few older threads on the forum mention a “hycom_NAN” tool [0, 1]. I wanted to try and run that to determine if the issue is in the original data, with the archv2ncdf3z tool, or in the way I’m reading in the resulting netCDF data, but wasn’t sure where/what that NAN tool is.
Where can I find the hycom_NAN tool and do you have any advice about how to go about tracking the issue down?
Thanks,
Jon
[0] https://groups.google.com/a/hycom.org/g/forum/c/JOySdRDmGN0
[1] https://groups.google.com/a/hycom.org/g/forum/c/a3aEmRjN_GY/m/9mYOjs2uBQAJ
From: Alan Wallcraft <alan.wa...@hycom.org>
Sent: Friday, June 27, 2025 17:15
To: HYCOM.org Forum <fo...@hycom.org>
Cc: Jon Cusick <JCu...@aphysci.com>
Subject: Re: Converting GOFS 3.1 meanstd .ab files to netCDF
The native 1/12 degree global grid is GLBb0.08, so use the regional grid and depth from https://data.hycom.org/datasets/GLBb0.08/expt_93.0/topo/
This has:
4500 'idm ' = longitudinal array size
3298 'jdm ' = latitudinal array size
Alan.
On Friday, June 27, 2025 at 4:06:20 PM UTC-4 Jon Cusick wrote:
Hello,
I’m trying to convert the monthly mean u and v components for the GOFS 3.1 .ab HYCOM files [1] into netCDF, using the archv2ncdf3z utility. However, I’m running into indexing errors with idm and jdm, and I’m not sure how to resolve them.
I call the utility as follows, with the file regional.grid.b downloaded from [2] and placed in the current directory. See attached for the input file passed to the utility and the output returned.
$ ./archv2ncdf3z < archv2ncdf3z.in
I’m set idm and jdm to 4500 and 4263, respectively, in the input file based on the contents of regional.grid.b, though something seems to be misaligned with those parameters.
My two asks are:
- Can you provide input on how to resolve the idm, jdm sizing issues seen in the .out file?
- Can you provide guidance on how to use this same utility to subset the resulting netCDF file to a given lat/lon bounding box? Is the workflow to update {i, j}orign and {i, j}dmp in the .in file, where I divide the total idm and jdm by the min/max lat/lon listed in regional.grid.b to get the index offsets?
Thanks,
Jon
[1] https://data.hycom.org/datasets/GLBb0.08/expt_93.0/data/meanstd/
[2] https://data.hycom.org/datasets/GLBy0.08/expt_93.0/topo/
Alan Wallcraft
#
# --- GoM
# --- hycom_lonlat2ij -98 18
# --- 2349 1734
# --- hycom_lonlat2ij -77 32
# --- 2611 1928
#
# --- output is netCDF output.
1734 'jorign' = j-origin of plotted subregion
263 'idmp ' = i-extent of plotted subregion (<=idm; 0 implies idm)
195 'jdmp ' = j-extent of plotted subregion (<=jdm; 0 implies jdm)
netcdf \930_archMN.2022_12_3z {
dimensions:
MT = UNLIMITED ; // (1 currently)
Latitude = 195 ;
Longitude = 263 ;
Depth = 40 ;
variables:
float Latitude(Latitude) ;
Latitude:standard_name = "latitude" ;
Latitude:units = "degrees_north" ;
Latitude:axis = "Y" ;
float Longitude(Longitude) ;
Longitude:standard_name = "longitude" ;
Longitude:units = "degrees_east" ;
Longitude:point_spacing = "even" ;
Longitude:axis = "X" ;
Jon Cusick
Ahh, I hadn’t realized that the subregion arguments could be passed directly into the archv2ncdf3z tool.
When making use of those arguments, and ensuring that the requested area is below 47N, the resulting netCDF files indeed have 1d axes for both latitude and longitude.
I really appreciate the help Alan, thank you!
