Description

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.

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, …​

During the simulation, Feel++ produces data outputs that can be visualized with post-processing softwares and exported in different formats.

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.

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.

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.

Most Feel++ documentation is generated using the asiidoc format. Antora is used to generate the documentation docs.feelpp.org. The man pages are automatically generated in the same format and detail each application usage. The documentation is automatically generated and deployed on an web server.