Configuring chgres to Work With Older NCEP FNL Analyses about ufs_utils HOT 17 OPEN

I don't have read permissions for your files here: /work2/noaa/aoml-hafs1/ahazelto/hafs-input/GFS_FNL/gfs.20080910/00/atmos/

from ufs_utils.

I have updated the permissions - it should be readable now.

from ufs_utils.

I see what is happening. Doing a dump of fnl_20080910_00_00.grib2, I see what looks like soil temperature in records 235-238:

235:9633444:d=2008091000:TMP Temperature [K]:0-0.1 m below ground:anl:
236:9658101:d=2008091000:TMP Temperature [K]:0.1-0.4 m below ground:anl:
237:9682412:d=2008091000:TMP Temperature [K]:0.4-1 m below ground:anl:
238:9706791:d=2008091000:TMP Temperature [K]:1-2 m below ground:anl:

If I check these records for the GRIB2 discipline, I see '0'- meteorological products:

235:9633444:code table 0.0=0 Meteorological Products
236:9658101:code table 0.0=0 Meteorological Products
237:9682412:code table 0.0=0 Meteorological Products
238:9706791:code table 0.0=0 Meteorological Products

chgres_cube assumes soil temperature is disciple '2' - land products:

https://www.nco.ncep.noaa.gov/pmb/docs/grib2/grib2_doc/grib2_table4-1.shtml#2

So, to get chgres_cube past this step, some code mods will be required. There may be other issues that will require additional work.

from ufs_utils.

I see - is there a way to get chgres_cube to use those even though they are meteorological data?

from ufs_utils.

I see - is there a way to get chgres_cube to use those even though they are meteorological data?

Not without some code modifications. Are you using the head of develop?

from ufs_utils.

Yeah it's the support/HAFS branch, which I believe was branched off of develop:
commit e6eec36 (HEAD, origin/support/HAFS, origin/HEAD, support/HAFS)

from ufs_utils.

Yeah it's the support/HAFS branch, which I believe was branched off of develop: commit e6eec36 (HEAD, origin/support/HAFS, origin/HEAD, support/HAFS)

The code mods to get past the error should be minimal. But there could be other issues with this old data. I can try to run the case myself. Don't get rid of the input data or the fort.41 namelist. Make sure I have read permissions on the data.

from ufs_utils.

from ufs_utils.

I have updated the permissions - it should be readable now.

I can't get to your working directory. Can you leave the fort.41 file somewhere for me and make sure I can read all the files it points to? Thanks.

from ufs_utils.

I changed the working directory to be readable - it's here: /work2/noaa/aoml-hafs1/ahazelto/hafstmp2024/HAFS_tutorial_test0_oldgfs/2008091000/09L/atm_ic/.

Let me know if you still can't access it.

from ufs_utils.

I changed the working directory to be readable - it's here: /work2/noaa/aoml-hafs1/ahazelto/hafstmp2024/HAFS_tutorial_test0_oldgfs/2008091000/09L/atm_ic/.

Let me know if you still can't access it.

Got stopped at this point: drwxr-s--- 12 ahazelto aoml-hafs1 4096 May 29 15:55 hafstmp2024

from ufs_utils.

OK looks better now?

drwxr-sr-- 12 ahazelto aoml-hafs1 4096 May 29 15:55 hafstmp2024/

from ufs_utils.

OK looks better now?

drwxr-sr-- 12 ahazelto aoml-hafs1 4096 May 29 15:55 hafstmp2024/

Try chmod 755.

from ufs_utils.

I did a chmod -R 755 on /work2/noaa/aoml-hafs1/ahazelto/hafstmp2024/HAFS_tutorial_test0_oldgfs/. Does that work?

from ufs_utils.

I did a chmod -R 755 on /work2/noaa/aoml-hafs1/ahazelto/hafstmp2024/HAFS_tutorial_test0_oldgfs/. Does that work?

Yes. I am able to reproduce the error. Don't remove any of your files.

My test data and script is here: /work2/noaa/da/ggayno/save/chgres.old.grib2

from ufs_utils.

Hi George, just wanted to follow up on this and see if you had any further insights or suggestions? Thanks!

from ufs_utils.

Hi George, just wanted to follow up on this and see if you had any further insights or suggestions? Thanks!

I documented what is happening here: #954 (comment)

Code changes will be required to work with this data. I can assist if you want to try updating the code yourself.

from ufs_utils.