This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Hi Frank, re: > One last question and then travel info. Ready... re: > Our university wants to put our servers on a cloud system, which will be > nice for me, since hardware maintenance will be their problem. And this > is a chance to expand our LDM data to include GOES16 when it's available > via LDM, and NexRad data which I don't get for space reasons. OK, sounds good. FYI: All GOES-16 data distributed in the GOES ReBroadcast (GRB) and in NOAAPort are already available via the LDM/IDD. In NOAAPort, GOES-16 ABI imagery are distributed as tiles that need to be stitched together to for full scenes (one can use the ldm-alchemy package of Python routines that we make available in the Unidata section of GitHub to stitch the pieces back together into full scenes). The GRB feed is also composed of tiles, but we use the CSPP GEO ingest/processing package from UW/SSEC/CIMSS to turn these into full scenes which are then made available in the SATELLITE (known as DIFAX in LDM versions previous to and including 6.13.6) data feed. re: > We run gempak on the same systems that collect data via LDM. GEMPAK does _not_ support the netCDF4/HDF5 format of the GOES-16 images as made available in the SATELLITE feed nor the tiles in the NOTHER feed that is created from NOAAPort. The Unidata-Wisconsin channel (IDD feed type UNIWISC aka MCIDAS) does provide a subset of GOES-16 images now, and will be expanded to include a lot more in the near future, and the format of the images in this feed _are_ usable by GEMPAK. re: > What amount of memory do you all recommend for this? If you are actually referring to RAM, then one must provision the machine/ virtual machine with enough RAM to be able to memory map the LDM queue and run the other kinds of tasks that a machine running the LDM normally performs (e.g., data FILEing, decoding, etc.). Depending on how much data one wants to receive, the RAM requirements should vary from about 16 GB for smaller instances to as much as 64 GB for large instances. Exactly how much you will need/want will depend on how much data you want to receive and what sorts of processing you will be doing. re: > And would a Tb of > disk storage work for carrying a week of data online? Perhaps, but this will depend on how much data you want to receive. re: > Thanks! No worries. 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: VPS-995567 Department: Support LDM 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.