[philippose]

Hello,
First and foremost, I wish you all a very Happy New Year! I hope everyone had a great year 2006, and are all looking forward to an even greater 2007 :-)!

Now for the questions.... I was trying out a moving mesh test case where a conical object moves in to reduce the effective area of an inlet system (basically a poppet valve). As my starting point, I used the movingCone case in the OpenFOAM 1.3 tutorial directory (using icoDyMFoam).

First question...am I right in assuming that in this case, the motion is implemented purely by stretching the cells rather than adding and removing layers...?

Secondly... does it make more sense to first run a steady state simulation (using say simpleFoam) of the system at the starting position, and using the results of that as the initial conditions for icoDyMFoam? Or is it ok to start the simulation directly with icoDyMFoam?

Third question.... when I run the movingCone example in the tutorials... there is a warning which comes up in the log file right in the beginning saying:

Create mesh

Selecting dynamicFvMesh dynamicMotionSolverFvMesh
--> FOAM Warning :
From function dynamicFvMesh::New(const IOobject&)
in file dynamicFvMesh/newDynamicFvMesh.C at line 90
library "libtetDecompositionMotionSolvers.so" did not introduce any new solvers

Selecting motion solver: laplaceTetDecomposition
Selecting motion diffusion: quadratic
Reading transportProperties

Reading field p

Reading field U

Reading/calculating face flux field phi

The simulation continues after that, and I dont see any problem with the mesh motion itself... is this warning critical?

The last question.... Can mesh motion via layer addition and removal be implemented in OpenFOAM 1.3 without having to write a completely new customised solver for the motion?

I would like to set up moving mesh cases for turbulent incompressible flow situations... are there any solvers which use combinations of layer additon and cell stretching which I could use as guidelines for writing my own?

Have a nice day and a good weekend!

Philippose

[hjasak]

I have implemented both automatic mesh motion and mesh layering in OpenFOAM and both work. You do not need to write any specific code, only create and use the appropriate mesh modifier. Doing turbulent incompressible is a straightforward modification on the existing solver and should work out-of-box. I believe Tommaso is already running turbulent compressible + combustion (and spray?) with topological changes executing during combustion - have a look at the SAE 2007 paper on this subject.

There's no point running a steady-state solver for the initial field - the transient solver will sort it out for you in the first time-step.

You can ignore the warning (harmless).

Hrv

[philippose]

Hello Hrv,
Thanks for the reply... that sorts out most of the questions I had.

I have read through the wiki-article on how to setup dynamic mesh cases, where you talk about the mesh modifiers... and scoured through the various threads discussing the topic. Shall look through it again in more detail.

The main thing that I couldnt figure out was, whether the mesh modifiers need to be added to the source-code of a modified solver, or whether they are all parameters which need to be specified in a dictionary such as "dynamicMeshDict", which are then picked up by the dynamic mesh solver.

I started modifying the turbFoam solver to incorporate mesh motion...I was thinking of basically adding code from icoDyMFoam into the turbFoam solver in order to make it account for mesh motion. In this case... do I need to do anything special in order to make use of layer additon/removal? For example...do I need to add code in order to create and use the mesh modifiers? Or is it all automatically taken into account based on dictionary entries?

One more thing... can the tetDecomposition motion solver be used also in these cases? And... are there any other dictionaries other than dynamicMeshDict for moving mesh cases?

Philippose

[lucchini]

Hi Philippose,
if you need to create a turbulent incompressible solver with mesh modifiers you should collect the following objects:

- a dynamic moving mesh (topoChangerFvMesh)
- a turbulence model (incompressibleTurbulenceModel)
- the governing equations for an incompressible solver + turbulence (UEqn, pEqn,...).

In my opinion the best way to do that is to take icoDyMFoam and add turbulence inside it as it happens for turbFoam.

icoDyMFoam contains the topoChangerFvMesh object which is basically a moving fvMesh with topological changes.

If you would like to add a new kind of moving mesh with topological changes (for example layer addition removal), you need to implement it by yourself and add it to the topoChangerFvMesh library.

Have a look to the mixerFvMesh and movingConeFvMesh to better understand how to add mesh modifiers and how to implment mesh motion.

Regards,

Tommaso

[philippose]

Hello Tommaso,
A Good day to you!

Thank you for those pointers. On Friday I modified the turbFoam solver to include dynamic meshes by incorporating those parts from icoDyMFoam. I havent tested the new solver yet, though it compiled without any errors.

The icoDyMFoam solver works by purely deforming the cells by moving the node points based on the parameters given in the "dynamicMeshDict" dictionary and the "motionU" file. There is no change to the number of cells in the mesh. I guess this is ok for low amplitude motion where the increased non-orthogonality and cell skewness dont significantly reduce result quality.

I am looking at hydraulic valve spools, with motion of the order of 6 to 8mm. I shall look through mixerFvMesh and movingConeFvMesh to see how these topological changes are made.

As far as I understood from the various threads in the forum, layer addition/removal and attach/detach functions are already available. Hrvoje Jasak in the previous message said that no special purpose code was required to implement these.

Anyway... shall look deeper into this matter during the course of the day.

Thanks again, and have a nice day! (I am sure there are more questions to come :-)!)

Philippose

[hjasak]

The icoDyMFoam solver works by purely deforming the cells

This is not true. icoDyMFoam will take ANY moving or topologically changing mesh, as specified in the dynamicMeshDict in the case you are running. Have a look, for example, at the mixer tutorial, where the mesh changes topologically. I am very surprised you haven't found this yet.

Hrv

[philippose]

Hello again,
I apologise for the slip up... For some reason, I hadnt looked into the mixer tutorial yet.

On the other hand... now I think I understand the whole moving mesh concept implemented in OpenFOAM... correct me if I am wrong...

Basically you need to write a customised library which is called by the general moving mesh system in OpenFOAM. This specific library defines the kind of motion and the different motion modifiers one likes to use for the case at hand.

Based on this library, you need to fill up the dynamicMeshDict with the right data.

So for the moving cone system, you use the "libtetDecompositionMotionSolvers.so" which is a library written with the mesh motion being defined by only stretching/squeezing the cells (without topological changes).

And for the mixer system, you use the "libtopoChangerFvMesh.so", which contains code for implementing the topological changes required for a sliding mesh interface...called by the specific function "mixerFvMesh".

In each case, each of those functions require a specific set of user defined parameters which come from the general purpose dictionary file "dynamicMeshDict".

So if I need to implement a specific kind of moving mesh, I need to either look around in "libtopoChangerFvMesh" to see if there already exists a function which fulfills my requirement, or extend this library, or write a new library on similar lines.

Am I right so far? If so... that feeling of enlightenment was quite nice I must say :-)!

Thanks for the help and have a great Sunday!

Philippose

[hjasak]

If you want to deal with mesh motion only, there is a general way: my automatic mesh motion solver. Here, you will use the appropriate dynamic mesh and specify the motion of the boundary points. The motion solver will then solver the motion equation (that you can control to achieve various mesh grading, mesh distortion control and similar, but this will deal with ALL forms of motion-only cases.

Sometimes it is more efficient to use a simpler method, e.g. if you've got a "box" in a mesh that moves in a known manner. In this case there is no need to solve the motion equation and there is a set of classes for "typical" cases of motion.

For topological changes, I recognise some typical cases which usually combine mesh motion and topo changes. Some of those have pre-defined (already written) mesh classes that will do the job for you with minimal interaction. For example, in order to get the mixer mesh working you need to build the mesh and identify various parts. In collaboration with Tommaso, there are such classes for various internal combustion engine types, with piston and n valves.

If there is no pre-defined mesh class that will do the job for you, you should think about your problem in a generic manner: what class of motion + topo variation does your problem belong to? can you generalise the code to handle a wide set of simulations? how will you identify various parts of the setup? etc. Once you do that, it will become clear how to put together the appropriate mesh class.

The mesh class you would end up writing is derived from thingy-mesh (cannot remember the name) and in it reside some zones, mesh topo modifiers, motions specification and similar animals. You will need to compile and link it with your executable - there is a number of ways to do so.

All lower-level functionality, including the actual execution of topo changes, mesh mapping, data transfer etc. are done automatically by the classes I have already written. Therefore, you do not need to worry about mesh ordering, cell numbering etc. in your mesh class. All that lives inside it is a combination of mesh motion and some sliding interfaces, attach/detach boundaries, layer addition/removal - all of those are already self contained functioning objects.

Hope this was helpful,

Hrv

[philippose]

Hi Hrv,
That was a cool message.... thanks a lot for taking the time to put it together :-)!

So now.... one thing I need to clarify before I jump deeper into the code.... when you mean "mesh motion".... is it basically the case where the number of cells, points and faces in the mesh remain a constant, and only a spatial rearrangement of the parts of the mesh take place? And this rearrangement is carried out by a motion solver for example like the "tetDecompositionMotionSolvers"?

And when you mean "topological changes"... is it again motion of parts of the mesh, but this time, with an actual change in the number of cells of the mesh, and with a change in the mesh connectivity too?

You mentioned that the motion solver can also control mesh grading... does this mean that in the pure "mesh motion" case too, there is a change in the mesh connectivity and number of cells?

One other doubt which popped into my head was.... I am currently using purely tetrahedral meshes (generated by Netgen)... is it possible to do layer addition/removal and attach/detach operations on such unstructured meshes? How is a "layer" defined in such cases?

I was looking through the linear valve motion class code.... and there is a threshold for the cell height before a layer is removed or added... but that would require something like hex cells with some sort of uniform structure right?

The animated examples in openFoam forum which demonstrate topological changes (such as the piston motion) were also all meshes with a uniform block structure.

The turbFoam solver modified to include mesh motion is working... do you think it will be a good idea to post it in the openFoam contributions website for others? Maybe you could test it out before its put out to the general public :-)!

In addition, sometime back I had also modified the simpleFoam solver to display the mass flow rate on patches (currently hard-coded) as part of the solver output... would it make sense to put that out for others too after making the patches selectable via a dictionary?

Have a nice week!

Philippose

[hjasak]

Correct:

- in mesh motion, the number of points, faces, cells and connectivity remains unchanged and points move

- in topo changes, connectivity changes as well.

All topo definitions are fully unstructured. If you have a full tet mesh, you can still define a surface within it by collecting some faces (and giving them orientation. Ideally, you want to scratch a surface into your space before meshing but this is not a requirement. Your surface will be made of triangles and layers will be created as triangular prisms . If you start with layer addition, nicely formed layers can later be removed with no problem.

I really have no idea what will happen if you try to do layer removal in an all-tet mesh - the operation makes no sense and you will probably end up with a mangled mesh.

You can control mesh resolution with pure mesh motion - just "squeeze" the cells towards the interesting region. Have a look at Zeljko's mesh motion pictures at the OpenFOAM training Wiki hosted by MFIX:

Training Wiki mesh pages

Enjoy,

Hrv

[philippose]

Hi,
Thanks once again for clearing up things for me! The basic concepts are crystal clear now... While scouring the net for similar topics, I found a paper written by you (Hrv) titled "Automatic mesh motion for the unstructured finite volume method".... shall look through that too for closure.

I guess I need to start looking around for free hex meshing software if I need to simulate large scale motion which would not be feasible via pure mesh deformation without topological changes.

Anyway, for starters I can live with pure mesh motion because I am currently working with a valve which has a small motion range which can be covered by mesh motion.

The only unanswered questions were regarding the modified solvers, and whether it would be useful to make it available to others.... I would love to contribute something back to the openFOAM community.

Philippose

[lr103476]

I created an 3D unstructured mesh by combining two meshes using mergeMeshes and stitchMesh. So on the interface there are some polyhedral cells.

icoFoam is working fine on this problem, but I got some problems with mesh motion. It doesn't matter which dynamicFvMesh library I use, but a segmentation error occurs. It always occurs inside:

fvMesh::movePoints(motionPtr_->newPoints());

Did anyone encounter the same problem and solved it?

Thanks, Frank

[bfa]

Hi,
the movie with the vibrating channel looks very much like something I'm trying to accomplish. I know it's quite old by now, but does anyone of you happen to have the corresponding case setup? It would be great if you could mail it to me.
Thanks in advance
Bjoern

[plmauk]

Hi,
I don't quite understand, which function has the "cellToRegion"-file in the 0-directory of the Mixer2D case. Can somebody explain that?

Thanks,
Paul.

[jaswi]

Hi Paul

could you please specify which solver you are using.
mixer2D case is being solved with icoDyMFOAM and MRFSimpleFOAM.

once I know that , i will try to answer your question

regards
Jaswi

[plmauk]

Hi, Jaswi!
I'm trying to use icoDyMFoam.

[plmauk]

And I have one more question about cellZones in the mixer2D-case (icoDyMFoam):

1
(
movingCells
{
type cellZone;
cellLabels List<label>
288
(
0
1
2
3
4
....

which sells are ment here?

Thanks,
Paul

[guido_adriaensen]

Hello Paul,

The cellZones are used to identify the part of the mesh that is moving. (movingCells) The list of cells that is described in the movingCells cellZone should correspond to the cells that are moving. For the mixer2D case that would be the cells surrounding the propeller (circle). The outerpart of the mesh with the stator is static.
I hope this answers your question.

kind regards
Guido

[plmauk]

Hello Guido,
Thank you very match, I understand.

regards,
Paul.

[plmauk]

Hello once again,
however, I need more help and I try to describe my case more detailed.
The problem looks quite similar as mixer2D-case, but with a 3D mesh, imported from Fluent. There is a cylindrical body, in the middle of this body is a bubbler located and this bubbler should make a rotatory motion. I imported the mesh without any problems, made slider-boundaries and slider-faceZones. Mesh seems to be OK.
Solving process begins, but after 3rd time-step I get following error-message :

Create mesh for time = 0

Selecting dynamicFvMesh mixerFvMesh
void mixerFvMesh::addZonesAndModifiers() : Zones and modifiers already present. Skipping.
Mixer mesh
origin: (0 0 0)
axis : (0 0 1)
rpm : 10
Reading transportProperties

Reading field p

Reading field U

Reading/calculating face flux field phi


Starting time loop

Volume: new = 1.51852e+06 old = 1.51852e+06 change = 2.23517e-08
Courant Number mean: 0 max: 0
deltaT = 0.00059952
Time = 0.00059952

Volume: new = 1.51852e+06 old = 1.51852e+06 change = 0.000251836
volume continuity errors : sum local = 0.000711521, global = -1.65836e-10
time step continuity errors : sum local = 0, global = 0, cumulative = 0
PCG: Solving for pcorr, Initial residual = 0, Final residual = 0, No Iterations 0
Courant Number mean: 0 max: 0
PBiCG: Solving for Ux, Initial residual = 1, Final residual = 1.25137e-10, No Iterations 1
PBiCG: Solving for Uy, Initial residual = 1, Final residual = 4.62183e-10, No Iterations 1
PBiCG: Solving for Uz, Initial residual = 1, Final residual = 1.44756e-10, No Iterations 1
PCG: Solving for p, Initial residual = 1, Final residual = 0.0492531, No Iterations 31
time step continuity errors : sum local = 3.36724e-24, global = -6.772e-28, cumulative = -6.772e-28
PCG: Solving for p, Initial residual = 0.999971, Final residual = 0.0467714, No Iterations 147
time step continuity errors : sum local = 1.35297e-19, global = 5.96158e-22, cumulative = 5.96157e-22
PCG: Solving for p, Initial residual = 0.0227172, Final residual = 0.00112531, No Iterations 24
time step continuity errors : sum local = 3.21139e-19, global = 8.79348e-22, cumulative = 1.47551e-21
PCG: Solving for p, Initial residual = 0.00708999, Final residual = 9.7545e-07, No Iterations 184
time step continuity errors : sum local = 2.84312e-22, global = -5.93851e-24, cumulative = 1.46957e-21
ExecutionTime = 138.22 s ClockTime = 142 s

Volume: new = 1.51852e+06 old = 1.51852e+06 change = 0
Courant Number mean: 0.000344973 max: 0.355124
deltaT = 0.000683174
Time = 0.00128269

Volume: new = 1.51852e+06 old = 1.51852e+06 change = 0.991629
volume continuity errors : sum local = 0.000632995, global = 6.53022e-07
time step continuity errors : sum local = 3.2066e-18, global = -6.76714e-24, cumulative = 1.4628e-21
PCG: Solving for pcorr, Initial residual = 1, Final residual = 0.00969254, No Iterations 95
Courant Number mean: 1.07362e-16 max: 2.05429e-13
PBiCG: Solving for Ux, Initial residual = 0.392221, Final residual = 2.5613e-06, No Iterations 1
PBiCG: Solving for Uy, Initial residual = 0.362983, Final residual = 6.821e-07, No Iterations 1
PBiCG: Solving for Uz, Initial residual = 0.506822, Final residual = 4.69415e-06, No Iterations 1
PCG: Solving for p, Initial residual = 0.0334414, Final residual = 0.00165112, No Iterations 136
time step continuity errors : sum local = 6.3177e-19, global = -8.18665e-21, cumulative = -6.72385e-21
PCG: Solving for p, Initial residual = 0.0453925, Final residual = 0.00217678, No Iterations 21
time step continuity errors : sum local = 7.53534e-19, global = -5.52678e-21, cumulative = -1.22506e-20
PCG: Solving for p, Initial residual = 0.0151796, Final residual = 0.00075518, No Iterations 39
time step continuity errors : sum local = 2.57325e-19, global = -1.49908e-20, cumulative = -2.72415e-20
PCG: Solving for p, Initial residual = 0.00816892, Final residual = 9.33806e-07, No Iterations 186
time step continuity errors : sum local = 3.17751e-22, global = -4.88335e-25, cumulative = -2.7242e-20
ExecutionTime = 272.26 s ClockTime = 280 s

Volume: new = 1.51852e+06 old = 1.51852e+06 change = 0
Courant Number mean: 0.000343934 max: 0.358919
deltaT = 0.00077803
Time = 0.00206072

Volume: new = 1.51852e+06 old = 1.51852e+06 change = 0.0145871
volume continuity errors : sum local = 0.000828983, global = 9.6061e-09
time step continuity errors : sum local = 4.20235e-19, global = -5.56138e-25, cumulative = -2.72425e-20
PCG: Solving for pcorr, Initial residual = 1, Final residual = 0.00919084, No Iterations 93
Courant Number mean: 1.27294e-17 max: 3.99054e-14
PBiCG: Solving for Ux, Initial residual = 0.926559, Final residual = 2.57888e-08, No Iterations 2
PBiCG: Solving for Uy, Initial residual = 0.891096, Final residual = 3.67632e-06, No Iterations 1
PBiCG: Solving for Uz, Initial residual = 0.963452, Final residual = 9.64084e-06, No Iterations 1
PCG: Solving for p, Initial residual = 0.0289451, Final residual = 0.00138406, No Iterations 128
time step continuity errors : sum local = 6.19434e-19, global = 5.2492e-21, cumulative = -2.19933e-20
PCG: Solving for p, Initial residual = 0.173516, Final residual = 0.00799926, No Iterations 18
time step continuity errors : sum local = 3.91987e-19, global = 2.7567e-21, cumulative = -1.92366e-20
PCG: Solving for p, Initial residual = 0.0618283, Final residual = 0.00309137, No Iterations 49
time step continuity errors : sum local = 1.295e-19, global = 1.05006e-20, cumulative = -8.73603e-21
PCG: Solving for p, Initial residual = 0.0323534, Final residual = 9.34442e-07, No Iterations 196
time step continuity errors : sum local = 3.75156e-23, global = 5.90901e-26, cumulative = -8.73597e-21
ExecutionTime = 407.2 s ClockTime = 422 s

Volume: new = 1.51852e+06 old = 1.51852e+06 change = 0
Courant Number mean: 0.000403248 max: 0.363236
deltaT = 0.000884439
Time = 0.00294516



--> FOAM FATAL ERROR : Cannot determine best atan point. Doing face: 8(683304 697284 683092 567061 683093 697285 683305 567276) Cur point: 697284 Next points: 4(683092 683304 567060 684662)

From function void enrichedPatch::calcCutFaces() const
in file slidingInterface/enrichedPatch/enrichedPatchCutFaces.C at line 277.

FOAM aborting

At the moment I have no idea, what could be wrong, maybe has somebody more experience in these cases and can give me helpful advices?

best regards,
Paul.