Closed markjolah closed 4 years ago
@markjolah I will look into this.
@markjolah Here is my plan: I am modifying the IODA converter to remove nrecs related things, and also add units now. I am dealing with satellite radiance data first and will send you AMSU-A from 2019070100 for testing soon. Once you give me a green light, I will re-generate the whole month for all instruments. I can generate the entire month of obs data in 1-2 days (if machines behave normally).
@markjolah @cyberbass The updated obs files for 2019070100 can be found on s4 at the following location: /data/users/eliu/AOP75/2019070100_new/obs
Things fixed in this updated data set are: (1) Removed obsolete "nrecs" dimension from obs files (2) Added units to GSI reference variables (e.g., @GsiHofX) (3) Added @GsiHofX and @GsiHofXBc for sea surface temperature in SSTS obs file
Please let me know if this new set of obs files work for jedi-rapids.
@emilyhcliu, just want to double check that you will eventually be submitting a PR with these modifications. Thanks!
Also, how much work would it be to regenerate the GSI related obs files in the IODA test file set (April 15, 2018 dated obs files) using the new converter once it's completed? The concern is that something got changed that causes a test failure, and we don't discover what the issue is for a long time. Running jedi-rapids on the July 2019 files however should go a long way toward flushing these kinds of bugs out so it may not be absolutely necessary to update the April 15, 2018 files.
I'm thinking that if it's low effort we should go ahead and update the April 15, 2018 files, but if it's a lot of work we may want to hold off on that task. Thanks!
@srherbener I would like to update ioda-converters in two steps (PRs) The first one would be the following: (1) add missing units for some variables (2) remove obsolete variables and add new variables (3) add SST (4) update GPS and Ozone data types (currently used in operation)
The second one is to remove "nrecs" dimension: The GPSRO people told me that they are still using nrecs in GPSRO data. Do we still want to remove nrecs?
@emilyhcliu, Thanks for bringing this to our attention. We do want to get rid of nrecs in the ioda obs files, and I think your plan is good.
The reader in IODA is ignoring nrecs in the file, and the reader itself is generating the nrecs value and associated record numbers. It's likely that we can removed nrecs and @RecMetaData variables and the GPSRO operators would not notice. I'll work this out with the GPSRO folks. We should be able to get this straightened out before your second PR.
PRs #256, #257, #258 have resolved this issue. The original PR (#255) that this issue was tied to was closed before merging and replaced by #256 which has been merged. Therefore I'm going to close this issue now.
Currently the
gsi-ncdiag
converter package is producing improperly formatted NetCDF IODA files. These files are retaining anrecs
dimension and some are also retaining variables indexed bynrecs
. This is a problem, as these invalidnrecs
indexed variables are preserved in the HofX output IODA files, and this can lead to problems concatenating the output HofX files from each processor. Additionally, it makes it impossible to concatenate GSI observation IODA files to form longer time windows, as each window may disagree on thenrecs
dimension.To solve this issue, the
gsi-ncdiag
python package will need to be updated and tested with the GSI input files. I don't currently have these original files, so if someone could provide them, I maybe able to help debug this issue.Here is a list of GSI output files from the July 2019 run @emilyhcliu has completed, and for each file any references to
nrecs
dimension or attributes should be removed and especially any variables indexed bynrecs
should be removed. In particular some of the conventional obs are producing two different variables for Station_ID with different capitalization and indexing dimensions.