[kbeat]

Hey guys

I did manage to build 2D refinement for OF6, ill clean up the sources and tar the files here soon.
But there seems to significant mesh effects, in case of reactingFoam( modified to include dynamic mesh), I have tested it and the flow field changes quite a bit from non dynamic meshes.

P.S thanks Luca, the sources were quite helpful.

[openfoammaofnepo]

Dear Luca,



Thank you very much for your work. It can work very well in our case. BTW, is it possible modify the code in order to be used for 1D AMR modelling? Thanks a lot.

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

[ndtrong]

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

Dear Luca

Have you tried to compile your source with OpenFOAM v5? I would like to know the suitability of your code with OpenFOAM v5.

[openfoammaofnepo]

For the current version of AMR in openfoam, how does it deal with the parallel load balancing? Because when the mesh is refined, the number of the cells in each processor will be different. Finally, one of the processors may take longer time for each time step than others. Any comments?

Originally Posted by openfoammaofnepo

Dear Luca,



Thank you very much for your work. It can work very well in our case. BTW, is it possible modify the code in order to be used for 1D AMR modelling? Thanks a lot.

Originally Posted by 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.

[mcfdma]

Originally Posted by e1905

Hi,Moritz

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

Best
Yang

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

Did anyone manage to overcome this issue?
Thanks in advance!

[ma-tri-x]

Hello Luca!


Amazing work! Is it now inside foam-extend-4.1? Because that's what was missing the last 6 years. I tried it once myself, but didn't get far. Now my bubbles might work with AMR!! Nice! Now [two things] one thing:


- How can I cite you?


second thing was:

- Do you have an idea, why the solver complains with

[5] --> FOAM FATAL ERROR: 
[5] Number of cells in mesh:2103 does not equal size of cellLevel:12668
This might be because of a restart with inconsistent cellLevel.

when I use 2D-AMR on a snappyHexedMesh? The 12668 cells are the total amount of the cells concerning checkMesh. The 2103 cells are the ones for one processor. Why is it a problem and how can I change it?
----
I got this solved by deleting the *.gz files in the basedir/constant/polyMesh. Then The AMR takes the correct ones.



Best regards from the cavitation working group in Göttingen, Germany

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

[Luca Cornolti]

Thank you,

sharing the code was a good way to make the time I spent on it more meaningful.
Obviously, I didn't write articles about it and I don't need to be cited for this, but collaborations on modeling multiphase flows are always welcome.

The code of the dynamic mesh refinement is quite messy, it seems that it was written a lot of years ago and never updated.
In fact, the style of this code is far from the object oriented one which characterizes most of other OpenFOAM classes, I mean the hexRef8.C file has about 5400 lines!
Moreover, there were comments like "crappy way to do ..." (in the 1706 version) and some checking loops which seem redundant in my opinion.
Even Weller once answered to a request about the dynamic mesh refinement algorithm with something like: I didn't write this class, so I won't touch it.


Some months ago , the developers of foam-extend (essentially Dr. Vukčević) rewrote this part of the code completely in a more object oriented style. You can find this development in the nextRelease branch of the git repository of foam-extend 4.

I Attached an example of the setup which use this new refinement class (dynamicPolyRefinementFvMesh) for the interDyFoam solver of foam-extend.

Unlike my developments, this class is not able to handle wedge cells, but overall it is written in a much better way, as I just modified the original code instead of rewriting it as they did and it should be done. I don't known if there are also benefits with respect to the computation time, you could check and tell us.


The porting of the new developments of foam-extend to the other version of OpenFOAM is not straightforward, but it would be nice to do that and to try to extend the algorithm capability to allow mesh refinement only in the directions of high gradients instead of all directions.

Originally Posted by ma-tri-x

Hello Luca!


Amazing work! Is it now inside foam-extend-4.1? Because that's what was missing the last 6 years. I tried it once myself, but didn't get far. Now my bubbles might work with AMR!! Nice! Now [two things] one thing:


- How can I cite you?


second thing was:

- Do you have an idea, why the solver complains with

[5] --> FOAM FATAL ERROR: 
[5] Number of cells in mesh:2103 does not equal size of cellLevel:12668
This might be because of a restart with inconsistent cellLevel.

when I use 2D-AMR on a snappyHexedMesh? The 12668 cells are the total amount of the cells concerning checkMesh. The 2103 cells are the ones for one processor. Why is it a problem and how can I change it?
----
I got this solved by deleting the *.gz files in the basedir/constant/polyMesh. Then The AMR takes the correct ones.



Best regards from the cavitation working group in Göttingen, Germany

[Henning86]

Hi,


I ported the library released with the paper to v1812:

Rettenmaier, Daniel, et al. "Load balanced 2D and 3D adaptive mesh refinement in OpenFOAM." SoftwareX 10 (2019): 100317.

link:
https://www.sciencedirect.com/scienc...52711018301699


source code:
https://github.com/ElsevierSoftwareX/SOFTX_2018_143

git clone https://github.com/HenningScheufler/multiDimAMR.git


Best,


Henning

[vstron]

Originally Posted by ahmad12982

2D+axisy. dynamic mesh refinement can be found in the link below.
http://faculty.yu.edu.jo/ahmad_a/Lis.../AllItems.aspx

Hello. Any specific version of OpenFoam to be used? It doesn't compile in my Version 5.xx

[vstron]

Originally Posted by ahmad12982

2D+axisy. dynamic mesh refinement can be found in the link below.
http://faculty.yu.edu.jo/ahmad_a/Lis.../AllItems.aspx

Hello Foamers,

After spending enough time (weeks), I was able to run this code successfully. Now another issue pops up with reconstructPar and reconstructParMesh. Feeling desperate, need your help

of@of-VirtualBox:~/FOAMRUN/inject$ reconstructParMesh -latestTime -mergeTol 1e-05
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 2.1.1 |
| \\ / A nd | Web: www.OpenFOAM.org |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : 2.1.1-221db2718bbb
Exec : reconstructParMesh -latestTime -mergeTol 1e-05
Date : Jul 03 2020
Time : 16:52:55
Host : "of-VirtualBox"
PID : 2740
Case : /home/of/FOAMRUN/inject
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster
allowSystemOperations : Disallowing user-supplied system call operations

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

This is an experimental tool which tries to merge individual processor
meshes back into one master mesh. Use it if the original master mesh has
been deleted or if the processor meshes have been modified (topology change).
This tool will write the resulting mesh to a new time step and construct
xxxxProcAddressing files in the processor meshes so reconstructPar can be
used to regenerate the fields on the master mesh.

Not well tested & use at your own risk!

Merge tolerance : 1e-05
Write tolerance : 1e-06
Doing geometric matching on correct procBoundaries only.
This assumes a correct decomposition.
Found 4 processor directories

Reading database "inject/processor0"
Reading database "inject/processor1"
Reading database "inject/processor2"
Reading database "inject/processor3"
Setting master time to 0.04

Reading points from "inject/processor0" for time = 0.04

Reading points from "inject/processor1" for time = 0.04

Reading points from "inject/processor2" for time = 0.04

Reading points from "inject/processor3" for time = 0.04

Overall mesh bounding box : (0 0 -3.48955e-06) (7.99239e-05 0.00063 3.48955e-06)
Relative tolerance : 1e-05
Absolute matching distance : 6.35088e-09

Constructing empty mesh to add to.

Reading mesh to add from "inject/processor0" for time = 0.04

Adding to master mesh

#0 Foam::error:rintStack(Foam::Ostream&) in "/home/of/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#1 Foam::sigSegv::sigHandler(int) in "/home/of/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#2 in "/lib/x86_64-linux-gnu/libc.so.6"
#3 Foam::face::normal(Foam::Field<Foam::Vector<double > > const&) const in "/home/of/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#4 Foam::wedgePolyPatch::initTransforms() in "/home/of/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#5 Foam::wedgePolyPatch::wedgePolyPatch(Foam::wedgePo lyPatch const&, Foam:olyBoundaryMesh const&, int, int, int) in "/home/of/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#6 Foam::wedgePolyPatch::clone(Foam:olyBoundaryMesh const&, int, int, int) const in "/home/of/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#7 Foam:olyMeshAdder::add(Foam:olyMesh&, Foam:olyMesh const&, Foam::faceCoupleInfo const&, bool) in "/home/of/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/lib/libdynamicMesh.so"
#8
in "/home/of/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/bin/reconstructParMesh"
#9 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#10
in "/home/of/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/bin/reconstructParMesh"
Segmentation fault (core dumped)

[Henning86]

Hello. Any specific version of OpenFoam to be used? It doesn't compile in my Version 5.xx

it should work with version openfoam v1812 from openfoam.com

[Fellwalker96]

Hi,

I downloaded Henning's port of the 2D mesh refinement for openfoam v1812 but can't get it to run in parallel. Each time I run the Allrun files for the tutorials I keep on running into this error

Selecting dynamicFvMesh dynamicMultiDimRefineBalancedFvMesh
[0] 
[0] 
[0] --> FOAM FATAL IO ERROR: 
[0] Entry 'operation' not found in dictionary "/mnt/c/Users/pcygh2/Documents/OpenFoam_cases/OpenFOAM-v1812/capillaryRisePlates2D/constant/dynamicMeshDict.adaptCriteria"
[0] 
[0] file: /mnt/c/Users/pcygh2/Documents/OpenFoam_cases/OpenFOAM-v1812/capillaryRisePlates2D/constant/dynamicMeshDict.adaptCriteria
[0] 
[0]     From function bool Foam::dictionary::readEntry(const Foam::word&, T&, Foam::keyType::option, bool) const [with T = Foam::word]
[0]     in file /opt/OpenFOAM/OpenFOAM-v1812/src/OpenFOAM/lnInclude/dictionaryTemplates.C at line 201.
[0] 
FOAM parallel run exiting

By editing the dynamicMeshDict I've managed to get cases to run not in parallel but I'd really like to be able to run my cases in parallel. I'm a bit of a novice with openfoam so any help would be greatly appreciated.

cheers

[FelixFunk]

Hey,



I want to do a adaptive mesh refinement in only x and y direction. However in OpenFoam 8 the mesh will always cut in 8 peaces. I tried the code from Ajit Kumar but got the same error like dzordz:


--> FOAM FATAL ERROR:
cell 689 of level 0 does not seem to have 8 points of equal or lower level


I also tried to implement the meshRefinement2D_of6.tar.gz of Luca but didnt compile. Did someone wrote a new version for OpenFoam 8 ?


Thanks,

[Henning86]

I updated the readme of the project that explains the refinement selection.

the composedAdaptCriteria enables to combine multiple functions with logical operators e.g. and or

[bjnieuwboer]

Dear Henning,

I tried out the code and I think it is really nice development for speeding up VOF-simulations. I am experienced with openfoam, but just started out with VOF simulations and came across some issues with the multiDimAMR-code I wanted to share with you in the hope you might be able to solve them for me and the community.

1: I downloaded the master branch from your personal git: https://github.com/HenningScheufler/multiDimAMR.git to compile with openfoam 2006 patch 200727 and I got two error messages:

   dynamicMultiDimRefineFvMesh/dynamicMultiDimRefineFvMesh.C:598:46: error: ‘class Foam::HashTable<int, int, Foam::Hash<int> >::const_iterator’ has no member named ‘object’
const label oldPointi = iter.object();

   dynamicMultiDimRefineFvMesh/dynamicMultiDimRefineFvMesh.C:1290:56: error: no matching function for call to 

‘Foam::dynamicMultiDimRefineFvMesh::writeObject(Foam::IOstreamOption::streamFormat&, Foam::IOstreamOption::versionNumber&, Foam::IOstreamOption::compressionType&, const bool&) const’ dynamicFvMesh::writeObject(fmt, ver, cmp, valid)

This issue was solved when I downloaded the 2012 branch. Is this expected behavior? If so, could you change the getting started page?

2: For me the damBreak case crashed, when using the ptscotch method in the balanceParDict. As a solution I used the kahip method. For me the question rose if ptscotch works when openfoam v2012 is used. I also wondered what determines when one needs to use kahip? And why is it not the standard method if it is most stable?

3: The AMR method does work well with iso-advector as you already mentioned to openfoam in https://develop.openfoam.com/Develop.../-/issues/1955 . I hope this will be picked up quickly by the development team. Also I hope this AMR-code will be included into the openfoam distribution or the community codes. Is this something you are aiming for?

4. After running a decomposed test case, I ran into trouble reconstructing the case. As a novice in this area I hoped to find the answer in the tutorial cases, but those are not reconstructed. Would it be possible to include a reconstruction method in the tutorial cases. I found a working method at this forum: Problems with reconstructParMesh and reconstructPar in 15 . Could you incorporate that in the allrun file? Or do you have a better method that can be included?
I hope you will find my comments insightful and want to look into them.



Thank you again for sharing this with the openfoam community.

[Henning86]

Thanks for the feedback!


1. I updated the Readme


2. Openfoam is not able to handle meshes with zero cells the decompositions method sometimes if the base mesh has a low number of cells puts zero cells into a processor resulting in a crash. In my experience kahip was not so suspectible to this issue. Also the decomposition method should only affect the memory usage and speed of the simulation no its results the choice is not that important.


3. If you want to test AMR with a geometricVoF method this might be a helpful reference but it currently only works with of1812

https://arxiv.org/abs/2103.00870
https://github.com/DLR-RY/TwoPhaseFlow

AMR is a crucial technology for the simulation of multiphase flow and also has numerous other benefits. But the current release multiDimAMR is far from production ready


4. I quick workaround to the check the results is to use the "decomposed Mode" by

touch test.foam # test or some other name only .foam matters

paraview test.foam

[bjnieuwboer]

Dear Henning,


Thank you for the answers. For now, I'll stick with the standard openfoam implementation of the VOF method together with multiDimAMR. I hope that you keep on working on developing multiDimAMR to get it production ready in the future.


Bas

[Schmidtgen]

Originally Posted by Henning86

Hi,


I ported the library released with the paper to v1812:

Rettenmaier, Daniel, et al. "Load balanced 2D and 3D adaptive mesh refinement in OpenFOAM." SoftwareX 10 (2019): 100317.

link:
https://www.sciencedirect.com/scienc...52711018301699


source code:
https://github.com/ElsevierSoftwareX/SOFTX_2018_143

git clone https://github.com/HenningScheufler/multiDimAMR.git


Best,


Henning

Hi Hennig,

I tried to use your package with Openv2112. When compiling, few errors occur in hexRefNew.C. Do you plan to update your package to the latest ESI variant?

[Schmidtgen]

Update:

With Branch v2012 only the utility testUpdate is not compiled correctly. The rest works.

[giano]

Hello guys, thanks for the nice contribution. Does the code updated by Luca work also for OF7?