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

[McIDAS #JGN-249914]: IMGMAKE

Hi Mike,

re:
> Nearly everything was K=ABIS, did a find/replace all to K=SCMI.  I'm
> only working with GOES16 on this install so those were the only
> entries I had in there.

To be clear, the dataset I was talking about was the one for the GOES-16
SCMI images that are distributed in NOAAPort.  The GOES-16 images that
are in the GRB use K=ABIN in RESOLV.SRV.

re: please report snags

> I've found two, but at least one should be an easy fix.
> 
> After sourcing the file you mentioned above, the new MCSTRETCH
> variable was not in my environment.  I'm using bash, so I'm looking at
> those .sh files.  I see 'MCSTRETCH="EXP"' exists, but MCSTRETCH was
> not added to the export line in either .sh file (line 51 in
> mcidas_env.sh, line 11 in user_env.sh).  For the other shells, each
> line uses setenv so I don't foresee a problem there.

That's what I get for doing too fast, last minute edits.  I have
added MCSTRETCH to the list of environment variables that get exported
in both the user_env.sh and mcidas_env.sh scripts.  After doing this,
I cut a new distribution compressed tar file, mcidasx2017.tar.gz, and
uploaded it to the McIDAS-X v2017 download area on our website.

re:
> Snag two, I'm now seeing some odd artifacting when I display GOES16
> data.  I'm attaching an example.  Below are the settings I used to
> make that image:
> 
> IMGREMAP NPGOESR/FDC13 GOESR.13 PRO=LAMB 5 28 98.5 SIZE=14000 11000
> IMGDISP GOESR.13 MAG=-6 LAT=37.0 93.0
> 
> A number of differences would yield something similar (remap or not,
> full disk data or conus, other bands, etc.).  Though one combination
> that seems right is IMGDISP the raw CONUS data with SU=IRTEMP, most
> other things look like that example.  I can try to narrow down what
> circumstances cause it better tomorrow when I have a little more time.

Hmm...  Since I didn't touch the IMGREMP or ABIN ADDE server code,
the IMGREMAP strangeness show in the example display that you attached
is a puzzler.  This one will take some deep code diving, so it may
take quite a bit of time to find and fix.

re:
> But some good news, whatever problem I was having earlier with
> remaping and SU tables seems to have gone away.

I don't understand the SU problem you reported previously, so I'm
glad that it went away.

re:
> I can remap and SU
> just fine now, and I tend to believe whatever's going on now is
> unrelated.

That is my guess as well.

Again, figuring out what is going on with the IMGREMAP will likely
take a lot of time... sigh!

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: JGN-249914
Department: Support McIDAS
Priority: Emergency
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.