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

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

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.