JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for DEVORAC Archives


DEVORAC Archives

DEVORAC Archives


DEVORAC@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

DEVORAC Home

DEVORAC Home

DEVORAC  May 2012

DEVORAC May 2012

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Re: Agreement on consistent Channel numbering necessary

From:

Gareth Thomas <[log in to unmask]>

Reply-To:

Gareth Thomas <[log in to unmask]>

Date:

Wed, 30 May 2012 18:19:59 +0100

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (179 lines)

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:

type imager_measurements_s

      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)
>
>
> MYD021KM.A2008172.1240.005.2009317020933.bscs_000500531943
> MODIS-AQUA
> 5 5
> 1 2 6 31 32
> 1 2 3 4 5
> WAT
>
>
>
> input decsription
> -----------------
> 1)filename
> 2)instrument
> 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.
>
> Cheers
> Caroline
>
> -----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
> routines.
>
> 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
> degrees.
>
> Cheers
>
> Gareth
>
> 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.
>>
>>
>> Cheers,
>>
>> Matthias
>>
>> 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
          Clarendon Laboratory
          Parks Road
          Oxford OX1 3PU
          England

Email: [log in to unmask]
Telephone: +44/0 1865 272 894
Fax:       +44/0 1865 272 923

Top of Message | Previous Page | Permalink

JISCMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011


WWW.JISCMAIL.AC.UK

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager