AIDA, a software package for atmospheric data analysis, interpretation, and FAIR data production

Bénard, Sylvie; Piguet, Bruno; Maurel, William; Étienne, Jean-Claude; Couzinier, Jacques; Richard, Pascal; Riandet, Aurélie; Mequignon, Arnaud

doi:10.5194/egusphere-2025-6022

Preprints

https://doi.org/10.5194/egusphere-2025-6022

Preprints

07 Jan 2026

| 07 Jan 2026

Status: this preprint is open for discussion and under review for Geoscientific Instrumentation, Methods and Data Systems (GI).

AIDA, a software package for atmospheric data analysis, interpretation, and FAIR data production

Sylvie Bénard, Bruno Piguet, William Maurel, Jean-Claude Étienne, Jacques Couzinier, Pascal Richard, Aurélie Riandet, and Arnaud Mequignon

Abstract. AIDA (Analysis and Interpretation of Data from the Atmosphere) is a modular software suite for analysing time series of atmospheric measurements from ground stations, ships, aircraft, drones or other platforms. Users define processing workflows as sequences of mathematical and statistical operators selected from AIDA's library. AIDA records metadata to ensure traceability and produces validated output files (NetCDF, CSV, etc.) that follow international conventions such as CF and ACDD, supporting FAIR principles (Findability, Accessibility, Interoperability, Reuse). Outputs from research projects using AIDA have been published (e.g., (Huynh et al., 2023)). The project stores time series and their metadata together in a self-describing format called the AIDA Vector.

Originally written in C, development now uses Python 3, NetCDF4, Udunits2, Qt5/6 and related technologies. This paper describes the AIDA Vector, the data organization, the workflow, and the surrounding tools that let users integrate and visualize data at every processing stage. AIDA is suitable for anyone responsible for atmospheric measurements.

Received: 10 Dec 2025 – Discussion started: 07 Jan 2026

Publisher's note: Copernicus Publications remains neutral with regard to jurisdictional claims made in the text, published maps, institutional affiliations, or any other geographical representation in this paper. While Copernicus Publications makes every effort to include appropriate place names, the final responsibility lies with the authors. Views expressed in the text are those of the authors and do not necessarily reflect the views of the publisher.

Download & links

Sylvie Bénard, Bruno Piguet, William Maurel, Jean-Claude Étienne, Jacques Couzinier, Pascal Richard, Aurélie Riandet, and Arnaud Mequignon

Status: open (extended)

Post a comment Subscribe to comment alert

RC1:
'Comment on egusphere-2025-6022', Anonymous Referee #1, 17 Oct 2026 reply
AIDA, a software package for atmospheric data analysis, interpretation, and FAIR data production.
This paper describes a complex software package and information ecosystem for managing and manipulating several classes of observational data (ground based, airborne etc). The software itself is well described, with considerable detail. I enjoyed reading it. However, I do have one major concern about this paper - it reads like documentation, and it is not obvious to me that it belongs in the research literature, even in a journal concentrating on instrumentation and software. I will discuss that issue below, and leave it to the editor how to deal with this concern. If that issue is not a problem, I would recommend publication with minor corrections, if it is an issue, then I would recommend publication after major modifications.
Major Issue?
Is this a research article? As my summary suggests this is a good description of what is obviously a complex and useful data, software and information ecosystem. However, apart from the introduction on why it exists, and the worked example, there is very little reference to any other literature. Why does this package still exist given other packages? What does it do better than others? What others exist? How does it differ? How is the information architecture related to the architecture of others? (What is the information architecture, see question about vocabularies below.) Can the internal data architecture be described using formal methods (e.g. the Unified Modelling Language), rather than sketches with coloured boxes that need quite a lot of context to interpret (not all of which is in the paper). Is the provenance information consistent with external provenance systems (such as PROV) ...
As it stands, this reads like excellent documentation, but it is not obvious to me that anyone other than those that have built and use this tool need to read it.
To what extent this is a problem for this journal I leave to the editor. If it is a problem I would recommend a major rewrite to ensure a more standardised description of the architecture and a section putting this software in the context of other similar tools. If it is not, then I would be very happy for the paper to appear once the editor is satisfied with the responses to the following minor comments.
Minor Comments
The github link in my PDF resolves to a 404 at github. That's not acceptable, and must surely be a typo. I have not looked at any code.

When introducing the AIDA vector in section 3, an obvious question is, why is a new format needed? What is the advantage of this format over simply profiling the usage of an existing format (e.g. NetCDF or indeed CSV)? (There are a couple of possible half explanations in the text, but I think these need to be explicit).

(I am slightly concerned by the binary component being described as "the computers's memory representation of the data", that's not even close to a portable concept. Is this a portable format? What architectures does it work on? )

I am always a little concerned about calling something a self-describing format when actually one needs to read other things to interpret codes (e.g rft, or %60 ). The dependency on INI files means this isn't really fully self-describing, I would maybe call them self-contained, incorporating all the metadata necessary for management and analysis. However, this is a rather pedantic point, so if the authors want to push back, fine!

I would have thought there needs to be controlled vocabulary for the (name,english_name) pairs, in order to be able to export to CF (or any other standard). It's clear then that this system depends on more than just the software and the format, but on these vocabularies. There is not discussion of this information management in the paper, and there needs to be.

I don't really understand figure 3. Not only is there apparent duplication (I guess these are intended to be different examples, but if so, something has to change surely?), the meaning of all the relationships is not clear. I strongly recommend the authors consider recasting many of their figures using Unified Model Language concepts (activity diagrams, object-class relationships, component diagrams etc). Annoying though having to rethink/redraw those things, they then make it much easier to immediately understand the intent of the diagrams. Certainly more informative figure captions would be helpful.

On page 13 I got confused about the example. Why is there not a frequency part in the output name?

In the discussion around figure 7 I became a little confused as to how editable the are on the right is. (Which should be called "edit area" not "edition area"). Does the user edit things within the commands which are inserted using the left menu? Can they edit the entire thing (and accidentally make up non-existent commands)? (This is really interesting stuff, so just a wee bit more detail would be great.)

FIgure 10 is nice, it would be good to add a sentence explaining where the page layout is generated. I understood how each figure frame was created, but for example, how is the order and number of rows and columns per page created? I suspect the answer is trivial and only requires an additional sentence.

The genealogy is obviously an interesting thing. Could one take a provenance graph like this, and change the inputs, to get a new output? Can one replay these? Could they be exported to appear in (e.g. provenance websites)? (It's obviously fine if the intention is internal only, but the reader just wants to know.)

There is a missed opportunity in section 6 to compare AIDA functionality with the EddyPro software? Presumably AIDA could process fluxes? Or maybe not? There is clearly a validation and evaluation activity, so there must be some overlap in functionality?

Line 322. I wouldn't define AIDA as a software "workshop", maybe "ecosystem" would be a better word?

Reply
Citation: https://doi.org/10.5194/egusphere-2025-6022-RC1

Sylvie Bénard, Bruno Piguet, William Maurel, Jean-Claude Étienne, Jacques Couzinier, Pascal Richard, Aurélie Riandet, and Arnaud Mequignon

Viewed

Total article views: 2,013 (including HTML, PDF, and XML)

HTML	PDF	XML	Total	BibTeX	EndNote
1,173	724	116	2,013	133	128

HTML: 1,173
PDF: 724
XML: 116
Total: 2,013
BibTeX: 133
EndNote: 128

Views and downloads (calculated since 07 Jan 2026)

Month	HTML	PDF	XML	Total
Jan 2026	683	228	60	971
Feb 2026	101	45	19	165
Mar 2026	236	239	12	487
Apr 2026	37	50	1	88
May 2026	23	68	1	92
Jun 2026	11	12	1	24
Jul 2026	15	22	5	42
Aug 2026	10	21	3	34
Sep 2026	30	24	7	61
Oct 2026	27	15	7	49

Cumulative views and downloads (calculated since 07 Jan 2026)

Month	HTML	PDF	XML	Total
Jan 2026	683	228	60	971
Feb 2026	101	45	19	165
Mar 2026	236	239	12	487
Apr 2026	37	50	1	88
May 2026	23	68	1	92
Jun 2026	11	12	1	24
Jul 2026	15	22	5	42
Aug 2026	10	21	3	34
Sep 2026	30	24	7	61
Oct 2026	27	15	7	49

Viewed (geographical distribution)

Total article views: 1,991 (including HTML, PDF, and XML) Thereof 1,991 with geography defined and 0 with unknown origin.

Country	#	Views	%

Latest update: 19 Oct 2026

Short summary

The analysis and data-processing programs and applications for observational meteorology and environmental research that we have developed over the years now allow us to simplify and automate the analysis, processing and production of data for research. The latest developments account for the arrival of multidimensional variables from remote‑sensing instruments and include graphical interfaces to facilitate use of the tools.


Total:	0
HTML:	0
PDF:	0
XML:	0