Welcome back to AWIPS Tips! Today we’re going to go over a brief overview of the backend component of AWIPS: EDEX. EDEX is the Environmental Data Exchange system that comprises the server side of AWIPS; it handles functions such as requesting raw data, decoding and ingesting data, storing processed data, and dealing with data requests from CAVE and python-awips connections. All data accessed from CAVE and python-awips comes directly from an EDEX server. It is only supported for Red Hat Enterprise Linux (RHEL) and CentOS Linux operating systems. It requires administrative privileges to make root-level changes, and can run on a single machine, or be spread across multiple machines in a Distributed EDEX set up.
Typically, Unidata’s EDEX server (which can be accessed by pointing CAVE to edex-cloud.unidata.ucar.edu) should be able to serve most of your needs. If you have specific data or additional data that we don’t currently serve, then it might be helpful to set up and run your own EDEX.
EDEX has several main components: LDM, Qpid, PostgreSQL, HDF5, and PyPIES.
LDM: The Local Data Manager (LDM) is a piece of Unidata supported software that is used for data distribution. Additionally the AWIPS LDM makes use of another key piece of software (edexBridge) to notify EDEX when data is ready for ingest.
Qpid: Apache Queue Processor Interface Daemon (Qpid) is the messaging system used by AWIPS to communicate with the EDEX server and CAVE client.
PostgreSQL: PostgreSQL (postgres) is the database AWIPS uses to handle the storage and retrieval of metadata, database tables and some decoded data.
HDF5: The Hierarchical Data Format (v. 5) (HDF5) is the decoded data format that all processed data from EDEX are stored in.
PyPIES: Python Process Isolated Enhanced Storage (PyPIES) was created for AWIPS to facilitate data storage. PyPIES handles the reads and writes of data in the HDF5 files.
In addition to all these external tools working together as part of EDEX, the server itself has multiple “modes” that it can run either individually or simultaneously. The three most common modes are: ingest, ingestGrib, and request.
ingest: This mode handles the decoding, processing, and storing of almost all data types.
ingestGrib: This mode handles the decoding, processing and storing of grib data types, such as model data, MRMS data, and model sounding data.
request: This mode handles the data requests coming from the connected CAVE (and python-awips) clients. If this mode is not running, CAVE (and python-awips) clients will not be able to connect to the EDEX server.
NOTE: There are other, simpler modes you can run if you’d just like to ingest very specific data.
A single EDEX system would consist of one machine running all the components mentioned above. It could be described like this:
Here at Unidata, because we process and serve so much data, we have actually divided some of the ingest and decoding work between two machines. We have a main EDEX machine that looks very similar to the schematic for the single machine EDEX shown above, and then we have an additional ancillary EDEX machine that is solely responsible for receiving and decoding radar data. The radar EDEX machine then takes the final, processed data and sends it back to the main EDEX machine for storing and serving for the request process. It looks something like this:
If you are interested in learning more about using or administering your own EDEX, check out the EDEX Installation Guide and EDEX User Manual for more info. AWIPS Tips will be back in two weeks with an introduction to the Points and Baselines tools.
To view archived blogs, visit the AWIPS Tips blog tag, and get notified of the latest updates from the AWIPS team by signing up for the AWIPS mailing list. Questions or suggestions for the team on future topics? Let us know at support-awips@unidata.ucar.edu
This blog was posted in reference to v18.2.1-1 of NSF Unidata AWIPS
