Accessing MPAS Files from THREDDS Data Services (not a valid CDM file) and "64-bit offset" vs "64-bit data" netcdf files

billcapehart

New member
[I'll be CCing this to the UNIDATA/THREDDS people as well]

I am starting the migration from WRF to MPAS and am seeing issues serving some of my output through our THREDDS service.

As an example, I have a link to the tutorial example x1.10242.init.nc file where we create the static land-cover input files with init_atmosphere.
Our catalog service link is here:

https://thredds.ias.sdsmt.edu:8443/....html?dataset=CLASS_Examples/x1.10242.init.nc

The OPeNDAP link fails with the following error:

Code:
Error {
    code = 500;
    message = "java.io.IOException: Cant read /ias_raid/data/DATASETS/local_academic_repo/CLASS_Examples/x1.10242.init.nc: not a valid CDM file.";
};

While it reads just fine with xarray and ncdump locally, and the HTTPServer link will download the file, it can still be read easily with the command line and Python resources.

I examined the type of the file x1.10242.init.nc is with "ncdump -k" it is reporting it as a "64-bit data" and when with ncmpidump it reports as "cd5."

However, when I did the same with the x1.10242.grid.nc grid file that is input into init_atmosphere, both ncdump and ncmpidump, it reports as "64-bit offset." The *grid.nc" files can be read easily with OPeNDAP.

Has this problem been encountered before? Also, while using nccopy to convert the unoffset "64-bit data" files to "64-bit offset" seems to create a working solution and is readable with OPeNDAP, will this impact MPAS and related tools' ability to use these "repaired" netcdf files later in the workflow?

Cheers and Thanks
Bill Capehart
 
Back
Top