[philippose]

Good day to everyone :-)!

Its been a while now since my last post, though as usual, I have been keeping track of the proceedings from a passive standpoint....

Anyway, I have a quick question regarding the basic mesh motion capability in OpenFOAM 1.4.1-dev (SVN)..

I have a mesh which consists of two completely separate parts which are not in contact with each other...but...all in one mesh description (no subset meshes... just one set of "owner", "neighbour", "faces", "points" files...)

All the boundary faces on one separate part have one patch name, and all the boundary faces on the other part have another patch name.

Using the "motionU" file, I specified a constant velocity for one of those "pieces", and using the tetdecomposition motion solver, tried to move the mesh with the "moveMesh" application...

The application runs without any warnings or errors, but the part of the mesh which was given a fixed velocity, does not move at all...

In Paraview I can see that the velocity of the boundary of the part has been set, but the "points" file for each time step are exactly the same... the mesh does not move...

Is this something I am doing wrong... or is this a limitation? And how does one normally go about simulating a situation where there are two separate parts to a geometry?

As additional info... if the independent part which is supposed to move does move... after a specific distance, it will intersect with the stationary part to form a continuous fluid path (basically a valve spool :-)!)

I guess the basic question would be... how does one use the sliding interface when the two sliding parts are initially completely separated from each other ?

Hoping to see a reply....

Have a nice day...:-)!

Philippose

[jaswi]

Hi Philippose

Nice to have you back :-)

I was about to write you an email and here you are.
The problem is interesting but i do not understand the complete setup. If you have no apprehensions about the case setup then please do mail the case to me. I would like to spend some time on it. It seems to be a good case to test my understanding of dynamic mesh setup ;-).

Best Regards
Jaswi

[philippose]

Hello again,

For more clarity, here are a couple of images of the geometry I am refering to...





As can be seen... in the beginning, the spool is completely closed... in that... there is no continuous fluid path, and the mesh consists of two completely separated parts....

Now.. I want to use this separated mesh along with a sliding interface setup, to reach the situation as shown in the second image (img02.jpg) by slowly axially moving the central region into the outer ring region...

But the problem I am facing is, that when the mesh is as shown in the first image (as two separate parts in one mesh file), the mesh motion does not work...


Have a nice day!

Philippose

[jaswi]

Hi Philippose

That's much better now to understand what exactly is required. As far as my understanding goes this case has two mesh modifiers

-sliding mesh for moving the central region into the outer ring region
- once it has reached the required position , then use the attach-detach mesh modifier(the situation becomes similar to the T-juntion)

For this case it seems that the two mesh modifiers have to be combined together. First the sliding mesh will move the central part axially and once a particular criterion is met then trigger the second mesh-modifier namely the attach-detach.

What I am still unable to understand is how to execute the sliding-mesh as you have mentioned in the first post that the sliding surface are apart.
Is it possible to zoom into the marked region and post some pics form another perspective so that one could see the patches which are to be slided against each other.

Best Regards
Jaswi

[philippose]

Hello and a good evening :-)!

Before we jump into the actual sliding interface, and how to attach detach the surface, the main issue has to be addressed and solved....

To make it clear....

1. I started with a mesh of the geometry shown in figure 1 above.... basically, I used "netgen" to create a 100% tetrahedral mesh, and then imported it to OpenFOAM.

2. When checkMesh is run on this mesh, two mesh regions are reported (as expected), and checkMesh creates a file called "cellToRegion" in the "<case>/constant" folder...

3. For test purposes, there are only two patches for the entire mesh.... assume... "patchStatic" and "patchMoving"....

All the boundary faces of the outer ring and the rest of the geometry connected to it is assigned to "patchStatic"

All the boundary faces of the inner cylinder, and the negatives of each of the holes are assigned to "patchMoving"

4. Now, I set up a completely normal moving mesh case, with a file called "motionU" in the "<case>/0" folder, and a "dynamicMeshDict" file in the "<case>/constant" folder....

In the "motionU" file, I supply a fixed velocity to the patch - "patchMoving" in the axial direction (which in this case is -z)

In the "dynamicMeshDict" file, I use the following settings:

......dynamicFvMesh dynamicMotionSolverFvMesh;

......solver laplaceFaceDecomposition;

5. Once this is done, I use the "moveMesh" utility, to check the motion of the mesh so far...


Now comes the issue..... though there is a velocity specified to the entire "patchMoving" part, even after a relatively long simulation time, there is no movement of the mesh....

I checked the "points" files which gets written at each time step, and found that there are no differences between time steps....

When I check the velocity of the "patchMoving" patches, it shows me the expected velocity...


Now for the finale.... Using exactly the same settings, I created a case using the geometry shown in figure 2.... in this case, the mesh is only one continuous region since one of the "holes" are already within the ring geometry creating a fluid path....

In this case.... the mesh motion works fine...


So my question is.... is this phenomenon we are seeing here a limitation of the mesh motion system, or is it just that I am handling this scenario in a wrong manner....? If I am doing something wrong, it would be wonderful to get some kind of feedback.....

If this is a limitation, then how do I approach such situations with OpenFOAM ?

Have a wonderful weekend.... :-)!

Philippose

[hjasak]

Hi Philiposse,

I see no problem with what you are trying to do. In fact Tommaso is doing approximately the same thing when he does 2-stroke internal combustion engines using OpenFOAM, so I know this works fine.

Moving the bits:

There is no limitation or anything like that. Make sure your boundary conditions are correct, your motion solver gets called (do you see the solution + residuals) and that you move the mesh properly afterwards. I have done this a thousand times, without trouble

Sliding interface:

The way i implemented the sliding interface algorithm in OpenFOAM allows no overlap or partial overlap. The faces that are covered end up as internal faces n the mesh, while the rest that remains uncovered will end up in a patch (one for each side) for which you cn define the boundary condition. Therefore, when the 2 bits are uncovered, you will presumably have a wall b.c., and once they cover each other they will be connected.

Hope this helps,

Hrv

[philippose]

Hello Hrv,

A Good Morning to you :-)!

Sorry for the delay in my reply... was on a short holiday... so back in action now :-)!

I was (and still am) convinced that there are no limitations for multiple mesh regions in the mesh motion libraries... which was why I was quite surprised and rushed to the forum to post a message regarding it :-)!

Shall look through the whole case setup again today and see if I can find something wrong with the configuration and the boundary conditions...

As for the sliding interface bit..... I was thinking of using the "linearValveFvMesh" library, which seems to be able to automatically handle the sliding interface as well as the complete "attach-detach" system required in this situation.

As you mentioned, the two uncovered bits do have a "wall" boundary condition, and once they cover, I want all the overlapping and partially overlapping parts to be converted to internal faces (nothing exotic...)

But... before checking out the sliding interface, I need to see why the mesh doesn't move in the first place :-)!

Shall get back on this as soon as possible...

Have a nice day!

Philippose

[philippose]

Hello yet again,

I have been trying to sort out the problem for the past couple of hours, but haven't succeeded yet... for more clarity, here are snippets of important files and logs:

** OpenFOAM Version: 1.4.1-dev (SVN)
** Application used: moveMesh

** contents of checkMesh log:
Create polyMesh for time = constant

Time = constant

Mesh stats
points: 61527
edges: 378229
faces: 611506
internal faces: 567706
cells: 294803
boundary patches: 6
point zones: 0
face zones: 0
cell zones: 0

Number of cells of each type:
hexahedra: 0
prisms: 0
wedges: 0
pyramids: 0
tet wedges: 0
tetrahedra: 294803
polyhedra: 0

Checking topology...
Boundary definition OK.
Point usage OK.
Upper triangular ordering OK.
Topological cell zip-up check OK.
Face vertices OK.
Face-face connectivity OK.
*Number of regions: 2
The mesh has multiple regions which are not connected by any face.
<<Writing region information to "constant/cellToRegion"

Checking patch topology for multiply connected surfaces ...
Patch Faces Points Surface
fixedWalls 19147 9742 ok (not multiply connected)
inlet 924 500 ok (not multiply connected)
outlet 840 455 ok (not multiply connected)
insideSlider 404 282 ok (not multiply connected)
outsideSlider 4501 2383 ok (not multiply connected)
spool 17984 9091 ok (not multiply connected)

Checking geometry...
Boundary openness (1.2283e-20 -2.34141e-19 -3.64842e-19) Threshold = 1e-06 OK.
This is a 3-D mesh
Domain bounding box: (-21 -15 993.9) (21 34.25 1038.2)
Max cell openness = 1.61443e-16 OK.
Max aspect ratio = 8.7318 OK.
Minumum face area = 0.00712188. Maximum face area = 1.28015. Face area magnitudes OK.
Min volume = 0.000402903. Max volume = 0.46229. Total volume = 21761.7. Cell volumes OK.
Mesh non-orthogonality Max: 68.1677 average: 20.8648 Threshold = 70
Non-orthogonality check OK.
Face pyramids OK.
Max skewness = 0.870358 OK.
Min/max edge length = 0.112805 1.96145 OK.
All angles in faces OK.
All face flatness OK.

Mesh OK.

End


** Contents of dynamicMeshDict:
{
...motionSolverLibs ("libfaceDecompositionMotionSolver.so")

...twoDMotion no;

...solver laplaceFaceDecomposition;

...diffusivity uniform;

...frozenDiffusion on;
}


** contents of boundary file:
2
(
patchStatic
{
....type wall;
....nFaces 24572;
....startFace 567706;
}

patchMoving
{
....type wall;
....nFaces 19228;
....startFace 592278;
}
)


** contents of motionU file:
dimensions [0 1 -1 0 0 0 0];

internalField uniform (0 0 0);

boundaryField
{
....patchStatic
....{
........type fixedValue;
........value uniform (0 0 0);
....}
....patchMoving
....{
........type fixedValue;
........value uniform (0 0 -0.001);
....}
}


** contents of log file on running moveMesh:
Create mesh for time = 0

Selecting motion solver: laplaceFaceDecomposition
Selecting motion diffusivity: uniform
Time = 0.001
PCG: Solving for motionUx, Initial residual = 0, Final residual = 0, No Iterations 0
PCG: Solving for motionUy, Initial residual = 0, Final residual = 0, No Iterations 0
PCG: Solving for motionUz, Initial residual = 0.343301, Final residual = 8.93302e-11, No Iterations 184
PCG: Solving for motionUx, Initial residual = 0, Final residual = 0, No Iterations 0
PCG: Solving for motionUy, Initial residual = 0, Final residual = 0, No Iterations 0
PCG: Solving for motionUz, Initial residual = 5.45762e-11, Final residual = 5.45762e-11, No Iterations 0
ExecutionTime = 199.37 s ClockTime = 216 s

Time = 0.002
PCG: Solving for motionUx, Initial residual = 0, Final residual = 0, No Iterations 0
PCG: Solving for motionUy, Initial residual = 0, Final residual = 0, No Iterations 0
PCG: Solving for motionUz, Initial residual = 5.45762e-11, Final residual = 5.45762e-11, No Iterations 0
ExecutionTime = 216.33 s ClockTime = 234 s

Time = 0.003
PCG: Solving for motionUx, Initial residual = 0, Final residual = 0, No Iterations 0
PCG: Solving for motionUy, Initial residual = 0, Final residual = 0, No Iterations 0
PCG: Solving for motionUz, Initial residual = 5.45762e-11, Final residual = 5.45762e-11, No Iterations 0
ExecutionTime = 233.26 s ClockTime = 252 s

Time = 0.004
PCG: Solving for motionUx, Initial residual = 0, Final residual = 0, No Iterations 0
PCG: Solving for motionUy, Initial residual = 0, Final residual = 0, No Iterations 0
PCG: Solving for motionUz, Initial residual = 5.45762e-11, Final residual = 5.45762e-11, No Iterations 0
ExecutionTime = 250.21 s ClockTime = 270 s

Time = 0.005
PCG: Solving for motionUx, Initial residual = 0, Final residual = 0, No Iterations 0
PCG: Solving for motionUy, Initial residual = 0, Final residual = 0, No Iterations 0
PCG: Solving for motionUz, Initial residual = 5.45762e-11, Final residual = 5.45762e-11, No Iterations 0
ExecutionTime = 267.12 s ClockTime = 288 s


** Now, when I check the difference between the contents of the "points" file which is written in the time-step 0.001 and the one in time-step 0.005, I see:

16c16
< instance "0.001";
---
> instance "0.005";


So basically, all the point co-ordinates have remained exactly the same between the time steps.

When I look into the "motionU" file for time-step 0.005, I find that there are many points within the "internalField" which have a velocity vector (0 0 -0.001)

There are also many entries in the "meshPhi" file which are non-zero.

However, since the "points" files are completely identical, there is no actual motion of the moving part of the mesh "patchMoving"....

Moreover, after the first iteration, it can be seen that the number of sub-iterations for the "motionUz" solver goes down to zero...

any ideas what I might be doing wrong here?? I am more or less completely out of ideas....

Have a nice Afternoon :-)!

Philippose

[philippose]

Hello and a very good evening :-)!

Ok :-)! I think I solved the problem.... and... I am finding it very difficult to look up out of sheer embarrassment :-)!

It looks like the issue was, that I had forgotten to run a "transformPoints" on the mesh to convert from millimetre to metre... should have seen it from the output of "checkMesh", but well :-)!

So basically I was moving with a velocity of 1 mm/s, running the simulation for around 0.05 seconds, and seeing no change, because the mesh was created in millimetre, but since OpenFOAM works with SI Units, after the import, it was considered to be in metre.

Anyway, now I shall move on further, and see how things go.... now that the motion of the individual parts has been solved, I can look into the sliding interface (linearValveFvMesh) bit...

I guess... the saying "When one hears hoof beats... think Horses and not Zebras" really does apply :-)!

Thanks to everyone and have a nice evening!

Philippose

[hjasak]

I take it this is now solved, right (still on my list).

Hrv

[philippose]

Hello and a good morning :-)!

So... I confirmed that the problem so far was to do with the millimetre - metre conversion issue... so that part of the problem is solved...

Now... last evening I went further and enabled the "linearValveFvMesh" setup for the sliding interfaces.

Here I have a quick question... When does one use the "Integral" and the "partial" options for the sliding interface? In the linearValveFvMesh setup, the sliding interface is hard-coded with the "integral" option.

Looking at the description in "slidingInterface.H", it says:

"The definition of the sliding interface can be either integral or partial. Integral interface implies that the slave side completely covers the master (i.e. no faces are uncovered); partial interface implies that the uncovered part of master/slave face zone should become boundary faces."

In the image that I posted, the system is initially completely independent, implying, that both the master and slave sides are not in physical contact and are hence boundary (wall) faces, and as the simulation progresses, there are situations when the master and slave sides are only partially covered.... would this then mean, that I should be using the "partial" option?

Have a lovely weekend!

Philippose

[philippose]

Hello and a Good Evening :-)!

Hope the week has been good for everyone so far :-)!

I have been trying to get the sliding Interface working, but for some reason, success seems to be evading me..... so I thought its time to put another status update here in the hope of eventually finding the solution...!

As can be seen in the last few posts, I solved the issue with the moving mesh (which was an amateur mistake on my part).

Since then, I have trivially modified the "linearValveFvMesh" library to switch from an "Integral" slider system to a "Partial" one, and have set up a simple case with which to test the sliding Interface system.

For ease of understanding, here are a couple of pictures of the two patches which are involved in the slider system (In 3D they are two offset blocks):





The part of the mesh with the circular arc moves towards the right to eventually "slide into" the rectangular part on the right.

As far as I can see, there doesn't seem to be any mistakes in the case setup.... couple of details:

** The motion solver: I have tried "laplaceFaceDecomposition", and "velocityLaplacian"

** Both cases with "uniform" diffusivity

** For the motion solver, I have tried the AMG as well as the ICCG solvers.

** So far, I am only interested in getting "moveDynamicMesh" to work successfully, hence, no fluid related issues yet.

So now for the problem I am facing:

When I run "moveDynamicMesh", everything works perfectly fine, till the time step where the first contact takes place between the two parts of the mesh.

At the instant of first contact, after the sliding interface has been calculated and the checkMesh run is done (which reports a good mesh), when the motion solver takes over, the simulation aborts.

** In the case of the "velocityLaplacian" motion solver, at the point when the mesh has to be moved (after calculating the new point positions), it throws up an error that the number of active points is less than the number of points in the pointList

** In the case of the "laplaceFaceDecomposition" motion solver, the simulation does not get past the motion solver bit, and aborts with a "floating point exception" error.


Here are two images, one in the time step before contact, and one immediately after contact:





As can be seen, the sliding interface has successfully detected the slave points which have crossed the master patch, and changed the mesh locally (I am assuming this change is correct, since checkMesh does not complain, and the mesh looks good still).


It would be great if someone could point out what I might be tripping up on this time.... I spent quite a long time reading through the sliding interface code before realising that the error actually seems to be coming from the motion solver...

Hoping to get some advice....!

Have a great evening!

Philippose

[philippose]

Hello again,

I have been wondering and thinking about this issue further....

Could there be some kind of oversight in the "decoupling" routine in the Sliding Interface system?

The error with which the motion solver quit was related to the number of points in the slave (patch which is moving in this case) patch.

As far as I could understand from the sliding interface code, during the "decouple" phase, all the faces of the master patch and the slave patch are restored to their original form, including all the retired points.

This would imply, that if everything has gone well, the motion solver would not be aware of the fact that there was a topology change in the patches between two solver calls.

Since in this case the motion solver aborts with an error, would it not mean that the mesh was not completely restored to its original form before the motion solver was called?

Just an idea....

Have a nice day!

Philippose