SPEDAS Interoperability Tools and Future Development Plans

SPEDAS Interoperability Tools and Future Development Plans
Slide Note
Embed
Share

SPEDAS tools for data access and analysis discussed in the IHDEA Virtual Meeting. Learn about workflows, metadata issues, and future development plans. Discover how SPEDAS simplifies complex data processing tasks with sample workflows and GUI features. Dive into magnetic field models, data loading menus, and interactive interfaces for efficient data analysis. Get insights on using generic tools like HAPI for different data sources. Join the SPEDAS community for advanced space science research."

  • SPEDAS
  • IHDEA
  • Virtual Meeting
  • Data Analysis
  • Space Science

Uploaded on Feb 16, 2025 | 0 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.

E N D

Presentation Transcript


  1. SPEDAS Interoperability Tools and Future Development Plans IHDEA Virtual Meeting, October 2020 SPEDAS downloads, documentation, and email list: spedas.org Jim Lewis Space Sciences Lab, University of California, Berkeley jwl@ssl.berkeley.edu SPEDAS Slide 1

  2. Agenda Example workflows SPEDAS tools for CDAWeb, HAPI, DAS2 data access Metadata issues Future development plans, open questions SPEDAS Slide 2

  3. Sample SPEDAS work flow Load THEMIS satellite positions and fluxgate magnetometer data for a time range of interest Load solar wind parameters from the OMNIWeb data repository Load geomagnetic indices from the Kyoto data repository Use the solar wind parameters, geomagnetic indices, and times/locations as inputs to a magnetic field model (e.g TS07 via the GEOPACK library), to generate expected field values at the THEMIS times and positions Plot and compare the THEMIS observed fields to the modeled fields Each of these steps could be accomplished with just a few lines of IDL code, or a few clicks in the SPEDAS GUI, because SPEDAS already includes full-featured load routines for THEMIS, OMNI, Kyoto WDC, etc. But could this workflow be accomplished for a different data source (e.g. BepiColumbo flyby), using generic tools (HAPI, CDAWeb, DAS2)? reduce d SPEDAS Slide 3

  4. SPEDAS GUI data loading menu ;---------------- SPEDAS Slide 4

  5. ;---------------- SPEDAS Slide 5

  6. Magnetic Field Models The GUI is now able to: - Model the field at the spacecraft position - Trace field from position to the ionosphere and equator SPEDAS Slide 6

  7. Data Analysis Active Data Available Data Common Functions SPEDAS Slide 7

  8. CDAWeb interactive interface: ;---------------- SPEDAS Slide 8

  9. Sample HAPI code: idl/general/crib_hapi.pro: ;---------------- SPEDAS Slide 9

  10. Cassini mag data via Heliophysics API (HAPI), from idl/general/crib_hapi.pro: ;----------------- SPEDAS Slide 10

  11. Interactive HAPI load interface ;----------------- SPEDAS Slide 11

  12. THEMIS FGM data, HAPI versus CDAWeb: ;----------------- SPEDAS Slide 12

  13. DAS2 command line example (das2dlm_crib_basic_juno): ;----------------- SPEDAS Slide 13

  14. Juno spectrogram via DAS2: ;----------------- SPEDAS Slide 14

  15. Metadata handling comparison CDAWeb serves ISTP-compliant CDFs, however, some useful non-ISTP attributes may or may not be included depending on what the original data source provided. For example, COORDINATE_SYSTEM is optional, and some data sets do not specify it as a variable attribute. The user would need to manually add that information before passing it to a field model or transforming to a different choice of coordinates. HAPI (at least as implemented in SPEDAS) provides units and certain other metadata, like bin centers and boundaries, but no way to directly access other parameter attributes. The DAS2 interface control document seems to be able to accommodate arbitrary attributes attached to data quantities, but the SPEDAS development team has only worked through a few example data sets. We don t yet have a sense of what is typically available in common practice. So to answer the question of whether our desired workflow (load positions and magnetic fields; generate a model, compare to observations) can be achieved using these data access method: CDAWeb, maybe?; HAPI and DAS2, probably not without manual intervention to set at least the coordinate systems to what GEOPACK is expecting. SPEDAS Slide 15

  16. More metadata considerations Even if the necessary metadata is available, would SPEDAS necessarily know what to do with it? Consider the values one might encounter for coordinate system attributes, specifically earth-centered inertial coordinates. SPEDAS would call this system GEI . Another mission might reasonably call it ECI . MMS uses J2000 . Can they be treated as synonyms? Unfortunately, no! SPEDAS GEI system uses true of date equator & equinox, while J2000 is mean equator/equinox as of the J2000 epoch , and if you come across ECI, who knows? The SPASE model is probably the best available standard reference for these sorts of issues, and SPEDAS should probably be making more explicit use of it. If HAPI, CDAWeb, DAS2, and other access methods could be extended to provide DOIs or other unique identifier, or directly specify a URL such as an HDPE landing page, SPEDAS could very easily leverage that to supplement whatever metadata might be present in the native data stream. Even so, there are nuances that may not yet be completely captured by SPASE. One issue that came up during the BepiColumbo analysis was a discrepancy between the published THEMIS ephemeris products in GSM coordinates, and the result of converting from GEI to GSM using a different tool. It turns out that the internal tool was using the recently released IGRF-13 dipole parameters, while THEMIS was still using IGRF-12 to generate its GSM positions. SPEDAS Slide 16

Related


More Related Content