[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 got the new build from the FTP and just installed it on my dev
> environment.
> 
> In mcunpack, you no longer set the version number if it's not passed like
> you said you would, but you only included the echo statements in that IF
> block and not an exit command.  

Oops, this was a mistake that I just corrected.

re:
> This is a problem because even though I
> didn't pass a version number my build still proceeded successfully.  That's
> right, it still succeeded and that's bad.  Here's how & why:

Yup, I agree.  Again, I just corrected the omission of an 'exit'
when the version number is not passed in.

re:
> Per the standard install instructions (
> https://docs.unidata.ucar.edu/mcidas/current/users_guide/PreparingthemcidasAccount.html)
> a reference to $McINST_ROOT/admin/mcidas_env.sh is to be added to
> ~/.profile, and in mcidas_env.sh MCVER is set based
> on $MCHOME/data/VERSION.TXT when the user logs in.  It just so happens that
> I had already installed a 2020a version here, and that's the only reason
> why this still worked.  I intentionally ran mcunpack without passing a
> version number simply curious to see what would happen, and now I'm glad I
> did.  taskfailedsuccessfully.gif

The instructions on the web will be updated to reflect the change
made to mcunpack.

re:
> Beyond that however, the build completed without issue.  Since you
> effectively installed it on that VM I won't bother to redo that, unless you
> want me to.

No, that shouldn't be necessary.  If your 'dev' machine is running
an older version of gcc/gfortran, then the logic added to 'mccomp.sh'
is working as hoped/designed.

re:
> I'll get back to you with notes on FED soon, though it may be Monday at
> this point.  As a sneak preview though here are a few things I've already
> noticed (though haven't thoroughly tested):
> 
> Both the L2 and L3 data plot and look about what I'd expect them to.
> The L3 values are significantly higher than the L2 values.  Good, they
> should be (hopefully 5x more).
> 
> Interestingly, without modifying abincalb.inc to change the max value, the
> L3 FED looks nearly identical to the TTU FED with max set to100.  There are
> some small differences wrt extent and a slight northward shift.  

Hmm...  If there is only a northward shift and not a change in "shape" of
areas of interest, my suspicions will be raised.  I have been relying
on tests run in AWIPS as validation that the process that stitches together
the Vlab tiles we download from AWS results in correctly located values.
Some of the testing done was comparison of features loaded directly from
Vlab tiles compared against the reconstituted full scenes (image), and I was
assured that they match identically in AWIPS.  Whether or not the procedure
that the Vlab code implements is exactly the same as the TTU code is something
that I can't comment on since I have never see either sets of code.

re:
> I'm not
> surprised by either; different processing could yield slightly different
> results, and I'm guessing that northward shift is related to paralax.  

It might indeed be a function of parallax.  Steve and I were talking to
Eric Bruning, the author of the code that produces the TTU products which
is supposedly the basis for the NOAA Vlab processing, about parallax corrections
yesterday evening over a beer (Eric is in Boulder for the SAC meeting
today and tomorrow).

re:
> But
> the plotted values are essentially the same.  This is where I want to dig
> deeper to understand what's going on here.  When I know more I'll update
> you with some samples.  But maybe we don't have to edit abincalb.inc like I
> had thought.

I'm not quite sure that I understand fully why there wouldn't be a need to
adjust values in abincalb.inc, but I assume that I will know more after you
get back with examples.

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.