Multi-Physics Toolboxes Contribution Guide
In the spirit of free software, everyone is encouraged to help improve our Multi-Physics toolboxes. New contributors are always welcome! Here, we discuss the different ways to contribute to Feel++ multiphysics toolboxes. You can contribute
We start first with explaining the difference between an example and a benchmark.
A benchmark is essentially an example which contains data that allows to either:
verify that the model(the equation set) was solved correctly, this is called verification. Synthetic data is provided to make the verification or data provived by another software
verify that the model solved is the correct one, this is called validation. Experimental data is provided to make the validation or data provided by another software which have been validated.
verify that the performance of the model scale properly, this includes weak and strong scalability benchmarking.
Anyone can propose or suggest a new example to be added to the Feel++ toolbox repository. To do so, start a new issue and select the Example Request template. You just then have to fill out the example or benchmark request.
|The answers provided can, almost directly, be used to document the case documentation file.|
To contribute a case description, you need to follow the steps:
But first you need to understand the file organization of the examples and benchmarks directory tree.
|It is important that you read Antora File Organization section before continuing.|
This is how the
examples tree directory may look like
examples └── modules ├── ROOT │ └── pages ├── cfd (1) │ ├── examples (2) │ │ ├── cyclone │ │ │ └── attic │ │ └── flow_past_cylinder (3) │ └── pages (4) │ └── flow_past_cylinder └── csm (5) ├── assets (6) │ └── images (7) │ ├── ribs (8) │ ├── rotating-winch (8) │ ├── sensor (8) │ ├── sheet-rounding (8) │ ├── suspension (8) │ ├── t-beam (8) │ ├── torsion-bar (8) │ └── vierendeel-truss (8) └── pages (4) ├── ribs (9) ├── rotating-winch (9) ├── sensor (9) ├── sheet-rounding (9) ├── suspension (9) ├── t-beam (9) ├── torsion-bar (9) └── vierendeel-truss (9)
|1||example module for the computational fluid dynamic (cfd) toolbox|
|5||example module for the computational solid mechanics (csm) toolbox|
|8||the images of each example are organized by directory named using the slug name of the example,|
|9||each example documentation is located in a topic directory named using the slug name of the example. The topic directory contains
the slug name of a
You need to identify which toolbox the example belongs to. here is the list of slug toolbox name:
The example is then located in the model named after The slug name of the toolbox:
examples/modules/<slug toolbox name>
Follow the steps to setup the documentation:
create a branch
#nnis the corresponding issue number in github
<shortname>is the code name of the case
<toolbox shortname>is the code name of the toolbox used, it is optional
<latest version>meaning the latest version number upon which we build the documentation, e.g
0.105. The work done in the branch will appear in the documentation under development.
here is an example
create a topic in `[examples]/modules/<toolbox>/pages/<short name>/README.adoc
start filling up
README.adocusing the case template file.
Follow this step :
create the geometry (e.g.
cases/modules/<slug toolbox name>/examples/<slug case name>/
The input files for the example
Once the test case description and implementation are done, there remains to document the numerical results obtained with Feel++. This step may require
generating images (
.pngformat) using e.g. Paraview to show the mesh and fields
generating Vtkjs files to have 3D interactive models embedded in the browser to show the mesh and fields
generating Plot.ly interactive graphics embedded in the browser to show 2D data, convergence plots, …
The generation of Vtkjs files is now preferred as it permits interaction. Have a look at the examples in computational solid mechanics providing both images and Vtkjs files.
The image files for the example
Once you have started working and committing to Github, propose a pull request (PR) for merging into the master branch.