Two input files for RRTMG are incompatible with GCHP
Closed this issue · 4 comments
Name and Institution (Required)
Name: Sebastian Eastham
Institution: Massachusetts Institute of Technology
Confirm you have reviewed the following documentation
Description of your issue or question
Two of the current input files used when running with RRTMG enabled are incompatible with GCHP. Specifically, the files:
- ExtData/HEMCO/RRTMG/v2018-11/species_clim_profiles.2x25.nc
- ExtData/HEMCO/RRTMG/v2018-11/modis_surf_albedo.2x25.nc
In both files, the format of the units string for the time variable is rejected by the NetCDF metadata interpreter in MAPL, resulting in an error being thrown. This is essentially because the time format is given as hours since 1985-1-1 00:00:0.0, and MAPL expects hours since 1985-01-01 00:00:00. The use of a decimal in the seconds term in particular causes an issue. The specific error thrown is:
Error termination. Backtrace: At line 377 of file /home/seastham/Simulations/C2023-10-21_RRTMGSA/Code.GCHP/src/MAPL/base/FileMetadataUtilities.F90 Fortran runtime error: Bad integer for item 1 in list input
This error can be easily fixed by replacing the units attribute with hours since 1985-01-01 00:00:00. I have tested this on our Hex cluster and found that this resolves the error.
A quick update: I have discovered that this file also causes GCHP to fail when encountering a leap year. This may be because the file has samples once every eight days, which ExtData does not know how to handle. This failure can be quickly reproduced by running a simulation which starts on 2020-02-29. The problem can be easily fixed by replacing "2002" with %y4 in the time template for two files (modis_surf_albedo.2x25.nc and modis_emissivity.2x25.nc). The automated date extrapolation means that this should have no effect on outputs while allowing the run to proceed.
I have generated fixed versions of the modis_surf_albedo... and species_clim... files in https://www.dropbox.com/sh/ofh34b0j37cq4o6/AAA6XlnJ1n5kW-PepSf8EXnea?dl=0. Replacing the existing files with these copies and replacing the time template in ExtData.rc (see comment above) seems to fix these problems.
Thanks @sdeastham, for reporting this and finding a fix. I will address this in December along with all of the other RRTMG-related issues/PRs that are open.
The files are now fixed on Harvard's ftp site and should be synced at WashU soon.
Regarding the leap year bug, I was not able to reproduce this. Doing an RRTMG simulation for 2020-02-29 gives me no error and the ExtData log looks okay. It is using 2002 data for Feb 27 (left bracket) and Mar 6 (right bracket). @sdeastham, did you see something else in your tests?
0000: CAP.EXTDATA: DEBUG: UpdateBracketTime: Updated bracket L for ./HcoDir/RRTMG/v2018-11/modis_emissivity.2x25.nc
0000: CAP.EXTDATA: DEBUG: ==> (L Time Requested: 2020-02-29 00:00:00
0000: CAP.EXTDATA: DEBUG: ==> (L Record time : 2002-02-26 00:00:00
0000: CAP.EXTDATA: DEBUG: ==> (L Effective time: 2020-02-26 00:00:00
0000: CAP.EXTDATA: DEBUG: UpdateBracketTime: Updated bracket R for ./HcoDir/RRTMG/v2018-11/modis_emissivity.2x25.nc
0000: CAP.EXTDATA: DEBUG: ==> (R Time Requested: 2020-02-29 00:00:00
0000: CAP.EXTDATA: DEBUG: ==> (R Record time : 2002-03-06 00:00:00
0000: CAP.EXTDATA: DEBUG: ==> (R Effective time: 2020-03-06 00:00:00
0000: CAP.EXTDATA: DEBUG: UpdateBracketTime: Updated bracket L for ./HcoDir/RRTMG/v2018-11/modis_surf_albedo.2x25.nc
0000: CAP.EXTDATA: DEBUG: ==> (L Time Requested: 2020-02-29 00:00:00
0000: CAP.EXTDATA: DEBUG: ==> (L Record time : 2002-02-26 00:00:00
0000: CAP.EXTDATA: DEBUG: ==> (L Effective time: 2020-02-26 00:00:00
0000: CAP.EXTDATA: DEBUG: UpdateBracketTime: Updated bracket R for ./HcoDir/RRTMG/v2018-11/modis_surf_albedo.2x25.nc
0000: CAP.EXTDATA: DEBUG: ==> (R Time Requested: 2020-02-29 00:00:00
0000: CAP.EXTDATA: DEBUG: ==> (R Record time : 2002-03-06 00:00:00
0000: CAP.EXTDATA: DEBUG: ==> (R Effective time: 2020-03-06 00:00:00