CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM Running, Solving & CFD (http://www.cfd-online.com/Forums/openfoam-solving/)
-   -   small question about the functionalities of topological changes in OpenFoam (http://www.cfd-online.com/Forums/openfoam-solving/113879-small-question-about-functionalities-topological-changes-openfoam.html)

ngj February 28, 2013 05:42

small question about the functionalities of topological changes in OpenFoam
 
Dear All,

I have a small question about the functionalities of topological changes in OpenFoam. These questions are more out of curiosity than based on actually problems, since my underlying source code would have to undergo a substantial modification to allow for topological changes, hence before undertaking this work, I would like to know a bit about the options.

My question can be nicely based on this small animation of scour under an elevated wall in front of a partial standing, free surface wave:

http://www.student.dtu.dk/~ngja/elevatedWallScour.mpg

The attention should be given to the poor mesh quality just below the vertical wall. In this case it could easily be resolved by changing the diffusivity of the mesh motion, though a great number of test cases would require some sort of topological change/re-meshing, e.g. a pipeline place with a minute gap to the bed of e.g. 0.2 mm from the bed and an expected final scour depth of say 100 mm.

My question is as follows:

Are there any methods available, which allows for the mesh lines attached to the vertical wall to slide off and fill the gap under the wall and creating new cells along the way, thus keeping a certain mesh quality? The vertical wall would potentially be replaced by a cylinder, where the mesh lines flow from above the cylinder to below in a constant attaching-detaching of lines to the cylinder surface.

In case of a positive answer, would this method also allow for the reverse operation, i.e. pushing the mesh lines onto the patch again in case the hole starts infilling for some reason.

Thank you for your attention

Niels

P.S. For those of you who are not familiar with the term, then scour is the response of a sediment bed due to the presence of a structure. Therefore, the modelling consists of a sediment transport simulation and the evaluation of the change in bed level based on the divergence of the transport field.

deepsterblue February 28, 2013 08:43

Niels,

Impressive animation! I can see how there's a potential for topological changes in your simulation.

In your case, if you prefer a hex mesh, I suppose layering would be an ideal candidate. Since you have a boundary layer next to the bottom surface, you may have to split cells based on some ratio using distance to the wall (rather than a simple 0.5) if you're looking to maintain that during the simulation.

If you're looking for a tet / tri-prism based solution, you can use dynamicTopoFvMesh (which includes some limited layering support too). The only concern to me is that mapping discontinuous volume-fraction fields is sometimes not so obvious. I'm also usually wary of VOF simulations on anything other than a hex mesh, but I may be wrong.

ngj February 28, 2013 10:02

Hi Sandeep,

Thanks for your thoughts on the possibilities. Just to recapitulate for my own sake:

dynamicTopoFvMesh only works with tetrahedra or prism if I understand you correctly, and there I should rather use it for remeshing/refinements than actual layering techniques. Correct?

I concur with respect to VOF-methods. I have hardly ever seen any methods, which gave good results on anything but hex-cells, and in my experience MULES is definitely only suited for hex-cells. I see your point on the mapping of the void fraction and in particular how to do it such that mass and momentum is preserved.

With respect to the layering, I suppose that you are referring to those methods included in the engineTopoChangerMesh? This is a good place to gain knowledge, at least to gain the needed inspiration into developing my own tailored method.

=== Conclusion ===
It is as I suspected: Many, many weeks of development ahead, if the code should be compatible with these topics - especially considering that I also have to synchronise everything between three different meshes: region0 (fvMesh), a subsetMesh of region0 (fvMesh), where the location of the interface should be fixed irrespectively of topological changes and a faMesh.

Thanks for your time,

Niels


All times are GMT -4. The time now is 21:09.