|
[Sponsors] |
small question about the functionalities of topological changes in OpenFoam |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
February 28, 2013, 06:42 |
small question about the functionalities of topological changes in OpenFoam
|
#1 |
Senior Member
Niels Gjoel Jacobsen
Join Date: Mar 2009
Location: Copenhagen, Denmark
Posts: 1,903
Rep Power: 37 |
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. |
|
February 28, 2013, 09:43 |
|
#2 |
Senior Member
Sandeep Menon
Join Date: Mar 2009
Location: Amherst, MA
Posts: 403
Rep Power: 25 |
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. |
|
February 28, 2013, 11:02 |
|
#3 |
Senior Member
Niels Gjoel Jacobsen
Join Date: Mar 2009
Location: Copenhagen, Denmark
Posts: 1,903
Rep Power: 37 |
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 |
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Memory protection in OpenFOAM / combinig with FORTRAN | botp | OpenFOAM Programming & Development | 2 | February 15, 2016 13:25 |
Summer School on Numerical Modelling and OpenFOAM | hjasak | OpenFOAM | 5 | October 12, 2008 14:14 |
Question on specify gcc compiler for OpenFOAM 15 | peterlai | OpenFOAM Installation | 2 | October 2, 2008 08:20 |
small question | faiz rauf | FLUENT | 3 | September 9, 2004 12:22 |
small question regarding mesh export | faiz rauf | FLUENT | 7 | August 9, 2004 13:14 |