Hi,

I have a fairly naive question about meshing. I'm currently experimenting with interFoam, as my problem involves simulating dripping and flow of fairly thin films of water (air is the other phase).

I've created a simple test case consisting just of a cube with edge length 10cm, and have set the gamma to 1 in a small region at the top, on one of the sides of this cube (the region is a cube of 5mm edge length). When I mesh this region using blockMesh (with 20x20x20=8000 hexahedral cells), the interFoam solution proceeds perfectly, and the results look fine. However, when I use a tetrahedral mesh for the box (I'm using tetgen at the moment, the mesh I generated was about 12000 tetrahedra from memory), the simulation seems to become unstable - the Courant number blows out to something large, and if I have adaptive time steps enabled the deltaT becomes smaller and smaller.

Does this simply mean that I'm using a bad quality mesh? Are there any tools I can use to discover what the problems are, or alternatively can anyone suggest a better meshing tool? I have run checkMesh on the triangulated mesh and its tests return OK (there are 4 severely non-orthogonal facets out of 4800, everything else was fine).

Obviously using a tetrahedral mesh for this particular example isn't important, but the geometry I'm aiming to use in the future will be triangulated data from a CAD package, so I assume I'll be unable to use blockMesh in that case.


Thanks,

Damian.

Oh, it will work - the mesh doesn't sound too bad. The point here is that default setting are made for speed and accuracy, not robustness. Therefore, you will need to adjust the fvSchemes and fvSolution and maybe the solver tolerances (time to get some CFD experience with FOAM) :-)

Off the top of my head, I would say add 1 non-orthogonal corrector and pay attention on what the solver is doing. The PISO loop should converge the pressure at least 2 orders of magnitude. Play with non-orth correctors, number of PISO correctors and max Co number.

A word of warning: the old rule of "rubbish in-rubbish out" still applies. If you've got a bad mesh you will not get a good solution. More importantly, because the solver is set up to give accurate results (and fast!) for decent meshes, you will see a performance hit bigger than in commercial codes (that's because they are set up to deal with bad meshes by default and that makes them slower). Therefore, a good mesh means a good solution AND getting it faster!

Enjoy,

Hrv