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

[McIDAS #JGN-249914]: IMGMAKE

Hi Mike,

re:
> I was able to confirm something today and thought you'd want to know.
> 
> When GOES-16 is in 5-minute full disk mode (abi_mode=4), the end result
> from goes_restitch.py are files with ECONUS in the name, as opposed to
> CONUS.

OK, I thought that Ryan had/was going to fix this.  I know I talked to
him about the previous situation where his ldm-alchemy python script
would put things in a TCONUS directory.  Putting files in a ECONUS
directory is likely a result of the same sort of oversight.

re:
> We discussed this some time ago and what I did was to run the
> DSSERVE command with ".../GOES16/*CONUS/Channel..." in the DIRFILE and
> capture both under the "CONUS..." descriptor.  While that will capture
> either scenario, what I confirmed today is that if any ECONUS data exists
> for a data set, it will always be considered most recent even if newer
> CONUS data also exists.  So, say I have data for CONUS and slightly older
> data for ECONUS, and do an IMGDISP NPGOESRL/CONUSC02 given the above setup
> with that data set.  Even though CONUS data may be newer, the older ECONUS
> data gets displayed.  I'm guessing that because E comes before C, that's
> just how it gets sorted.

It is definitely a sorting issue.  Looks like I have to add more code to
do internal sorting of the list of files to be examined... sigh.

re:
> What I ended up doing was to remove the wild card from the DSSERVE DIRFILE
> line and to make CONUS and ECONUS separate.  Because of how I'm scripting
> everything anyways, I'll already know which one I want to look at, and this
> seems to prevent a problem with perpetually displaying old data until
> everything from ECONUS gets cycled out.  But I'm not sure this is ideal,
> say you're using the GUI and you don't know offhand which is most recent?
> At any rate, wanted to bring this to your attention.

Thanks for the sleuthing!

re:
> Also while I'm here, Evan was wondering if there had been any update
> pertaining to the email he sent Unidata prior to the holidays?

We discussed Evan's email internally.  I just have not found the time
to reply to it properly.  Please let Evan know that it is on my list
of things to do.

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.