[McIDAS #USW-595984]: 20200416: GLM imagery / McIDAS / CoD processing

Hi Mike,

Many apologies for the very slow reply...

re:
> I'm not sure if you've been following along with this lately, but thanks
> to Eric I've been able to make some good progress on our Flash Extent
> Density overlay.

I've been following what I am being CCed on...

re:
> But I'm running into a problem and I'm hoping you
> can help me out.
> 
> Ultimately what I'm trying to do is get the color scale for FED to be as
> close to AWIPS as possible.  Most of the examples I've seen of that look
> like this: ( https://i.ytimg.com/vi/zzQd32C56Kg/sddefault.jpg ;).  It's
> 0-256 on an exponential curve, and I'm not sure how best to manipulate
> McIDAS to come up with something similar.

OK.  Currently, the scaling used for the GFED is SQRT.  I have discussed
with folks at SSEC the need to include a LOG scaling option, and the
comment I got was that this had been considered, but there was no known
need for such a scaling at the time that it was considered.  Now that the
GLM lightning products are being supported, it is obvious that such a
scaling option is needed.

re:
> I also suspect McIDAS is capping the FED values too low during its initial
> stretching.  McIDAS will display FED as 0-255 brightness values, and even
> on low-end events that scale now tops out pretty quick.  Part of that
> is I'm now doing 5-min summations, whereas I'm betting McIDAS's handling
> was designed for just 1-min.  I'm looking at abincalb.inc and it looks
> to me that FED be being capped at 16; in other words it's taking the FED
> data and stretching it 0-16 to 0-255.  Is my understanding correct here?

Your understanding is spot on.  I chose the scaling values after looking
at a series of images that were available to me at the time.  I knew that
these values would need to be adjusted at some later time like when we
move into seasons with more lightning.  On top of the simple need to
adjust the values used for scaling, there is a need to be able to modify
those values by end-users.  The redesign of the ABIN ADDE servers will
have those kinds of values specified in a (set of) configuration file
that can be edited.  I say set since my original discussions with SSEC
were to support something like the CORE, SITE and USER configuration
file sets like other commands.

re:
> Assuming that's the case, 16 is far too low for 5-min summations.  The
> next place my head goes is to try adjusting that value and see if that
> helps my problem.  Can you recommend how I can easily do that, and remake
> just the necessary files so I don't have to remake the whole installation?

Unfortunately, the only way to modify the values right now is to change
the values in the abincalb.inc file and then rebuild/reinstall the ABIN
servers.  You do not have to rebuild the entire distribution, so the
job is not as monumental as it might seem at the offset.

Here is what I do in my development environment when adjusting values
like the ones in abinparm.h and abincalb.inc:

-- edit abincalb.inc

make libmcidas.a abinadir abinaget && rm ~/bin/abina* && ln abinadir abinaget 
~/bin

Having to do this is the reason for my comment above that the end-user needs
to be able to modify these sorts of values themselves.

re:
> All that being said, given how much traction these products are getting
> and that they are plottable in AWIPS, I'm wondering if these GLM products
> (even 5-min ones) will eventually be handled more appropriately by
> McIDAS itself with future patches.

The rewrite of the ABIN servers should make using these products much
easier/better.

re:
> That's sort of what happened with
> the ABI-L2 products right, where SSEC made their edits to abincalb.inc
> (and/or elsewhere) and their own EU tables to match AWIPS?  If that is
> the plan, then maybe I shouldn't spend too much effort hacking my own
> solution together.

That is, in fact, the plan.  That being said, it is unlikely that SSEC
will be the ones creating tailored enhancement tables, that job will fall
to me, and I will happily include in the Unidata McIDAS-X distribution
enhancement tables that you have created (after checking them over, of
course).

Again, I apologize for the tardiness of my reply!

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.