I can see the tide is against me on this one. If the channel indexing to
be instrument specific, I think we need to define instrument specific
index arrays for both the surface albedo and emissivity data.
Something along the lines of:
integer(kind=lint) :: nchannels,nmaxchannels=6
integer(kind=lint) :: nviews
integer(kind=lint) :: nobservations
real(kind=sreal), dimension(:,:,:), pointer :: data
real(kind=sreal), dimension(:,:,:), pointer :: uncertainty
! Instrument specific channel numbers
integer(kind=stint), dimension(:), pointer :: channels
! Define corresponding bands in surface albedo data
integer(kind=stint), dimension(:), pointer :: albedo_index
! Define corresponding bands in emissivity data
integer(kind=stint), dimension(:), pointer :: emissivity_index
end type imager_measurements_s
Another complication is that the surface albedo code needs to be able to
identify the 3.7 micron channel, as it has to use the emissivity value
to set the albedo rather than trying to read it.
On 30/05/12 17:53, Caroline Poulsen wrote:
> Ok here are my thoughts on this I definitely think we should make the code robust for the future. So in this case I think channel numbering should be according to the instruments i.e for MODIS
> 1 2 6(19) 31 32
> This make defining LUTS and channel instrument information much easier and avoids future confusion. For example I already process SEVIRI with extra channels. With this code.
> I have rewritten the driver file to work all this out i.e see below
> Driver files looks like this (could also be line input)
> 5 5
> 1 2 6 31 32
> 1 2 3 4 5
> input decsription
> 3)number of channels used(i.e. line 4): number in input file(i.e line 5) this is different to accomodate processing with 1.6 or 3.7 channel for example
> 4) which channels to use
> 5) index of channels in input file
> 6) phase to process
> However I realise that this poses a problem for avhrr with its 3a 3b numbering
> For this I think we have to come up with another solution maybe the 3b channel becomes channel 6 as I think Matthias proposed.
> -----Original Message-----
> From: ORAC Developers [mailto:[log in to unmask]] On Behalf Of Gareth Thomas
> Sent: 30 May 2012 17:10
> To: [log in to unmask]
> Subject: Re: Agreement on consistent Channel numbering necessary
> Hi Matthias, all,
> Here are my thoughts on this, which differ slightly from Matthias' - I
> suspect because I have been dealing with the surface albedo and
> emissivity side of things.
> Since the primary aim of the preprocessing is to run ORAC on the "same"
> (well, similar!) set of heritage channels from a range on instruments,
> it makes sense to me that we define a set on index numbers for these
> channels across all 3 instruments:
> 1 = 0.67 microns
> 2 = 0.87
> 3 = 1.6
> 4 = 3.7
> 5 = 11
> 6 = 12
> This makes dealing with ancillary data (like the surface albedo) a lot
> easier, because its independent of a particular instrument. A selection
> of these index numbers should be defined on the command line (or
> whatever), providing a common way of selecting different mixes of
> channels across the different instruments: this is how I'd deal with the
> 3A,3B channel question with AVHRR.
> The surface data files have their own "band" number systems, which are
> not (in general) related to any of the instrument channel indexes
> (although, since we're using MODIS surface albedo data, its numbering
> follows the MODIS convention). Thus, the routines for reading this data
> need to be hard-wired to return the correct channels, and this is much
> easier if you have a wavelength index number.
> Of course, the instrument specific channel numbers/identifiers need to
> be carried around to, as do the entry numbers in the RTTOV coefficient
> files. I can't really see any way around having these instrument
> specific index numbers hard-wired into the instrument specific set up
> In order to minimise the amount of hard-wired index number selections
> (and thus number of changes that would need to be made to the
> preprocessing if additional channels were added to the list), I think
> another couple of indexes or masks need to be specified as well. In
> particular, I suggest defining two masks which define which channels are
> "shortwave" and which "longwave" (or solar and thermal, if you prefer).
> Ie. for the channels listed above, these would be:
> shortwave = (/ 1, 1, 1, 1, 0, 0 /)
> longwave = (/ 0, 0, 0, 1, 1, 1 /)
> Don't forget that 3.7 microns is both shortwave and longwave!
> This may be self-evident, I would also suggest that we require that the
> channels be stored in wavelength order. This allows the use of array
> slicing to extract the shortwave or longwave channels.
> Regarding Matthias' point 4, the system that has been used in ORAC in
> the past is:
> -90< lat< 90
> -180< lon< 180
> Absolute azimuth is measured clockwise from north
> Relative azimuth has zero lying where the satellite and sun lie in the
> same direction when viewed from the surface, and ranges from 0 to 180
> On 24/05/12 12:43, Jerg Matthias wrote:
>> Hello everybody,
>> While programming it occured to me that we should discuss the channel numbering to find a consistent solution for the different parts of the software (Preprocessing, RTTOV, ORAC). Here are some thoughts about it to start the discussion:
>> 1.) It seems the most natural way is to use the original instrument numbering. While this is straightforward for MODIS it is more difficult for AVHRR as there are channels 3A and 3B. 3B seems to be attached to the files as channel 6 and they ar not always assigned meaningful number as they are switched on/off. All channels are read in presently but there is a flag which chooses for the preprocessing if either all channels are processed, all-3A or all-3B. Any thoughts on that? What about AATSR?
>> 2.) To read the RTTOV coefficeint files the instrument channel numbers have to be mapped to the entry number of the respective channel in the coefficient file. This is presently hardwired in the setup routines of the respective instruments. I think this is OK so far. When calling RTTOV this again changes as channels there are just counted starting with 1.
>> 3.) How shall we connect the preprocessing and ORAC in this respect?
>> 4.) Another thing which has nothing to do with channels but which should be clarified and unified in the preprocessing is the definition of the angles and lat,lon.
>> Dr. Matthias Jerg
>> ESA Climate Change Initiative
>> Satellite Application Facility on Climate Monitoring (CM-SAF)
>> Deutscher Wetterdienst (DWD)
>> Frankfurter Straße 135
>> D-63067 Offenbach
>> Tel.: +49-69-8062-2502
>> Fax: +49-69-8062-2506
>> E-mail: [log in to unmask]
Address: Dr G E Thomas
Atmospheric, Oceanic & Planetary Physics
Oxford OX1 3PU
Email: [log in to unmask]
Telephone: +44/0 1865 272 894
Fax: +44/0 1865 272 923