[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[McIDAS #PIR-584729]: McIDAS Research Questions



Hi Rod,

re:
> I have 2 questions.
> 
> 1) Apparently there is something wrong with Effective Radius Image
> Position 56... 2202 UTC supposedly 20:02. I am not sure if you are
> seeing a problem with that image?

What is the problem you are seeing?

re:
> But is there anyway you can show me
> your display of the Effective Radius Image Position 56 and also
> Effective Radius Image Position 69?

First, you will need to refer to the particular images by time, not
by ADDE dataset position number.  The reason for this is that I do not
have a full set of Effective Radius images like you do, so the number
of elements in the set that comprises the ADDE dataset will be different,
and so it is likely that the position numbers in your dataset will
not correspond to the position numbers in my dataset.

I think I see what you mean with respect to the image at 22:023 UTC:

An IMGLIST for the first 22:02 UTC image on your _and_ my machine shows an image
that is 320x320 in size.  Since this is the size specified in the IMGREMAP
command used in the EFRADx.BAT file, it is likely that the original image was
overwritten by the remapped one.  Hmm... a quick listing for all Effective
Radius images on your machine shows that the first image for 22:02 (your ADDE
dataset position number 56) is the only one in the G13/ERAD27APR11 dataset
that has a size of 320x320:

<as 'rod' on iset2>
cd $MCDATA
imglist.k G13/ERAD27APR11.ALL
 ...
  56  G-13 IMG      27 APR 11117  22:02:00    29   86
   Band: 1    No Information Available                  5.25  5.24   320 x  320
     proj:    0 created: 2012269 190034  memo: RT GVAR
     type:PRD      cal type:BRIT
     offsets:  data=    1280 navigation=  256 calibration=  768 auxiliary=    0
     doc length:   0   cal length:   0   lev length:   0 PREFIX=   0
     valcod:          0 zcor:  0 avg-smp: N
     start yyddd: 2011117  start time:220229  start scan:  382
     lcor: 9278  ecor:  9841  bytes per pixel: 1  ss:180
     Resolution Factors (base=1):   Line=    5.0   Element=    5.0

All of the other images are 600x1400 in size, including the second one for
22:02 UTC (your ADDE position 69):

Image file directory listing for:G13/ERAD27APR11
 Pos Satellite/         Date       Time      Center      Res (km)   Image_Size
     sensor                                 Lat  Lon    Lat   Lon
 --- -------------  ------------  --------  ---- ----  ----- ----- ------------
  56  G-13 IMG      27 APR 11117  22:02:00    29   86
   Band: 1    No Information Available                  5.25  5.24   320 x  320
     proj:    0 created: 2012269 190034  memo: RT GVAR
     type:PRD      cal type:BRIT
     offsets:  data=    1280 navigation=  256 calibration=  768 auxiliary=    0
     doc length:   0   cal length:   0   lev length:   0 PREFIX=   0
     valcod:          0 zcor:  0 avg-smp: N
     start yyddd: 2011117  start time:220229  start scan:  382
     lcor: 9278  ecor:  9841  bytes per pixel: 1  ss:180
     Resolution Factors (base=1):   Line=    5.0   Element=    5.0

The question is if the image in position 56 should be deleted so
that the one currently in position 69 is used.  I can not say for
sure that this should be done, but it seems like the correct "solution".

Good thing you have a pristine copy of the original images:

ls -alt $MCDATA/archive
total 2575876
drwxr-xr-x 3 rod users       4096 Dec 29 12:42 ..
drwxr-xr-x 2 rod users      12288 Dec  6 19:40 27apr2011
drwxr-xr-x 3 rod users       4096 Aug 22 15:59 .
-rw-r--r-- 1 rod users 2637671955 Aug 22 13:04 27apr2011.tar.gz

You may need to extract the 22:02 image from 27apr2011.tar.gz:

cd $MCDATA/archive
tar xvzf 27apr2011.tar.gz 27apr2011/2011117220200_effrad.area

Then again, you may not need to do this.

re:
> 2) Is there anyway for the IMGPROBE BOX STAT I did for that particular
> storm to find out where the maximum effective radius value is relative
> to the storm like at the center of the storm, NW, NE side etc?

I don't think that IMGPROBE can do this directly.  It can, however,
plot the values from an image; contour values over the image, and
list statistics for points in a region.  It would seem that the combination
of these capabilities would allow one to find the highest (or lowest)
value being searched for.

The other thing that jumps to mind is kind of involved.  I will sketch the
procedure out here:

- IMGREMAP the image into a RECTilinear projection

  You have done this before, is not new.

- convert the image into a grid using IMGGRD

- create an ADDE dataset of type GRID for the converted
  image(s)

- use GRDINFO STAT on the resulting GRID in the ADDE dataset
  just created

I think that this would work since I vaguely remember that the
STAT action for GRDINFO will list out the location of the MAX
and MIN values in the grid/subgrid.

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: PIR-584729
Department: Support McIDAS
Priority: Normal
Status: Closed


NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.