ticket_309_TicketSummary - ACCESS-NRI/accessdev-Trac-archive GitHub Wiki
Source Code and its Installation
The "trunk" version is,
https://access-svn.nci.org.au/svn/nwp/da/utilities/ops/satrad/satanal
which is installed for a general use on Raijin,
raijin5:/projects/access/da/utilities/ops/satrad/satanal
Jin has his development branch which has newer features,
NetCDF SatRad Writefiles and Their Use
SatRad writefiles are written out by the OPS SatRad code: one NetCDF file per PE. In the past we combined the NetCDF files from all PE's for a given base date/time into a single NetCDF file, labelling the combined NetCDF file with the base date/time. The utility for doing this is combine_pe
whose source is,
https://access-svn.nci.org.au/svn/nwp/da/utilities/ops/satrad/combine_pe
Its installation on Raijin is,
raijin5:/projects/access/da/utilities/ops/satrad/combine_pe
The problem with combine_pe
is that it reorders the dimension variables used in multi-dimensional fields. This was necessary since NetCDF concatenation was only allowed along a variable which is a record dimension and during the making of record dimension the order of dimension variables need to be swapped. So the current situation with regard to SatRad NetCDF writefiles is that there can 2 different types depending on how they are processed:
- if the NetCDF files were processed using
combine_pe
then the files will haveobs
as the first dimension variable followed bychannels
as second - the raw, uncombined PE NetCDF files will have
channels
as the first dimension variable followed byobs
How to Handle Ordering of Dimension Variables
The easist solution is to stick with the dimension-variable order used in raw PE NetCDF files. As these files are written out by SatRad as long as the SatRad code doesn't change the order will remain unchanged. This assumption of a particular ordering for dimension variables also simplifies code.
The solution above raises the question about the use of combine_pe
. Q. Can combine_pe
re-reorder the dimension variables?
Other Aspects of satanal Needing Improvement
- The use of the constant name,
FinalRejectReport
(inFinalRejectReport = 0b11111111111111111101000000000000
for example) is misleading.FinalRejectReport
is not one of the QCflags. It is used inReportFlags
inOB_type
. I should come up with a constant name which doesn't conflict with OPS