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

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

Hi Mike,

re:
> I sent my first with the trce file before I bothered to actually read it.

:-)  Been there, done that!

re:
> I had a hard time finding it at first, or that DEBUG setting you mentioned,
> so I got distracted by that and just sent it once I found it.

The problem with creating a 'trce' file is that some users might tack it
on to commands that are accessing datasets on remote ADDE servers, and
that will result in a growing ~mcidas/mcidas/data/trce file on the
machine hosting the remote ADDE server.  This would be useful for the
McIDAS admin on that server, but it would be pretty much worthless for
the remote user.

re;
> I hadn't seen that keyword used before, and I only checked
> https://www.ssec.wisc.edu/mcidas/doc/users_guide/current/imglist.html after
> I saw it.   But even in the full docs (
> https://www.ssec.wisc.edu/mcidas/doc/users_guide/current/users_guide.pdf) I
> don't see a TRACE keyword.  I know that's the SSEC doc, that's just what
> google finds first.  But I don't see it here either:
> https://docs.unidata.ucar.edu/mcidas/current/users_guide/GlobalKeywords.html
> Not a big deal of course, but wanted to let you know if you expected it to
> be there.

I've been using TRACE= for _so_ long that I must have projected that it
would be defined in the GlobalKeywords portion of the User's Guide.  If
it really is not described, the reason that SSEC must have decided to not
define it is the situation I described above.

re:
> Regardless, now that I'm aware of TRACE this is a nice tool to have in my
> belt!

Yup, I use tracing all of the time when debugging ADDE server code.  Without
the ability to have the server document what is happening, debugging would
be next to impossible!

re:
> OH, the one and only line I edited was in abinadir.cp.  

The exact same definition should be in abinadir.cp and abinaget.cp.  If
they are different, problems _will_ be encountered at some point.

re:
> I looked there
> given ABINADIR in the trce file.

Good catch.  When one makes a call to 'get' data 'AGET' service, one
has to find out some things that a 'list' would provide.  This is
used when doing an interrogation for the set of values represented
by a pixel (e.g., RAW, BRIT, TEMP, ECHO, ...).

re:
> Interesting, here's the line that's still in my abinaget.cp file:
> const char          EREGEXP[] =
> ".._(ABI|GLM)-((L1b|L2)-(.{3,5})(F|C|M[12]|AK|HI|PR))-M([346])(_|C.._)G(1[6-9])_s(.{7})(.{6})";
> 
> And yet it still seemed to work, hmm.  Well, with the hot off the press
> v2020a this may be moot.

This needs to be changed.  Since you are grabbing the current v2020a snapshot, 
and since you _will_ be using the updated ABIN-related code from it (!),
you will end up with source modules that contain the exact same definition
for EREGEXP (which, by the way, stands for Extended REGular EXpression :-).

If you hadn't guessed, I am the one that added the regular expression parsing
of the GOES-R ground station names of images/products to McIDAS.  As a point
of history, I am the one that added the use of regular expressions in defining
ADDE datasets a LONG time ago. Regular expressions are your friend :-)

re: grabbing the current v2020a snapshot

> Got it, thank you!  I'll install this next week before I go much further,
> and will let you know if I run into anything else (fingers still crossed).

Sounds good.  I will be on the lookout for your guidance on useful min/max
values for the GLM products.

Aside:  The ranges of possible values for a variety of the variables in
the value-added GLM products are HUGE, so coming up with a way to map them
to BRITnesses is anything but easy.  I have looked at doing logarithmic
scaling, exponential scaling, etc. in comparison with the existing square
root scaling (SQRT in abincalb.inc), but I have not decided what would be
most useful.  Adding more scaling functions is something that I have 
discussed with Russ Dengel (long time SSEC McIDAS developer) on several 
occasions.

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.