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

[McIDAS #JGN-249914]: IMGMAKE

Hi Mike,

re:
> Updating McIDAS:
> First I tried the mcupdate route, didn't go so well...
> 
> > <as 'mcidas>
> > cd ~mcidas/mcidas2017/update
> > -- download mcupdate.tar.gz
> > -- download mcupdate
> > -- make sure that mcupdate is executable
> > ./mcupdate
> 
> Did all that.
> 
> > cd ../src
> > make && make install
> 
> Did that, but was then greeted with this:
> ...
> /bin/sh: 5: cd: can't cd to ../hdf
> makefile:2906: recipe for target '../hdf/config.status' failed
> make: *** [../hdf/config.status] Error
> 
> Sure enough, the .old directories mcupdate made were there, but no
> replacements.  Did I skip a step, should I have clobbered first?

Oops, I forgot to revert the 'mcupdate' script to an earlier, simpler
version, one that does not replace subdirectories of ~mcidas/mcidas<version>.
I just made the editing change to the script in the Downloads area.  Sorry!

re:
> No matter, at that point I decided to go the full distro route...
> 
> > The full distribution tar file, mcidasx2017.tar.gz, contains all of the
> > updated code, so you can also do:
> >
> > <as 'mcidas'>
> > cd mcidas2017/src
> > make clobber
> >
> > cd ~mcidas
> > -- download mcidasx2017.tar.gz
> > ./mcunpack
> >
> > cd mcidas2017/src
> > make && make install
> 
> Did all of this, no apparent issues installing this way.

Phew!  There shouldn't be as this is the standard way of installing...

re: Please let me know the results you see after upgrading...

> Okay, I think I've had enough coffee to do this...
> 
> First thing's first, a baseline from a local data set:
> IMGDISP NPGOESRL/FDC13 MAG=-3 LAT=0 75
> 
> Plots okay, but still dim as noted yesterday.
> Time to copy local data and plot the copy:
> IMGCOPY NPGOESRL/FDC13 GOES16.13
> IMGDISP GOES16.13 MAG=-3 LAT=0 75
> 
> Plots completely white, so that's a failure. But I'm not giving up
> that easy, maybe CONUS data will be different?

This is very strange indeed.  I tested the IMGCOPY and IMGDISP of
each FD band yesterday with _no_ problems.

re;
> IMGDISP NPGOESRL/CONUSC13 MAG=-4 LAT=37 95
> 
> Plots okay, but still dim here too.  Now for the copy:
> IMGCOPY NPGOESRL/CONUSC13 GOES16.13
> IMGDISP GOES16.13 MAG=-4 LAT=37 95
> 
> Plots a white background, but black within the CONUS EAST domain, you
> know, where data should be.  Well that's different.  Now between this
> and all my other odd symptoms of late, I'm getting suspicious; I need
> another baseline.  Let's plot some data from your server and see what
> that looks like.
> IMGDISP NPGOESR/CONUSC13 MAG=-4 LAT=37 95
> 
> Plots totally fine, and at the appropriate brightness!  And the copy??
> IMGCOPY NPGOESR/CONUSC13 GOES16.13
> IMGDISP GOES16.13 MAG=-4 LAT=37 95
> 
> Also plots totally fine!!  Well that settles it, something's clearly
> fubar on my end.
> -head thumps on desk-

I'm with you on the banging of head on desk!  I don't have any idea
what could be causing your white backgrounds and MCSTRETCH failures!!

re:
> I'm going to go ahead and do a clean install from scratch someplace,
> test that, and get those results back to you.  But first, while I'm
> here, let's test IMGPROBE (your server's data again)...
> IMGDISP NPGOESR/CONUSC13 MAG=-4 LAT=37 95
> IMGPROBE LIST POINT MODE=N LAT=37 95
> 
> Image Name           Day      Nominal Time   Scan Time    Band
> ----------------      -------    ------------   ---------    ----
> NPGOESR/CONUSC13    15 Dec 17349   15:47:22      15:47:52      13
> 
> File     Nominal  Image     RAW         BRIT        TEMP
> Lat/Lon      Line/Element  Line/Element                              K
> 37:00:12/ 95:01:21   1077/ 1307    1078/ 1308           3068
> 104      278.16
> 
> IMGCOPY NPGOESR/CONUSC13 GOES16.13
> IMGDISP GOES16.13 MAG=-4 LAT=37 95
> IMGPROBE LIST POINT MODE=N LAT=37 95
> 
> Image Name           Day      Nominal Time   Scan Time    Band
> ----------------      -------    ------------   ---------    ----
> GOES16.9999         15 Dec 17349   15:47:22      15:47:52      13
> 
> File     Nominal  Image     RAW         TEMP        BRIT
> Lat/Lon      Line/Element  Line/Element                    K
> 37:00:12/ 95:01:21   1077/ 1307    1078/ 1308           3068
> 278.16         104
> 
> Not sure why temp and brit switched places in the output,

Me neither, but I didn't feel like this was of any consequence.  Hmm...
it could be that the order of the available calibrations in the calibration
module are different than the order that the comment cards are built
in the SCMI ADIR server.  I'll check this out today before I dive into
incorporating SSEC's XCD 2017.2 mods into my release (which will result
in a Unidata v2017b release).

re: 
> but the
> values are identical.  Looks like IMGPROBE is working as intended.  If
> you want me to test this in different ways, please let me know.

Getting IMGPROBE to work/work correctly is what I was beating my head
against yesterday and the day before.  Yesterday is when I found
the BONEHEAD mistake in the SCMI calibration module, sigh!

re:
> One last thing, regarding TCONUS - ECONUS.  Yeah, I didn't connect the
> T=Test dots either.  I brought this up though because I noticed
> goes-restitch.py still has a reference to TCONUS, so ECONUS may not
> get caught:
> 66    # TCONUS is just CONUS from the mode 4 full disk
> 67    if region == 'TCONUS':
> 68        scene = 'CONUS'

I'll touch base with Ryan about this.

re:
> Also, I'm under the impression that EMESO will be used when the
> satellite is in 30-second mesoscale mode, so it wouldn't surprise me
> to see that directory pop up when that happens.  I vaguely recall
> TMESO appearing before during 30-sec mode, but don't have the evidence
> from that any longer.

I'll pass this along to Ryan also.

re:
> Okay, now for me to go install McIDAS from scratch.  I'll probably do
> this on a whole different machine initially just to operate in a clean
> environment.  Will report back when I have more.

OK, thanks.  And, many apologies for the problems I have inadvertently
thrown your way!  I have to add, however, that your testing has helped
me immensely!  SSEC developers have the advantage that they have a set
of testers that stress test new developments and report any strangeness
back to the developer toute de suite.

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: 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.