search

precice / tutorials

Various tutorial cases for the coupling library preCICE with real solvers. These files are meant to be rendered on precice.org, so don't look at the README files here.
https://www.precice.org/
GNU Lesser General Public License v3.0
103 stars 105 forks source link

Flatten solver hierarchy for flow-over-heated-plate #136

Closed uekerman closed 3 years ago

uekerman commented 3 years ago

As part of the tutorials restructuring we want to flatten the second (solver) hierarchy. For the flow-over-heated-plate case this is non-trivial.

We currently have: https://github.com/precice/tutorials/tree/restructure/flow-over-heated-plate

- buoyantPimpleFoam-fenics
- buoyantPimpleFoam-nutils

We want instead:

- images/
- fluid-openfoam/
    - run.sh
- solid-openfoam/
    - run.sh
- solid-calculix/
    - run.sh
- solid-fenics/
    - run.sh
- solid-nutils/
    - run.sh
- precice-config.xml
- clean.sh
- README.md

For the CalculiX case see: https://github.com/precice/tutorials/pull/104 The OpenFOAM solid case needs to be ported from the OpenFOAM adapter.

Challenge: one preCICE config needs to fit all. This means dimensions="2" everywhere and the same coupling data names.

Furthermore, we should get similar physical results for all combinations.

For further conventions please copy from the turek-hron-fsi3 structure: https://github.com/precice/tutorials/tree/restructure/turek-hron-fsi3

MakisH commented 3 years ago

We also have the nearest-projection OpenFOAM-OpenFOAM cases (fluid and solid). This should probably be a different case in a separate directory flow-over-heated-plate-nearest-projection.

davidscn commented 3 years ago

Should we open a separate issue for the nearest-projection case? It is currently not part of the restructure project.

MakisH commented 3 years ago

Should we open a separate issue for the nearest-projection case? It is currently not part of the restructure project.

Good point, somehow we don't have it on the list at the moment. It needs to be in a separate directory, as the precice-config.xml will be different. Unless we decide that for any reason we don't want to keep it.

davidscn commented 3 years ago

We should definitely keep it. What I don't like about it having it as a separate case is the duplication of the case itself. I would also like to point out that the nearest-projection handling in OpenFOAM is very specific: we define separated meshes for reading and writing. So, it is rather unlikely that we will ever have a similar case added (unless we add meshes artificially).

davidscn commented 3 years ago

Closed via #154 and #159.