Move heat flux computation into a CHT module

precice / fenics-adapter

preCICE-adapter for the open source computing platform FEniCS

GNU Lesser General Public License v3.0

29 stars 15 forks source link

Move heat flux computation into a CHT module #3

Closed BenjaminRodenberg closed 4 years ago

BenjaminRodenberg commented 5 years ago

In the examples fenics-fenics and buoyantPimpleFoam-fenics the flux computation is basically identical, since the examples deal with identical physics.

in fenics-fenics : https://github.com/precice/tutorials/blob/master/HT/partitioned-heat/fenics-fenics/heat.py#L65
in buoyantPimpleFoam-fenics: https://github.com/precice/tutorials/blob/master/CHT/flow-over-plate/buoyantPimpleFoam-fenics/Solid/heat.py#L65

The solver uses Dirichlet BC on the whole boundary, while heat flux (Neumann BC) is computed in a post-processing step. Heat flux computation is problem dependent, but is not a required feature to solve the actual problem. We only need heat flux for coupling.

Therefore, we should move this functionality into a common CHT (Conjugate Heat Transfer) module (see OpenFOAM Adapter) to avoid code duplication and to ease reuse for coupled simulations with the same coupling physics (CHT), but a different solver (e.g. different boundary conditions, modeling...).

BenjaminRodenberg commented 5 years ago

I opened a thread here, since I am still not convinced by our current approach for computing the heat flux.

BenjaminRodenberg commented 5 years ago

In https://github.com/precice/tutorials/commit/3d836fa4b112ffe0661fba43d6f6021f62f36370 I changed the approach for heat flux computations. The approach before was less understandable and general. However, the new approach is less accurate and we cannot reach machine precision anymore (like described in https://github.com/precice/fenics-adapter/issues/13#issuecomment-443036244). The source of the error seems to be at the corners.

BenjaminRodenberg commented 5 years ago

Additionally, we have to make sure that the normal heatflux is considered. A shortcoming of the current adapter version becomes obvious, looking at this code, where the sign of the flux field has to be flipped, if we are considering the flux at the edge with normal pointing in negative direction.

MakisH commented 5 years ago

I am not sure we can avoid the minus. At the end of the day, when we couple two solvers, both have normal vectors pointing outside, so one needs to assume the flipping somewhere.

I think the best would be that we do the flipping in preCICE, e.g. using actions. In any case, we should document it everywhere.

BenjaminRodenberg commented 4 years ago

I will close this issue now, because I do not think that we can apply the design to the FEniCS adapter like for the OpenFOAM adapter. In the OpenFOAM adapter introducing modules for different physics has turned out a good decision. For the FEniCS adapter this is still not clear.

We can reopen this issue, if we have to reconsider the topic "modules" for the FEniCS adapter.