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. |
Hi all,
interesting developments. I also build a 2D mesh refinement library but within a completely different manner. However, may I suggest you something:
|
Quote:
I have the same problem with you, did you finally solve it? Best Yang |
3 Attachment(s)
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 |
Quote:
https://www.cfd-online.com/Forums/op...efinement.html To solve your issue just use these commands in sequence: "reconstructParMesh" to reconstruct just the mesh and then "reconstructPar" to reconstruct the fields. |
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 |
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. |
Quote:
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. |
Quote:
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 |
Adaptive mesh refinement for OpenFoam-v1812
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 |
Quote:
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, |
Hi,
Thanks for trying it out. Admittedly, I did not attempt any wedge geometry. Best, Aijt |
Mesh Geometry in the OpenFoam Dynamic Mesh LIbrary
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. |
Mesh Refinement on T
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! |
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! |
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. |
2 Attachment(s)
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? |
Quote:
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. |
Quote:
https://www.openfoam.com/releases/op...2/numerics.php Does the port to v1812 include this new algorithm? EDIT: it does not. |
Followup on the air bubble issue.
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? |
2D refinement
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. |
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. Quote:
|
Quote:
Have you tried to compile your source with OpenFOAM v5? I would like to know the suitability of your code with OpenFOAM v5. |
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?
Quote:
Quote:
|
Quote:
Quote:
Did anyone manage to overcome this issue? Thanks in advance! |
supercool
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 Code:
[5] --> FOAM FATAL ERROR: ---- 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 Quote:
|
1 Attachment(s)
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. Quote:
|
2d amr
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.git clone https://github.com/HenningScheufler/multiDimAMR.git Best, Henning |
Quote:
|
Error while reconstructing (2D axisymmetric bubble rise problem)
Quote:
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::printStack(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::polyBoundaryMesh const&, int, int, int) in "/home/of/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/lib/libOpenFOAM.so" #6 Foam::wedgePolyPatch::clone(Foam::polyBoundaryMesh const&, int, int, int) const in "/home/of/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/lib/libOpenFOAM.so" #7 Foam::polyMeshAdder::add(Foam::polyMesh&, Foam::polyMesh 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) |
Quote:
it should work with version openfoam v1812 from openfoam.com |
Issue running 2d-AMR in parallel
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 Code:
Selecting dynamicFvMesh dynamicMultiDimRefineBalancedFvMesh cheers |
Code for OpenFoam 8
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, |
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 |
Personal experience twith the multiDimAMR-code
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: Code:
dynamicMultiDimRefineFvMesh/dynamicMultiDimRefineFvMesh.C:598:46: error: ‘class Foam::HashTable<int, int, Foam::Hash<int> >::const_iterator’ has no member named ‘object’ Code:
dynamicMultiDimRefineFvMesh/dynamicMultiDimRefineFvMesh.C:1290:56: error: no matching function for call to 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: https://www.cfd-online.com/Forums/op...tml#post249382 . 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. |
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 |
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 |
v2112
Quote:
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? |
multiDimAMR with OpenFOAMv2112
Update:
With Branch v2012 only the utility testUpdate is not compiled correctly. The rest works. |
Hello guys, thanks for the nice contribution. Does the code updated by Luca work also for OF7?
|
All times are GMT -4. The time now is 23:34. |