To run a simulation, Feel++ needs to work with different input datasets. Feel++ can use either a geometry file issued from CAD/CAO or directly a mesh file. A geometry/mesh file represents the domain of the study and is a requirement.
|The mesh file can potentially have a consequential size.|
A field file represents a function defined on a mesh, which is associated to the FunctionSpace concept. This files can be used in many context : restart a simulation, define an initial solution from another simulation, or in post-processing,
Configuration files are required to setup the simulation : mesh files, physical model, solution strategy, post-processing, …
|In particular, it indicates where the data are located.|
During the simulation, Feel++ produces data outputs that can be visualized with post-processing softwares and exported in different formats.
|Depending on the application, the outputs can have a consequential size!|
Feel++ can produce several kinds of databases, depending on the context (e.g. Certified Reduced Basis, POD). Once generated, these databases can be stored on a distant server or saved statically via DB dump.
A logging system monitors the execution of the simulation. This logging system helps the user determining the reason why the application might have failed. The logs are saved.
Reproducibility is an important and difficult challenge. When all data are available (inputs/ouputs), reproducing existing simulation results for verification or validation purpose means to be able to place the simulation in the same original setting (same user environment, parametrization, hardware). Often the only information available are the one described in papers. For example, readers have access to tables, plots and parameters precised in the results descriptions which may be incomplete. From the author point of view, the difficulty is to know what should or should not be presented in the paper so that user may be able to reproduce the paper main result.
Feel++ introduces a benchmark system to help users first. It allows for better catching and storing of crucial information on their applications (problem size, hardware, …), but also enable users to compare new simulation results based on existing and validated ones.
We distinguish currently several parts that will interact with storage:
The principle of the Feel++ journal is to retrieve the simulation information in order to gather it all in a unique metadata file. Two storage approaches can be considered and are detailed hereafter.
A journal file is generated at the end of the simulation or at intermediate moments based on user event (step updates).
|The journal is different from the main logging system, they serve two different purposes.|
By default, these metadata are stored in a unique JSON files (
This file is stored as part of the output and can be used to make queries.
The journal file is versioned to ensure comparison metadata compatibility
between two simulations.
Feel++ can use mongodb, a NOSQL database (weak dependency). Each generated journal file represent an entry of the mongodb database.
The checker system allows users to check some metrics in order to know whether the simulation has finished successfully or not. Hence, different norms can be verified for a set of parameters. This system needs to access a specific and known database (see Database (MongoDB) section). This can be used for example to compute convergence curves or simply verify that the result matches a previous simulation run in the exact same settings.
|This system works in conjonction with the journal system.|
Feel++ deploys its applications as containers for different dedicated softwares (docker, singularity). These applications are tested to ensure they are working. The testing system is based on CTest. Some test applications may use checker, thus requiring (local/online) database access.