[McIDAS #VTR-898959]: LWU

Hi Mary Ellen,

re:
> I think we're officially MUG members again so I hope it will be OK to
> float another question your way....

:-)

re:
> I have MET9 data from two sources (NESDIS and EUMETSAT).

Quick questions:

- is the data you have in McIDAS AREA file format?

- if yes, is the machine that created the AREA file of the same
  'endian'ness as the machine on which you are running (i.e.,
  is the byte order in the AREA file you are working with the
  same as the byte order for your machine)?

  You can see this quickly using LWU LIST.  For instance, suppose
  the AREA file you have is AREA3000.  Run the following and see
  what the output looks like:

  LWU LIST AREA3000 0 64

  The very first line of the LWU listing will tell you if the
  byte ordering of the image matches the machine you are running
  on. How?  the second word should be the number 4.

  Example:

LWU LIST AREA3000 0 64
       0.          0           4 HEX:        0        4 ASCII:

  The second number being 4 tells me that my AREA3000 image was created
  on a machine with the same endianness as the machine I am running
  on (which is Linux running on an Intel processor).

  Here is an example where the endianness of an image does NOT match
  my machine:

LWU LIST AREA9000 0 64
       0.          0    67108864 HEX:        0  4000000 ASCII:

  Notice how the second number is _not_ 4; instead it is 67108864.

The point is that in order to use LWU POKE to change a value in an
AREA file, the value you POKE needs to be of the same endianness as
the rest of the image.

re:
> NESDIS time
> stamps the data at the start of the scan period (e.g, hh:12 valid at
> hh:15) and EUMETSAT time stamps the data at the end of the scan period
> (e.g., hh:27 valid at hh:15).

I didn't know this!

re:
> In some cases we have 1 band of data from
> EUMETSAT and the rest from NESDIS. Our sw requires that the imglist of
> all the image bands for a particular time have the same timestep as a
> q.c. so that the code doesn't accidentally use an image from the next
> time step. So, I'd like to manually modify the EUMESAT image's time
> value to coincide with the NESDIS images.

OK, I understand.  This should be doable directly if the endianness of
the image is the same as the endianness of the machine on which you
will run LWU POKE.

re:
> I was hoping to use LWU POKE to do this however, it doesn't appear that
> LWU contains the time/date info of the image.

Huh?  I don't understand 'LWU contains the time/date info of the image'.
LWU deals with any file, and if the file is in AREA format, then the
image header will have the date and time of the image.

re:
> Can you tell me the command
> that will list the image header information so that I can modify it?

LWU POKE will do the job subject to the proviso that I outlined above.

Comment:

- if the endianness of the image(s) you are dealing with are different
  from the endianness of the machine you are running McIDAS on, the
  easiest thing to do is convert the endianness of the image.  The
  best way to do this is to create input and output datasets and
  IMGCOPY the original from the input data set to a new image in
  the output dataset.  The AREA file created in the output dataset
  is guaranteed to have the endianness that matches your machine
  since it will have been created on your machine.

Please let me know if anything above does not make sense or match
what you are seeing.

re:
> Thanks!

No worries.  Welcome back to the MUG!

Cheers,

Tom
--
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: VTR-898959
Department: Support McIDAS
Priority: Normal
Status: Closed