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

[McIDAS #KXA-733353]: GOES 16/17 datasets on adde.ssec.wisc.edu

Hi,

re:
> The GOES 16/17 datasets (NPGOESR, NPGOESS, RTGOESR, and RTGOESS) aren't
> working on adde.ssec.wisc.edu.  In the Satellite>Imagery chooser of both
> the IDV and McIDAS-V, these datasets are listed in the Dataset dropdown
> by default, but they error for various reasons.  For example:
> 
> adde.ssec.wisc.edu/RTGOESR/GOES 16 CONUS 0.47um:
> No images satisfy selection criteria
> 
> adde.ssec.wisc.edu/RTGOESS:
> Error at "Connect" that the dataset isn't found on the server
> 
> adde.ssec.wisc.edu/NPGOESR/GOES 16 CONUS 0.47um:
> ADIRSERV failed on exec of abisadir
> 
> adde.ssec.wisc.edu/NPGOESS/GOES 16 CONUS 0.47um:
> No images satisfy selection criteria
> 
> I think I remember in the past someone mentioning that the GOES 16/17
> datasets would be added to adde.ssec.wisc.edu.

Correct.

re:
> Is this still in the
> plans to get them added/working?

Yes, but some infrastructure things have to happen before we can start
moving the GOES-16/17 GRB L1B and/or NOAAPort-distributed L2 imagery
to unidata2-new.ssec.wisc.edu (aka adde.ssec.wisc.edu, idd.ssec.wisc.edu):

- we need to configure a machine with significant memory and horsepower
  to take over the IDD relay function that unidata2-new is currently
  providing

  This is relatively high up on our list of things to do since the
  LDM queue on unidata2-new is not large enough to hold 1 hour of
  data, and this situation would only get worse if/when we start
  sending it all of the GRB products (SATELLITE feed) and NOAAPort
  satellite products (the revamped NIMAGE feed that I sent a notice
  out about earlier this week).

- more memory is needed in unidata2-new

  Even after IDD relay duties are transferred off of unidata2-new,
  we still need RAM to unidata2-new.  The reason is the same as
  the first bullet above - the LDM queue is not large enough
  to hold enough data (e.g., 1 hour) so that duplicate products
  received will be rejected.

re:
> I see they aren't listed on the
> Unidata ADDE Servers page
> <https://www.unidata.ucar.edu/software/mcidas/adde_servers.html>.

Correct, they are not listed because the data is not there... yet.

re:
> If
> they will be added, is there a rough timeline of when this would be
> done?

Sometime this summer, hopefully sooner than later.

re:
> We currently default to using adde.ssec.wisc.edu in McIDAS-V and
> we can change to adde.ucar.edu it this won't be done relatively soon.

When updating the set of ADDE servers in McV, I strongly suggest also
adding lead.unidata.ucar.edu.  I try to keep the datasets served by
ADDE on adde.ucar.edu and lead.unidata.ucar.edu in lock step.


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: KXA-733353
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.