= 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,

[https://access-svn.nci.org.au/svn/utils/branches/dev/jtl548/da/sat_da/channel_use/scripts/python/satanal]

= NetCDF !SatRad Writefiles and Their Use =

!SatRad writefiles are written out by the OPS !SatRad code. There is one NetCDF file per PE. In the past we combined those PE files into a single NetCDF file (labelled with base date/time) using `combine_pe` whose source is,

[https://access-svn.nci.org.au/svn/nwp/da/utilities/ops/satrad/combine_pe]

and 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. i.e.

   * if the NetCDF files were processed using `combine_pe` then the files will have `obs` as the first dimension variable followed by `channels` as second
   * the raw, uncombined PE NetCDF files will have `channels` as the first dimension variable followed by `obs`

= 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 order of 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?