[Luca Cornolti]

In the 3D case the original hex cell is cut into 8 smaller ones, new faces, edges and points are created.
One problem is how to link all these new features together and how to keep a track of them in order to remove all of them during the unrefinement step.
The second one is how to use these information.



In 3D, for every cut cell a new point is created in its centre.

This point is shared by the 8 daughter cells.


The original 3D code employs a list of these points to get all the information related the features created during the cutting process in a cascade process.

In short: 1) this central point is shared by 6 central edges, 2) the point of the other side of these edges is in the centre of the cut faces and is shared by 3) the four created faces for each original face. 4) The vertexes of these faces are the corners of the original cell and the points in the middle of the original edges.
To reproduce this cascade process in 2D and reuse most of the functions of the original code, the main trick of my code was to replace this list of points with a list of central edges, as in 2D we cut the cell into four smaller cells which shares an edge in the centre. Then, by simply skipping the first step of the 3D cascade process, we get all the information needed in the same way.


In 1D you have fewer new features. Following the same logic, you could use a list of central faces which is formed by the four created points in the middle of the original edges.


This is just a way to link information, then you have to change all the functions which uses them. For example in 1D you cut 2 of the original faces into 2 and the new face are formed by 2 original corners and 2 created points in the middle of the original edges, while in 2D and 3D the new faces have 1 original corner and 3 created points.



In other words there is some work to do…

I saw that the main developers of foam-extend very recently worked on this topic too. From What I saw they developed a new class which is able to handle both 2D and 3D cases, but not 1D.

[Tobi]

Hi all,

interesting developments. I also build a 2D mesh refinement library but within a completely different manner. However, may I suggest you something:

• Code developments should be put on a repository for code-development-analysis as well as transparancy and accessability
• If one of you would build a 2D refinement library it would be nice to have within the official FOAM release, however, duplicating hexRef8 to hexRef2 and manipulate the corresponding lines is not the goal we should have; I totally agree that this is the most easiester way but in code maintenance not recommended
• Thanks for your contribution
• Moved the thread to the OpenFOAM contribution subforum

[e1905]

Originally Posted by MSF

Hi,

I tried to compile the library from Ahmad but I get the following error message(OF 2.2.2):

g++: error: unrecognized command line option ‘-fvMotionSolver’

Anyone an idea what that means?

Best,
Moritz

Hi,Moritz

I have the same problem with you, did you finally solve it?

Best
Yang

[Dani81]

Hi everyone,

when running blockMesh with Luca´s 2D amr code in openfoam6 I get some warnings, mostly related to issues in loading the "libdynamicFvMeshUser.so".
The code works anyway when running a case on a sigle processor.

If I run in parallel instead, it fails to reconstrucPar afterwards.
Has anyone had the same issue? And is that the case for the code in openfoam4 too?

I attach the log files for blockMesh, decomposePar and reconstructPar with the warnings I get.

Thanks in advance

[Luca Cornolti]

Originally Posted by Dani81

Hi everyone,

when running blockMesh with Luca´s 2D amr code in openfoam6 I get some warnings, mostly related to issues in loading the "libdynamicFvMeshUser.so".
The code works anyway when running a case on a sigle processor.

If I run in parallel instead, it fails to reconstrucPar afterwards.
Has anyone had the same issue? And is that the case for the code in openfoam4 too?

I attach the log files for blockMesh, decomposePar and reconstructPar with the warnings I get.

Thanks in advance

This issue is not related to the 2D code and it is not even a real problem, see for example this thread:

Reconstruction after parallel run with dynamic mesh refinement

To solve your issue just use these commands in sequence:

"reconstructParMesh" to reconstruct just the mesh
and then "reconstructPar" to reconstruct the fields.

[Dani81]

Thanks for the feedback Luca.

One more question, if I may. When running the AMR utility I notice that a mesh originally made by only hexahedra will turn into one with polyhedra. The same happens also when using the standard refineMesh utility of the OpenFOAM distribution. Do you have any hint on this?

Thanks in advance,

Daniele

[dzordz]

Hi Luca!

The code you provided compiles nicely for of6 version, but gives the following issues for ofv1806. Any idea how how to fix this?

dynamicRefineFvMesh2D/dynamicRefineFvMesh2D.C: In member function ‘virtual bool Foam::dynamicRefineFvMesh2D::writeObject(Foam::IOs treamOption::streamFormat, Foam::IOstreamOption::versionNumber, Foam::IOstreamOption::compressionType, bool) const’:
dynamicRefineFvMesh2D/dynamicRefineFvMesh2D.C:1474:32: error: no matching function for call to ‘Foam::hexRef2D::write(const bool&) const’
&& meshCutter_.write(valid)
^
In file included from dynamicRefineFvMesh2D/dynamicRefineFvMesh2D.H:83:0,
from dynamicRefineFvMesh2D/dynamicRefineFvMesh2D.C:26:
/home/user/OpenFOAM/OpenFOAM-v1806/src/dynamicMesh/lnInclude/hexRef2D.H:585:18: note: candidate: bool Foam::hexRef2D::write() const
bool write() const;
^~~~~
/home/user/OpenFOAM/OpenFOAM-v1806/src/dynamicMesh/lnInclude/hexRef2D.H:585:18: note: candidate expects 0 arguments, 1 provided
/home/user/OpenFOAM/OpenFOAM-v1806/wmake/rules/General/transform:34: recipe for target 'Make/linux64Gcc63DPInt32Opt/dynamicRefineFvMesh2D/dynamicRefineFvMesh2D.o' failed
make: *** [Make/linux64Gcc63DPInt32Opt/dynamicRefineFvMesh2D/dynamicRefineFvMesh2D.o] Error 1

Cheers.

[Luca Cornolti]

Originally Posted by dzordz

Hi Luca!

The code you provided compiles nicely for of6 version, but gives the following issues for ofv1806. Any idea how how to fix this?

dynamicRefineFvMesh2D/dynamicRefineFvMesh2D.C: In member function ‘virtual bool Foam::dynamicRefineFvMesh2D::writeObject(Foam::IOs treamOption::streamFormat, Foam::IOstreamOption::versionNumber, Foam::IOstreamOption::compressionType, bool) const’:
dynamicRefineFvMesh2D/dynamicRefineFvMesh2D.C:1474:32: error: no matching function for call to ‘Foam::hexRef2D::write(const bool&) const’
&& meshCutter_.write(valid)
^
In file included from dynamicRefineFvMesh2D/dynamicRefineFvMesh2D.H:83:0,
from dynamicRefineFvMesh2D/dynamicRefineFvMesh2D.C:26:
/home/user/OpenFOAM/OpenFOAM-v1806/src/dynamicMesh/lnInclude/hexRef2D.H:585:18: note: candidate: bool Foam::hexRef2D::write() const
bool write() const;
^~~~~
/home/user/OpenFOAM/OpenFOAM-v1806/src/dynamicMesh/lnInclude/hexRef2D.H:585:18: note: candidate expects 0 arguments, 1 provided
/home/user/OpenFOAM/OpenFOAM-v1806/wmake/rules/General/transform:34: recipe for target 'Make/linux64Gcc63DPInt32Opt/dynamicRefineFvMesh2D/dynamicRefineFvMesh2D.o' failed
make: *** [Make/linux64Gcc63DPInt32Opt/dynamicRefineFvMesh2D/dynamicRefineFvMesh2D.o] Error 1

Cheers.

I just downloaded the code and it still compiles well.
I suppose that you are not the first guy who downloaded it, but you are the first one who encountered this issue.
Are you sure than you are using the plain v1806 version and not, for example, the plus version? Maybe the developers changed something in the basic code which clashes with the library.

[dzordz]

Originally Posted by Luca Cornolti

Dear all,

after some time I was able to work again on this topic and I completed a class which is able to refine 2D cases for both planar and axis symmetric (wedge) configurations.

Attached you can find the developed classes for OpenFOAM-6, foam-extend-4.0 and OpenFOAM-v1806.

The folders are arranged to be copied into the user directory ($WM_PROJECT_USER_DIR).

In the OpenFOAM-6 version there are also two tests for planar and wedge configurations.

I tested quite extensively the foam-extend-4.0 version.
The OpenFOAM-6 version should work as well as the code is almost the same, but I tested it only with the attached two tests as I don’t use the foundation version a lot.
The same is true for the v1806 version.


I hope that everything will work properly.

Note that a problem reported previously by me in this thread regarding mapping was solved by following the suggestion given in:

mapFields major bug

Hi Luca,
the v1806 (have not tested the others) has issues with parallel run. Works up to 4 processors, anything above this numbers it just holds still at first refinement and doesn't proceed. I'm guessing its communication issue. Do you have any idea how to fix this in the code?
Cheers

[ajitkumar22]

Sharing my github repo, which builds upon Luca Cornolti's foam-extend code. Compilation instructions and a demo example is included as well.

https://github.com/krajit/dynamicRefine2DFvMesh

Thanks to Luca, Shonibare, and Ahmad for working in this area.

Feedbacks are most welcome.

Ajit Kumar,
Assistant Professor, Mathematics,
Shiv Nadar University,
India

[dzordz]

Originally Posted by ajitkumar22

Sharing my github repo, which builds upon Luca Cornolti's foam-extend code. Compilation instructions and a demo example is included as well.

https://github.com/krajit/dynamicRefine2DFvMesh

Thanks to Luca, Shonibare, and Ahmad for working in this area.

Feedbacks are most welcome.

Ajit Kumar,
Assistant Professor, Mathematics,
Shiv Nadar University,
India

Hi Ajit,
thanks for sharing the library. The tutorial works fine for me. Just to let you know that the lib doesn't work a more complex wedge geometry (while the one from Lucas does).

Lucas code works with no error, with yours the output I get at the first refinement is:
--> FOAM FATAL ERROR:
cell 3248 of level 0 does not seem to have 8 points of equal or lower level
cellPoints:8(47082 47083 47084 47085 5020 5021 5022 5023)
pointLevels:8{0}

Cheers,

[ajitkumar22]

Hi,

Thanks for trying it out. Admittedly, I did not attempt any wedge geometry.

Best,
Aijt

[kbeat]

Hey, with reference to the of6 code by Luca , I was able to build my own code. but one thing i notice with newer versions of openfoam is that the sometime the split cells end up as tetrahedrons or prisms instead of remaining a cube or in case of 2D a square

I am new to the AMR, so if you have any leads on how to conserve the square it would be a great help.

[Brandani]

Dear all,
Thank you for sharing these codes.

I managed to compile Luca's meshRefinement2D_of6.tar.gz file on OF6 and the attached dambreak cases run all good (indeed meshing dynamically).

I am trying to employ the dynamic mesh refinement for reacting flow system - i am currently attempting this on a simple reactingFoam OF tutorial: /opt/openfoam6/tutorials/combustion/reactingFoam/laminar/counterFlowFlame2D

So what I do is: I copy the dynamicMeshDict file into the constant folder and change the field of refinement from alpha.water to T and add the libs
("libdynamicFvMeshUser.so") to the controlDict file.

I run the case normally: blockmesh + reactingFoam but no mesh is getting refined (although the case itself runs fine).

Am I missing something? Could somebody please tell me how you managed to do this for a non-DamBreak case.

Thank you!

[Brandani]

Hi Luca!
Thank you for sharing these codes.

I managed to compile the meshRefinement2D_of6.tar.gz file on OF6 and the attached dambreak cases run all good (indeed meshing dynamically).

I am trying to employ the dynamic mesh refinement for reacting flow system - i am currently attempting this on a simple reactingFoam OF tutorial: /opt/openfoam6/tutorials/combustion/reactingFoam/laminar/counterFlowFlame2D

So what I do is: I copy the dynamicMeshDict file into the constant folder and change the field of refinement from alpha.water to T and add the libs
("libdynamicFvMeshUser.so") to the controlDict file.

I run the case normally: blockmesh + reactingFoam but no mesh is getting refined (although the case itself runs fine).

Am I missing something? Could somebody please tell me how you managed to do this for a non-DamBreak case.

Thank you!

[Luca Cornolti]

Dear Mark,

not all OpenFOAM solvers support dynamic mesh refinement.
In particular, I'm quite sure that reactingFoam does not.

You can check it by comparing the output of reactingFoam with the one of a solver which supports it like interFoam and see if there are the same references to the dynamic mesh refinement library (for example you should find the sentence "Selecting dynamicFvMesh ...").
Alternatively, you should check the source code of the solver (nameOfTheSolver.C) and see if the header of the dynamic mesh class "dynamicFvMesh.H" is included or not.

If not, you have to create your own solver.

This is actually quite simple, just compare the source code of two solvers: one which supports it and one which does not. Identify the lines connected to dynamicFvMesh class and add them into your solver.
Eventually, I suggest you to look at the OpenFOAM-5 realease, because that was the last release where there were two versions of the same solver, one which supports dynamic mesh refinement (labelled with ad additional DyM in the name of the solver) and one which does not. For example, you can compare interFoam and interDyMFoam.

[dzordz]

Hi,
there is a bug in the dynamicRefineFvMesh2D library (compiled with OFv1812 - I have not tested the others). More specifically while running compressibleInterFoam and refining the interface, there is nonphysical entrapment of lighter phase in the heavier one when refining. EDIT: This issue ALSO appears with dynmicRefineFvMesh (the second picture without trapped phase, gets trapped phase, but a bit later in simulation.)

To show this I attached a case (two pictures) of high speed water jet in axis-symmetrical wedge configuration (in 3D this does not happen). Only difference between the simulations are refinement libraries.This issue does not occur with the non-dynamic mesh.

Any ideas on how to fix this issue?

[Luca Cornolti]

Originally Posted by dzordz

Hi,
there is a bug in the dynamicRefineFvMesh2D library (compiled with OFv1812 - I have not tested the others). More specifically while running compressibleInterFoam and refining the interface, there is nonphysical entrapment of lighter phase in the heavier one when refining. EDIT: This issue ALSO appears with dynmicRefineFvMesh (the second picture without trapped phase, gets trapped phase, but a bit later in simulation.)

To show this I attached a case (two pictures) of high speed water jet in axis-symmetrical wedge configuration (in 3D this does not happen). Only difference between the simulations are refinement libraries.This issue does not occur with the non-dynamic mesh.

Any ideas on how to fix this issue?

I think that this issue is related to the mapping algorithm more than the dynamicRefineFvMesh class which only deals with the change of the mesh.

If you found this issue also with the standard dynamicRefineFvMesh class, you can report this to the official developer as described here:

https://www.openfoam.com/code/bug-reporting.php.


You could also check if this issue still occurs with version v1906.

[dzordz]

Originally Posted by Luca Cornolti

I think that this issue is related to the mapping algorithm more than the dynamicRefineFvMesh class which only deals with the change of the mesh.

Thank for the idea, it might be mapping indeed! I see that there has been new mapping algorithm for dynamic meshes implemented with the release of 1812. But their repository seems to be down and I am unable to find who wrote that code, to contact them.
https://www.openfoam.com/releases/op...2/numerics.php

Does the port to v1812 include this new algorithm? EDIT: it does not.

[dzordz]

I have been testing the new mapping algorithm in v1812 (in 3D refinement since 2D is unavailable) and it performs much better and eliminates this issue of air bubbles being trapped. However when looking into the source code I see that the code from Ajit is based on v1806 and does not include the new mapping. Basically it is modified Lucas code made so that it can compile on v1812. Therefore it should not state that is v1812.

Is anybody working on actually having v1812 in 2D with the new mapping algorithm?