Skip to content

Home

Jump to bottom
alexey-petrov-occ edited this page Jun 28, 2019 · 14 revisions

Welcome to the MetaFOAM wiki!

Rational

OpenFOAM is an open source platform to build finite volume solvers. As a result, the number of solvers it supports is unlimited. As of today, there are no efficient way to build a GUI for all these solvers (including different forks and versions). Absence of freely available GUI makes OpenFOAM adoption difficult. OpenCasCade & KETEP are going to come up with a generic approach to build OpenFOAM solver's GUI. The main idea is to "extract" some kind of "meta-model" from OpenFOAM sources that could be used for GUI definition. As a result, GUI for any new solver should be extremely cheap to introduce and maintain.

Requirements

  1. It should be possible to populate the meta-model items both automatically (via corresponding scripts) and manually. This comes from the fact that some OpenFOAM entities could be difficult to formalize. Therefore, a way to incorporate manual description should be supported.
  2. It should be possible to define some meta-model items, outside of the public repository. This comes from the fact that some OpenFOAM items could be proprietary. Such proprietary descriptions need not come to the public repo and meta-model should provide a way to extend it from outside (something like a plugin system).
  3. Meta-model should simultaneously support different OpenFOAM forks and versions. As a result, once extracted, corresponding solver's GUI should be "portable" across OpenFOAM binaries.

Extraction OpenFOAM GUI meta-model from its sources

Let's describe as an example solvers that use "viscosity" model. Below it is possible to see schematically how "extraction" tools are supposed to layout their results to satisfy requirements mentioned above. foam2artefacts.plantuml Corresponding GitHub code can be found here.

OpenFOAM meta-model entities

Currently three meta-model entities are identified

  1. "Core" - represents the underlying OpenFOAM fork/version functionality. For example it describes available transport models and their grouping by categories ("viscosity", for example).
{'transport': {
       'models': [
           {'name': 'A', 'attrs': [
               {'x_attr': {'name': 'x', 'value': 1}},
               {'y_type': {'name': 'y', 'value': '1'}},
           ]},
           {'name': 'B', 'attrs': [
               {'z_attr': {'name': 'z', 'value': False}},
           ]},
           {'name': 'C', 'attrs': []},
       ],
       'categories': [
           {'name': 'K', 'models': ['A']},
           {'name': 'L', 'models': ['A', 'C']},
       ],
   }}
  1. "Solver" - refer to OpenFOAM "core" functionality solver relates on. For example, it could say that it relates on "viscosity" transport model.
{'transport': 'L'}
  1. "GUI" - details "solver" description against OpenFOAM "core" one to satisfy GUI workflow requirements (user should be able to switch between the "models" available for the given "solver" and while corresponding "model" attributes should accept and keep user input)
{'transport': {
       'category': 'L',
       'model': 'C',
       'models': [
           {'name': 'A', 'attrs': [
               {'x_attr': {'name': 'x', 'value': 22}},
               {'y_type': {'name': 'y', 'value': '111'}},
           ]},
           {'name': 'C', 'attrs': [
               {'z_attr': {'name': 'z', 'value': True}},
           ]},
       ],
   }}

artefacts2entities.plantuml

Corresponding GitHub boilerplates can be found here.

Meta-model implementation details

As it is possible to see from the requirements, it is possible to populate meta-model items manually. But we strongly encourage for automation. It will benefit the whole meta-model based GUI community in the following ways:

  1. Once formalised it could be applied to any OpenFOAM fork and version as existing as future ones;
  2. Explicitly formalised knowledge could be accumulated and reused by others;
  3. It will greatly reduce the maintenance and advancement efforts that are crucial for any open source projects.

Manual population is "acceptable" in the following cases:

  1. When it is necessary to start quickly and check feasibility of meta-model and GUI to handle your case;
  2. You don't have programming skills to put your knowledge into corresponding extractor code (ask for help);
  3. When it is difficult to formalize the extraction procedure (corresponding procedure become over complicated).

As for today, meta-model extraction tools are written using shell scripting and Linux bare commands (like grep, find and e.t.c). It is planned to keep implementation programming language agnostic so that if you are experienced in some different programming languages you will be free to use them.

GUI implementation details

GUI is supposed to be a WEB first. This design has the following benefits

  1. It will be possible to assembly and run OpenFOAM cases from any client and OS.
  2. GUI could be easily installed and run in both ways on premise and cloud.
  3. OpenFOAM developers could promote and charge for their "proprietary" solvers usage.

GUI is going to be integrated with SALOME

  • Get access and be empowered by most of the SALOME services (like meshing and modelling).

Contribution

We are inviting all interested OpenFOAMers to formalize your knowledge in the meta-model terms. In the future, meta-model could potentially play a role of a central hub for collecting, storing and ensuring it to be actual OpenFOAM knowledge. A special GitHub project is initialised (https://github.com/alexey-petrov-occ/metafoam) and ready to accept your contributions in a merge request form.

Development tips

  1. Flat is better than nested according to the Zen of Python. Let's keep the meta-model flat as long as possible. Later on, it will be much easier to build different business logic on top of the same meta-model.
  2. Keep meta-model extraction techniques programming language agnostic. Don't use file extensions for an executable script to indicate which language is used for its implementation. Use modern IDEs, like VS Code, for syntax highlighting.

Work with git

  1. git reset --soft HEAD~STEP - groups STEP commits in one.
  2. git commit
  3. git push --force

Windows and Linux line-endings

As Docker creates Linux environment it requires files to be with the end of the line (EOL) LF.
Git on Windows clones repos with EOL CRLF.
To use LF on windows go through the following steps:

  1. Set autocrlf = false in .git/config:
[core]
	autocrlf = false
  1. Remove .git/index
  2. Reset all files to LF:
git reset --hard
  1. Configure VSCode to use LF ad default:
  // The default end of line character. Use \n for LF and \r\n for CRLF.
  "files.eol": "\n",
Clone this wiki locally