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