Hi Mike,
re: I'll have to be the driver behind the major rewrite of the ABIN servers
> Understood. I'll voice my support for this feature and hope it can happen
> someday, but I know not to hold my breath.
I just need more time!
re:
> In that case I would like to request setting that value to 100. It's what
> I've been using ever since I set it and we've had no complaints. It's also
> my understanding that 5-min aggregations are much more preferred over
> 1-min, so it would probably be the more popular data & setting. That being
> said, it's been set at 16 officially this whole time and I have no idea how
> many people plot FED with McIDAS, so take this as just one guy's suggestion.
Since all of the value-added GLM (TTU and Vlab) entries in abincalb.inc are
ones that I chose, and since I do not dive into the data like you do, I
will ask if you would be willing to list which values are OK (acceptable)
and which are not (need changing). I will make the changes you recommend,
and I will check them in the next time that I update the SSEC McIDAS-X
code repository.
re:
> I had a chance to poke at this a little yesterday evening. The good news
> is IMGLIST does recognize the Level2 data, and I think it saw all variables
> (bands) I expected to be in there.
That is encouraging.
re:
> However, it did NOT recognize the Level3 data (no images satisfy criteria
> error). I noticed that the NetCDF variable names were different (e.g.
> Flash_extent_density*_w5u1* instead of Flash_extent_density). I tried
> using ncrename (ncrename -v Flash_extent_density_w5u1,Flash_extent_density
> {datafile}) but that didn't work.
Changing the data file is definitely not the way forward!
re:
> Unless it's necessary to have ALL of
> those vars changed (I was lazy and only did FED), something else might be
> breaking this too. This was at the end of a long day so I'm hoping to
> circle back to this again soon.
Your experience does not match mine for v2020a installations. To verify
that things are working, or, at least, appear to be working, I pointed
at the ADDE dataset that has the VLAB GLM L2 and L3 images and then listed
and plotted the one image I tried:
DATALOC ADD L2GOESR adde.ssec.wisc.edu
DSINFO I L2GOESR
...
VLABGLML2FD 99999 GOES-16 Level2 FullDisk Geostationary Lightning Mapper P
VLABGLML3FD 99999 GOES-16 Level3 FullDisk Geostationary Lightning Mapper P
IMGLIST L2GOESR/VLABGLML3FD FORM=ALL
Image file directory listing for:L2GOESR/VLABGLML3FD
Pos Satellite/ Date Time Center Res (km) Image_Size
sensor Lat Lon Lat Lon
--- ------------- ------------ -------- ---- ---- ----- ----- ------------
96 GOES-16 L2 30 JUN 22181 18:34:00 0 75
Band: 39 L3: GLM - VLAB Flash Extent Density w5u1 2.02 2.00 5424 x 5424
Band: 40 L3: GLM - VLAB Total Optical Energy w5u1 2.02 2.00 5424 x 5424
Band: 41 L3: GLM - VLAB Minimum Flash Area w5u1 2.02 2.00 5424 x 5424
proj: 0 created: 2022181 183400 memo: GOES Full Disk - Mode 6
type:ABIN cal type:RAW
offsets: data= 768 navigation= 256 calibration= 768 auxiliary= 0
doc length: 0 cal length: 0 lev length: 0 PREFIX= 0
valcod: 0 zcor: 0 avg-smp: N
lcor: 1 ecor: 1 bytes per pixel: 2 ss:187
Resolution Factors (base=1): Line= 4.0 Element= 4.0
IMGLIST: done
SF 1;ERASE F;IMGDISP L2GOESR/VLABGLML3FD LAT=0 75 BAND=39 MAG=-5 SU=GLMVLAB;MAP
Erased image frame(s) 1-1
Erased graphic frame(s) 1-1
ERASE: Done
Beginning Image Data transfer, bytes= 5675376
IMGDISP: loaded frame 1
IMGDISP: done
MAP: Completed frame 1
EB
BAR
FRMSAVE 1 VLABGLML3_FED_20220630_185100
So, if you are using an older v2020 and not the latest v2020a, you should
not expect that the Vlab L2 or L3 products will work. If you are using the
v2020a ABIN servers, then there is something else going on that needs
investigation.
re:
> No worries. What's important for me now is that I know how I need to
> proceed. I'll keep modifying abincalb.inc locally, and will put a post-in
> on my monitors to remind me of that whenever I need to update.
Like I said above, you have the "opportunity" (burden?) of providing me
a list of min/max values for any/all of the GLM L2/L3 products, and I
will happily incorporate them into the Unidata distribution AND check
them into the SSEC code repository.
re:
> One last question:
> Since McIDAS currently cannot read the Level3 Vlab data,
It can and does in my tests...
re:
> I still need to
> use the TTU data for my 5-min aggregations (I tried using the same process
> on the Level2 Vlab data but no joy, at least not yet). I know the grant
> for that runs out next month, is it expected that feed to be discontinued
> at that time? Just trying to plan ahead.
When the monies that TTU has been using to create their value-added GLM
L2 products runs out, the products will no longer be created, so they
_will_ disappear from the IDD. We have no resources or intentions to
pick up the activity internally especially since the Vlab GLM L2/L3
products are very usable, prehaps even more than the TTU images.
The thing that is missing (and will NOT be added) is CONUS/PACUS coverage.
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: USW-595984
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.
Attachment:
VLABGLML3_FED_20220630_185100.GIF
Description: GIF image
