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

[McIDAS #AJH-231968]: GLM types and creating those datasets

Hi Carol,

re:
> I have some questions about creating GLM datasets. I'm trying to setup a
> new dataset to pull old GLM data. It seems like I'm having trouble setting
> the type correctly for whatever reason. The normal GLM dataset for GOES-16
> GROUP type is as follows.
> 
> dsserve.k ADD RTGOESR/GLMGROUP GLMN TYPE=POINT 
> INFO='/home/mcidas/data/GLM_GROUP.cfg' 
> DIRFILE='/data/ldm/pub/native/satellite/GOES/GRB16/GLM/LCFA/current/*' 
> \"GOES-R Geostationary Lightning Mapper Groups

This looks OK to me.

re:
> Then the dataset that's defined for the old GLM data is as follows
> 
> dsserve.k ADD RTGOESR/GLMMAY18 GLMN TYPE=POINT 
> INFO='/home/mcidas/data/GLM_GROUP.cfg' 
> DIRFILE='/data/ldm/pub/native/satellite/GOES/GRB16/GLM/LCFA/20190518/*.nc'

This also looks OK to me.

re:
> It seems like the group isn't defined correctly in the RTGOESR/GLMMAY18
> dataset because I'm getting the following error when I run the glmdisp.
> 
> glmdisp.k TYPE=GROUP TIME=IMA INC=1 COLOR=1 TOPLABEL= X X X X 12 
> DATASET=RTGOESR/GLMMAY18
> glmdisp.k: TYPE conflict: GROUP vs ^@^@^@^@^@

The error appears to be coming from specifying the keyword 'TYPE=GROUP'.  If
you leave this out, your GLMDISP invocation should work.  I say this because
I tried to replicate your test using:

- define RTGOESR/GLMMAY18 exactly as you did above (on lead.unidata.ucar.edu)

- display the 20:00 UTC image for May 18

- plot GLM GROUP values on top of the image

Here is what I ran from an interactive McIDAS session:

DATALOC ADD RTGOESR LEAD.UNIDATA.UCAR.EDU

Group Name                    Server IP Address
--------------------         ----------------------------------------
RTGOESR                      LEAD.UNIDATA.UCAR.EDU

<LOCAL-DATA> indicates that data will be accessed from the local data directory.
DATALOC -- done

DATALOC ADD GOESRALL LEAD.UNIDATA.UCAR.EDU
Group Name                    Server IP Address

--------------------         ----------------------------------------
GOESRALL                     LEAD.UNIDATA.UCAR.EDU

<LOCAL-DATA> indicates that data will be accessed from the local data directory.
DATALOC -- done


SF 1;ERASE F;IMGDISP GOESRALL/FDC13 LAT=0 75 MAG=-6 DAY=138 TIME=20:00 20:05
Erased image frame(s) 1-1
Erased graphic frame(s) 1-1
ERASE: Done
Beginning Image Data transfer, bytes= 1415376
IMGDISP: loaded frame  1
IMGDISP: done
 
GLMDISP TIME=IMA INC=1 COLOR=1 TOPLABEL= X X X X 12 DATASET=RTGOESR/GLMMAY18
USING IMAGE DAY/TIME
Plotting GLM data from RTGOESR/GLMMAY18.ALL
GLMDISP - done

re:
> Another thing I don't understand is how I can get matches for glmdisp for
> the GLMGROUP when I use TYPE=EVENT. I would have suggested that there
> wouldn't be any matches for when the types doesn't match.
> 
> glmlist.k TYPE=EVENT RTGOESR/GLMGROUP TIME=11:00 11:05
> Finds 70953 matches

This looks like a bug because if you leave the TIME interval off, you
get a TYPE mismatch indication.  For instance:

GLMLIST TYPE=EVENT DAT=RTGOESR/GLMMAY18
GLMLIST: TYPE conflict: EVENT vs 

But, at the same time, if you specify GROUP as the TYPE, you also
get a TYPE mismatch:

GLMLIST TYPE=GROUP DAT=RTGOESR/GLMMAY18
GLMLIST: TYPE conflict: GROUP vs 

But, like the GLMDISP example above, if you leave off the TYPE, you
can successfully list values:

GLMLIST DAT=RTGOESR/GLMMAY18 DAY=138
 ...
   2019138    213340   33.3916   92.2757    357202208        12 141309328      
3331
   2019138    213340   33.3705   92.2706    357202208         4  70654664      
3331
   2019138    213340   33.3705   92.2706    357202208         2  70654664      
3331
Number of matches found = 38368
PTLIST: Done

All I can say is that it looks like there is work needed to:

- catch when a user specified type conflicts with the dataset definition

- work correctly when the user specified type matches the dataset
  definition

- probably a slew of other bugs

One thing: SSEC has noted that the GLM display and list routines are works in
progress.  It could well be that there are fixes fir the errors shown above
in code that has not been released yet.

re:
> Am I not defining the glmtype correctly in any of the datasets?

No.  The problems appear to be deficiencies in the GLMDISP and GLMLIST
routines.

re:
> Thanks,

No worries.

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: AJH-231968
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.