[McIDAS #VON-803764]: 20220830: GOES west schedule

Hi Carol,

re:
> Wow, there's a lot here! 

Yea, sorry for the lengthy explanations...

re:
> Thanks for explaining the schedule. I had assumed
> that interleave was going to still output GOES-17 data that contained
> GOES-18 data, not vice versa. That's why I was confused. 

I think that NOAA's calling it an interleave test has been misleading
since the onset.  To me, interleaving would mean that there would be
both GOES-18 and GOES-17 products in the distribution systems (meaning
GRB and NOAAPort), but not ones for the same times, but this is not
how things were setup on the NOAA side.

re:
> We'll have to get
> our GOES-18 data archiving set up as well now. I thought I could set that
> up in December, before GOES-18 was officially the operational west
> satellite. Anyways, I'll work on getting that all going this week.

Sounds good.  I don't recall when the next GOES-18 interleave period
is scheduled, but I would imagine that it might be sooner than later
since the current testing seems to be working nicely.

re:
> First, we are not pointing to atm.ucar.edu for any of ADDE dataset
> definitions, so I don't have to do anything there. We are mostly pointing
> to lead.unidata.ucar.edu for our ADDE dataset definitions.

Excellent!  I figured that I would bounce the notion off you first and
get your reaction before sending out the email to our mcidas-x and
idvusers email lists.

re:
> Good to know about the various GROUP name changes that you listed. I think
> you were telling me about this the last time that we talked. In general, we
> just reference our local data that we're pulling from LDM, but it's still
> good to know for other testing purposes.

Sounds good!

One additional piece of information that is pertinent to the idea behind
using adde.ucar.edu instead of atm.ucar.edu or atm-nwsc.unidata.ucar.edu:

Currently, we are providing three publicly-accessible ADDE servers:

adde.ucar.edu
lead.unidata.ucar.edu
adde.ssec.wisc.edu

As noted previously, adde.ucar.edu can float to different machines so that
maintenance can be done without interruption of service.  We have kicked
around the idea for a _long_ time of making adde.ucar.edu the front end
to a cluster of machines (lead.unidata.ucar.edu, adde.ssec.wisc.edu,
atm-nwsc.unidata.ucar.edu and atm.ucar.edu), but the setup when backend
machines are not all located in the same subnet is tricky enough that
we have held off on trying it.  At some point down the road, we may figure
out a simpler way to do "long distance" clustering, but for right now,
we will continue with operating ADDE on 3 geographically dispersed machines
(again, lead.unidata.ucar.edu which is housed in FL-3, adde.ucar.edu
which currently points at atm-nwsc.unidata.ucar.edu which is house in the
NWSC in Cheyenne, and adde.ssec.wisc.edu which is located in the SSEC Data
Center in Madison, WI).

> Thanks,
> Carol
> 
> 
> 
> address@hidden> wrote:
> 
> > Hi Carol,
> >
> > re:
> > > Despite trying to study this schedule -
> > >
> > >
> > https://www.goes-r.gov/users/transitionToOperations18.html#:~:text=GOES%2DT%20launched%20on%20March,%2D17%20as%20GOES%2DWest
> > >
> > > I'm still confused about which GOES satellite is the operational west
> > > satellite. 8/1-9/8 should we be using GOES-18, and GOES-17 currently
> > > isn't be distributed?
> >
> > That is correct.  NOAA is running a series of "interleave" tests in
> > which GOES-18 imagery replaces GOES-17 imagery in the GOES ReBroadcast
> > (GRB),
> > and for the current test, GOES-18 imagery is also replacing GOES-17 imagery
> > in NOAAPort.  The current test is the third interleave test in a series
> > that I think will include 2 more.
> >
> > re:
> > > BUT GOES-17 will be back on September 8th?
> >
> > That is what all of the notifications I have seen indicate.  The original
> > end date for the current interleave test was supposed to be September 6,
> > but they pushed it back to September 8 a few weeks ago.
> >
> > re:
> > > GOES-18 will be the official operational satellite starting in 2023?
> >
> > That is what I have seen in various notifications we get from NOAA.
> >
> > As far as I can tell, the testing of GOES-18 has been proceeding nicely,
> > so it would not surprise me at all to see an accelerated transition
> > to GOES-18 as GOES-West.  NB: I have not seen any hint of this in
> > the notifications that we receive, but I my gut is telling me that
> > the transition may well be accelerated.
> >
> > The plans that I have seen have GOES-17 drifting back east to a
> > parking orbit somewhere around our longitude where it will then
> > be made ready to take over for GOES-16 or GOES-17 if severe
> > enough problems develop on either.
> >
> > Since I have you "on the line", I want to let you know the following:
> >
> > If you have any process(es) that point at the ADDE server on atm.ucar.edu,
> > you should change it/them to point at adde.ucar.edu instead.  The reason
> > for this is we want to be able to move the adde.ucar.edu service to new
> > or different backend machines so that we can do work on the existing
> > service host.  We did one of these swaps in the early part of the summer,
> > and, for the most part, users have not even known about the swap.  Some
> > sites that run processes that access data via ADDE, however, are still
> > pointing at atm.ucar.edu, and this has caused us to have to spend time
> > trying to figure out who the sites are; determine contact emails; and then
> > inform the sites about the need to switch.  This is true not only for
> > McIDAS-X users, but also for IDV and McIDAS-V users.
> >
> > McIDAS-X poses a particular problem/challenge since it has always included
> > local caching of the IP address for ADDE server names presumably to avoid
> > having to do a name to IP address lookup each time it contacts a remote
> > ADDE server.  The downside of this approach is that the IP address will
> > continue to be used even if the name is moved to a different machine that
> > has a different IP address.  McIDAS-X users can run a McIDAS command that
> > will force an update of this name <-> IP paring, but few users
> > will actually remember/know that this is something that should be done
> > periodically.
> >
> > The command that a McIDAS-X user can run to force the update of the name
> > <-> IP
> > address pairings is:
> >
> > DATALOC HOST
> >
> > Running this will force all pairings to be updated.
> >
> > So, the question to you is if there are any EOL processes that use our
> > open ADDE servers, and, if yes, are any of them pointed at atm.ucar.edu?
> > If the answer is yes, please change them to point at adde.ucar.edu,
> > AND insure that the McIDAS environment is updated with the current
> > name <-> IP address pairing.
> >
> > For reference, the name <-> IP address pairings can most often be found in
> > the files:
> >
> > ADDESITE.TXT
> > MCTABLE.TXT
> >
> > The exact list of files that could be used is defined in the setting
> > of the environment variables McTABLE_READ and McTABLE_WRITE.
> >
> > NOTE: the entries in ADDESITE.TXT and/or MCTABLE.TXT can be updated
> > by hand by editing the files.  The settings that one will see in
> > either/both
> > of these files for a specific dataset will look like:
> >
> > ADDE_ROUTE_WEST=ADDE.UCAR.EDU
> > HOST_ADDE.UCAR.EDU=128.117.135.126
> >
> > 'ADDE_ROUTE_WEST' defines the server name to hit when accessing the
> > dataset whose group name is WEST, and 'HOST_ADDE.UCAR.EDU' defines the
> > IP address to use when trying to access the name ADDE.UCAR.EDU.
> >
> > On a similar note, I wanted to let you know that we are trying to
> > winnow down the number of ADDE dataset definitions that we have
> > on each of our public-facing ADDE servers.  In particular, the
> > GOES-18 interleave testing cause me to rethink the datasets that
> > I setup some years ago as the group names used are too specific
> > to the satellite that imagery comes from.
> >
> > For example, I created the following ADDE data set group names a
> > long time ago:
> >
> > RTGOESR
> > GOESRALL
> >
> > RTGOESS
> > GOESSALL
> >
> > NPGOESR
> > NPGRALL
> >
> > NPGOESS
> > NPGSALL
> >
> > These were fine while GOES-16 is GOES-East, and GOES-17 is GOES-West,
> > but they are "bad" when more than one satellite can provide images as
> > either of the operational platforms.
> >
> > When GOES-18 imagery started to be distributed in the GRB and then
> > later in NOAAPort, I create new ADDE groups that represented
> > the new satellite and no others:
> >
> > RTGOEST
> > GOESTALL
> >
> > NPGOEST
> > NPGTALL
> >
> > These dataset definitions allow a user to access imagery from the specific
> > the satellite that is desired, but they do not account for when there might
> > be a mixture of satellites providing imagery, like in the current GOES-18
> > interleave test.  For this reason, the best datasets to use *if one wants
> > imagery from GOES-East or GOES-West* are:
> >
> > EAST
> > EASTALL
> >
> > WEST
> > WESTALL
> >
> > NPGEAST
> > NPGEALL
> >
> > NPGWEST
> > NPGWALL
> >
> > The current definitions of the EAST and WEST datasets are such that EAST
> > just serves GOES-16 imagery while WEST serves either/both GOES-17 and
> > GOES-18 imagery.  The email that I will be sending out to the
> > address@hidden email list and that Yuan Ho will be sending
> > out to the address@hidden email list will contain the
> > information about using adde.ucar.edu and not atm.ucar.edu, and about
> > the different ADDE dataset groups that we recommend using.
> >
> > I hope that the above was reasonably coherent and informative.  Please
> > let me know if you have any questions or comments about the above
> > as soon as you are able so that I can adjust, if necessary, the
> > information that we sent out to our email lists.
> >
> > 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: VON-803764
> > 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.
> >
> >
> >
> 
> 

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