the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
| 27 Aug 2024
Alquimia v1.0: A generic interface to biogeochemical codes – A tool for interoperable development, prototyping and benchmarking for multiphysics simulators
Abstract. We present Alquimia v1.0, a generic interface to geochemical solvers that facilitates development of multiphysics simulators by enabling code coupling, prototyping and benchmarking. The interface enforces a call signature for setting up, solving, serving up output data, and other common auxiliary tasks, while providing a set of structures for data transfer between the multiphysics code driving the simulation and the geochemical solver. Alquimia relies on a single-cell approach that permits operator splitting coupling and parallel computation. We describe the implementation in Alquimia of two widely-used open-source codes that perform geochemical calculations, PFLOTRAN and CrunchFlow. We then exemplify its use for the implementation and simulation of reactive transport in porous media by two open-source flow and transport simulators, Amanzi and Parflow. We also demonstrate its use for the simulation of coupled processes in novel multiphysics applications including the effect of multiphase flow on reaction rates at the pore scale with openFOAM, the role of complex biogeochemical processes in land surface models such as the E3SM Land Model (ELM), and the impact of surface-subsurface hydrological interactions on hydrogeochemical export from watersheds with the Advanced Terrestrial Simulator (ATS). These applications make it apparent that the availability of a well-defined yet flexible interface has the potential to improve the software development workflow, freeing up resources to focus on advances in process models and mechanistic understanding of coupled problems.
- Preprint
(8720 KB) - Metadata XML
- BibTeX
- EndNote
Status: final response (author comments only)
-
RC1: 'Comment on gmd-2024-108', Anonymous Referee #1, 11 Nov 2024
This is a long-awaited publication - the Alquimia was released on github in 2013 and since then used in several DOE and other funded projects. The main purpose of Alquimia interface is to provide a seamless coupling between different multiphysics simulators and different chemical speciation solvers. For this, Alquimia offers a number of C data structures and API calls, sufficient for combining at least the codes written in C, C++ and Fortran. A partial Python API is also available. In principle, an Alquimia interface module needs to be created for each multiphysics code and each chemical speciation code. Currently, only CrunchFlow and ℗FLOTRAN chemical speciation solvers can be connected. A particular strength of this paper is that the concepts of Alquimia are explained on several examples, from typical reactive transport up to land surface hydro-biogeochemical models. The latter couplings actually broaden the context of coupled simulations and corroborate the innovativeness of the concept and approach behind Alquimia. Overall, Alquimia - the generic interface for coupling multiphysics with geochemical codes - marks a milestone and outlines state of the art, while showing a lot of potential for future extensions e.g. with more chemical speciation solvers. This is why the work presented by S. Molins and colleagues deserves the top mark in any sense. The attached pdf contains technical comments that, if the authors choose to implement, may improve the overall quality and impact of the paper.
-
RC2: 'Comment on gmd-2024-108', Anonymous Referee #2, 03 Feb 2025
This excellent paper introduces Alquimia, a software serving as
generic coupling interface to facilitate the coupling of geochemical
simulators codes into multi-physics frameworks.The authors start by describing the software landscape of reactive
transport models (RTM), including a formulation of the governing
equations for geochemistry (in terms of primary species, with
secondary species linked to them by means of mass action laws). The
role of the alquimia library is to sit between the "driver" and the
"engine". The driver is the transport code which sets up the spatial
discretization and defines the processes that are simulated; the
engine is the goechemical solver. The user needs to implement both the
alquimia-interface for the driver and the engine interface; the latter
is conveniently driver-agnostic, meaning that once an
alquimia-interface for the geochemical engine is available, it can be
reused by any driver.Alquimia itself is developed in C for maximum portability and its API
can be easily called by C/C++ and fortran, qhich are the most common
languages used to develop multiphysics applications and RTM in
general.Section 4 continues with implementation examples from already
developed interfaces in case of engines PFLOTRAN and CrunchFlow, which
are inherently different in terms of expected data structures and
auxiliary variables, highlighting the flexibility and added value in
terms of maintainability and extendability provided by the alquimia
approach. Notably, examples of coupling code dealing with adaptive
grid refinement and with different modi for the same driver (amanzi,
structured grids or unstructured grids) are provided and discussed to
explain important design choices for alquimia.Finally, section 4.3 presents results of 8 different combinations of
drivers and engines for the same problems, highlighting the fact that
once the alquimia interfaces are implemented, the user can
transparently test different codes and gauge the differences in
results due to the different numerical schemes for transport and the
actual engines.Section 5 presents further high-level use case for alquimia,
pertaining the coupling of geochemical engines to unconventional
reactive transport models, showcasing the ease of prototyping such a
coupling using the alquimia framework, notably using two different
engines in different domain regions in the ATS simulation.Finally the paper closes discussing current limitations and future
work.
The paper is excellent and the presented software innovative and I
have just minor comments for the authors:- It is correctly stated that chemistry is embarassingly parallel and
that alquimia is designed with a "single cell" approach which makes
it possible to flexibly deal with hardware resources, however no
further comment nor code example is given in the paper about it. I
would like the authors to elaborate on this aspect since it is in my
opinion crucial in the scope of RTM.Is the parallelization strategy completely determined by the driver
(e.g., reusing domain partitions as the AMR example of code listing
n. 4 seems to implicitely suggest) or does alquimia explicitely
allow to introduce ad-hoc parallelization schemes for the
goechemical engine in the coupling interface? As an exemplary use
case, the driver (transport code) would use N domain partitions on N
CPUs to solve flow and transport, but chemistry could be solved on M
> N CPUs since linear scaling is expected for geochemistry. Could
for example a round robin parallelization independent on the one
used in the transport code be implemented at the alquimia level, as
e.g. implemented by https://doi.org/10.5194/gmd-14-7391-2021 ?- Formal references to eqs solved by alquimia and geochemical engine
respectively are to be checked: sometimes (5-7), e.g., lines 114,
117, but often (8-5), e.g. lines 140, 142. Please carefully review
these references to avoid confusion.Citation: https://doi.org/10.5194/gmd-2024-108-RC2
Model code and software
Alquimia: A generic interface to biogeochemical codes– A tool for interoperable development, prototyping and benchmarking for multiphysics simulators Sergi Molins, Benjamin J. Andre, Jeffrey N. Johnson, Glenn E. Hammond, Benjamin N. Sulman, Konstantin Lipnikov, Marcus S. Day, James J. Beisman, Daniil Svyatsky, Hang Deng, Peter C. Lichtner, Carl I. Steefel, and J. David Moulton https://doi.org/10.5281/zenodo.11414441
Viewed
| HTML | XML | Total | BibTeX | EndNote | |
|---|---|---|---|---|---|
| 251 | 103 | 13 | 367 | 19 | 12 |
- HTML: 251
- PDF: 103
- XML: 13
- Total: 367
- BibTeX: 19
- EndNote: 12
Viewed (geographical distribution)
| Country | # | Views | % |
|---|
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1