Changes between Version 5 and Version 6 of ticket/309/TicketSummary


Ignore:
Timestamp:
Jun 6, 2017 8:55:41 AM (2 years ago)
Author:
Jin Lee
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ticket/309/TicketSummary

    v5 v6  
    1515= NetCDF !SatRad Writefiles and Their Use =
    1616
    17 !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,
     17!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,
    1818
    1919[https://access-svn.nci.org.au/svn/nwp/da/utilities/ops/satrad/combine_pe]
    2020
    21 and installation on Raijin is,
     21Its installation on Raijin is,
    2222
    2323`raijin5:/projects/access/da/utilities/ops/satrad/combine_pe`
    2424
    25 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.
     25The 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:
    2626
    2727   * 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
     
    3030= How to Handle Ordering of Dimension Variables =
    3131
    32 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.
     32The 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.
    3333
    3434The solution above raises the question about the use of `combine_pe`. '''Q.''' Can `combine_pe` re-reorder the dimension variables?