@fsimonis this seems to be close to merging. Does this need more work from your side, or just a new review iteration?

edit: Actually, no. There is still a blocking modeling issue.

Just finished a co-working session with @fsimonis. I pushed some new commits, which make the custom solver work with dynamic meshes and adjusts the case to apply dynamic mesh refinement with dynamicRefineFvMesh, based on the magnitude of the gradient of the transported value.

The settings are in constant/dynamicMeshDict and are currently rather arbitrary. Next step would be to refine these. We worked with an uncoupled scalar transport case based on the pitzDaily tutorial. Here is the draft (also with arbitrary settings):

adaptivePitzDaily.tar.gz

Run with: rm -rf 0.* && blockMesh && dynamicScalarTransportFoam.

The next step would be to further understand and adjust the mesh refinement settings.

The coupled case currently fails, but this is expected since the adapter does not yet support remeshing (precice/openfoam-adapter#382). I can start an implementation of that.

The accumulation of T at the outlet remains. Making the channel longer and refining the mesh showed that the accumulation is really on the last 2-3 layers of the mesh. Changing the system/fvSchemes strongly affected the behavior (to the worse):

divSchemes
{
    default         none;
-    div(phi,T)      Gauss linearUpwind grad(T);
+    div(phi,T)      Gauss linear grad(T);
}

However, the numerics and the boundary conditions are the same as in the pitzDaily case, so this might be unrelated. I would look next if the changes from the standard scalarTransportFoam have any effect (but I would expect not).

Some URLs for reference:

• https://precice.org/couple-your-code-moving-or-changing-meshes.html
• https://api.openfoam.com/2506/classFoam_1_1dynamicRefineFvMesh.html#details
• https://openfoamwiki.net/index.php/Parameter_Definitions_-_dynamicRefineFvMesh

I got the non-AMR version running. I moved the AMR specific changes to #689 and will revert this PR to the non-AMR version.
Let's then first merge it and continue from there.

@MakisH I think I implemented all suggestions. Could you review again?

I tried setting div(phi,T) bounded Gauss upwind; in fvSchemes and it can remove the false accumulation of the scalar at the outlet both with BC advective or zeroGradient for outlet.

Thank you, @Fujikawas! I can confirm that this scheme works just fine. Here is what I get with the coarse mesh and zeroGradient:

I will then use this scheme, the coarse mesh, the simpler zeroGradient condition, I will remove the custom meshing script.

Such a simple solution and we spent hours debugging this 😂

Having the simpler mesh is actually better as it makes the base of the AMR version more realistic.

@MakisH feel free to merge