[Datastream #MQU-657040]: L2 products sent in NIMAGE

Hi,

re:
> Do you have something describing the differences in the CMIP product
> from NOAAPORT as opposed to those from STAR?

I am not familiar with the CMIP products from STAR, so I guess that
the answer would be no.  The naming convention that I used to name
the reconstituted CMIP imagery, however, was taken from the PUG.

re:
> One observation, the start and end times do not match. The ones below
> are off by 2 ms. If the resolution of the data is the same, I think the
> start and end times would be identical (example would be channel 16).
> 
> STAR
> OR_ABI-L2-CMIPC-M6C01_G16_s20192281826560_e20192281826560_c20192281826560.nc
> 
> NOAAPORT
> OR_ABI-L2-CMIPC-M6C01_G16_s20192281826562_e20192281829335_c20192281829435.nc

It seems like you have the example names switched.  I force the milliseconds
value to be '0' in the goes-restitch.py script that I am using since there
is no information in the tiles that we are getting in the NOAAPort SBN that
has this information.  I decided that setting the millisecond value to '0'
was as good as leaving it out altogether.

That the millisecond values are all '0' can be seen in TDS listings of
dataset contents.  For instance, for CMIP CONUS Channel 1:

http://thredds.ucar.edu/thredds/catalog/satellite/goes/east/products/CloudAndMoistureImagery/CONUS/Channel01/current/catalog.html


> Rick
> 
> 
> On 8/16/2019 12:40 PM, Rick Kohrs wrote:
> > Success.
> > Also grabbed your new abin servers and they worked, that is not the
> > case with the current release of McIDAS-X.
> > Have a great weekend!
> >
> > On 8/15/2019 4:30 PM, Unidata Datastream Support wrote:
> >> Hi,
> >>
> >> re:
> >>> Aha!
> >> Promising! :-)
> >>
> >> re:
> >>> ldm.py you provided is totally different than my version. pip is
> >>> installing ldm-0.1.3.dist-info, - that must be a little old.
> >> Must be.
> >>
> >> re:
> >>> Things were running fine but needed to stop so I can get the files
> >>> to go
> >>> to the correct location.
> >> The top level directory under which goes-restitch.py will create the
> >> reconstituted imagery is defined as the value of the '-d' flag in
> >> the NOTHER action in the pqact.conf_npgoesr pattern-action file.
> >> Unlike when making changes to the LDM configuration file
> >> (~ldm/ldmd.conf),
> >> one can typically make changes to the contents of pattern-action files
> >> actions and make them active without stopping and restarting the LDM.
> >>
> >> The general process is:
> >>
> >> <as 'ldm'>
> >> -- edit the active LDM pattern-action file
> >> ldmadmin pqactcheck            <- gross check for syntax errors in
> >> pattern-action files
> >> -- if there are no errors
> >> ldmadmin pqactHUP              <- send a signal to all pqact
> >> instances telling them to
> >>                                    reread their pattern-action files
> >>
> >> This may not work for the Python goes-restitch.py action, however, as
> >> the approach taken in this (and other) ldm-alchemy script(s) is to keep
> >> running since the script is typically waiting for pieces to arrive
> >> and then add them to a product that is being built.  That being said,
> >> stopping, making sure that the Python invocations have exited, and
> >> then restarting always works.
> >>
> >> re:
> >>> Thanks for all your help!
> >> No worries.  Sorry I didn't remember exactly what I did to get things
> >> working on the machine that is creating full scenes from tiles here.
> >>
> >> By the way, given the rather high number of errors that I see in the
> >> NOAAPort ingest on both SSEC ingest machines, np1 and np2, it is
> >> possible that your reconstituted images will not be as complete as
> >> the ones we are creating ** assuming, of course, that you will be
> >> REQUESTing the NOTHER feed from your own ingest machines.  The
> >> reason for this is we use the 2 NOAAPort ingest machines here in
> >> UCAR, one at LSU/SRCC and the two that SSEC operates to create
> >> as good as possible datastreams that originate from NOAAPort.
> >>
> >> 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: MQU-657040
> >> Department: Support Datastream
> >> 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.
> >>
> >>
> --
> Rick Kohrs
> Satellite Data Services
> Space Science and Engineering Center
> University of Wisconsin - Madison
> address@hidden
> 608.263.6312
> 

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: MQU-657040
Department: Support Datastream
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.