[philippose]

Hello and a good evening,

I am not sure if I am doing the right thing, but the last two posts in the following thread are actually more related to the OpenFOAM sliding interface system:

Mesh motion + independent mesh regions

I thought it would be better to start a new thread for this topic, because the subject line of the previous topic is too misleading.

Hoping for help from OpenFOAM users who have experience with the Sliding Interface.

Have a great evening!

Philippose

[hjasak]

Sorry, but why are you using the mesh motion solver? Surely, it is faster and easier to specify the motion of two blocks directly, sonce they are moving as solid bodies...

Hrv

P.S. The tet decomposition motion solvers will work fine. Make sure you are detaching and attaching the mesh if multiple changes are to happen in a single time-step.

[philippose]

Hello Hrv,

A Good day to you... and firstly... thank you for the reply... :-)!

So far, I have not done anything exotic (as in... am still using standard utilities available in OpenFOAM)... I am using the stock "linearValveFvMesh" topology changer library for defining the sliding interface.

As far as I could understand, the "linearValveFvMesh" library detaches the mesh for each time step, before calling the mesh motion solver. After the mesh motion solver is done and the mesh has moved to the new position, it re-calculates the sliding interface, and attaches the mesh before calling the fluid solvers.

From the debug messages I got from the linearValveFvMesh and the sliding interface libraries, it looks like the simulation fails at a point after the sliding interface detaches itself, when the motion solver is called.... but only when when the two parts make contact (everything works fine before contact).

While reading through some of the earlier (2005/2006) posts regarding the sliding interface, I found a couple of posts which say that the sliding interface has (had?) problems with meshes where the sliding patches have a corner, due to projection difficulties... is this still the case?

I did not think about directly moving the points without a motion solver.... Shall look into this. However, it would be great if it would work with a motion solver, since the current case I am trying is only a simple case to test the sliding interface, but later this would not be the case.

Could it be something to do with the linearValveFvMesh library?

Have a nice day!

Philippose

[philippose]

Hello and a Good Afternoon :-)!

Cant ask for better weather to get one to sift through code on a Saturday afternoon :-)!

I have been trying to get the sliding interface working for the whole of this morning, and well... not yet hit that point of enlightenment :-)!

Anyway, have been looking through the code for the various parts involved, putting in debug messages etc..etc.., and now I have a couple more questions.

However, firstly, here is an excerpt of the "moveDynamicMesh" log for the time step at which the sliding interface makes contact, and for the immediately next time step where the simulation aborts, with some additional debugging messages, etc...:

Time = 0.005
In function: linearSpoolValveFvMesh::update()
linearSpoolValveFvMesh::update() => Status (slider attached): 1
Decoupling sliding interfaces
bool slidingInterface::changeTopology() const for object spoolSlider : Couple-decouple mode.
void slidingInterface::decoupleInterface(polyTopoChange & ref) const : Decoupling sliding interface spoolSlider
void slidingInterface::clearCouple(polyTopoChange& ref) const for object spoolSlider : Clearing old couple points and faces.
void slidingInterface::clearCouple(polyTopoChange& ref) const for object spoolSlider : Finished clearing old couple points and faces.
void slidingInterface::coupleInterface(polyTopoChange& ref) const : Finished decoupling sliding interface spoolSlider
void slidingInterface::updateMesh(const mapPolyMesh& m) const for object spoolSlider : Updating topology.
void Foam::slidingInterface::calcAttachedAddressing() const for object spoolSlider : Calculating zone face-cell addressing.
void Foam::slidingInterface::calcAttachedAddressing() const for object spoolSlider : Finished calculating zone face-cell addressing.
linearSpoolValveFvMesh::update() => Status (meshChanged1): 1
linearSpoolValveFvMesh::update() => Sliders disabled
linearSpoolValveFvMesh::update() => Number of points seen by motion solver = 15980
linearSpoolValveFvMesh::update() => Calling motion solver now...
PCG: Solving for motionUx, Initial residual = 0.332421, Final residual = 7.82099e-09, No Iterations 71
PCG: Solving for motionUy, Initial residual = 0, Final residual = 0, No Iterations 0
PCG: Solving for motionUz, Initial residual = 0, Final residual = 0, No Iterations 0
PCG: Solving for motionUx, Initial residual = 4.92632e-09, Final residual = 4.92632e-09, No Iterations 0
PCG: Solving for motionUy, Initial residual = 0, Final residual = 0, No Iterations 0
PCG: Solving for motionUz, Initial residual = 0, Final residual = 0, No Iterations 0
linearSpoolValveFvMesh::update() => Done with motion solver.... actually moving points now....
linearSpoolValveFvMesh::update() => Done with moving the points....
Coupling sliding interfaces
bool slidingInterface::changeTopology() const for object spoolSlider : Couple-decouple mode.
bool slidingInterface::projectPoints() for object spoolSlider : Projecting slave points onto master surface using N-squared point projection
Number of hits in point projection: 2 out of 1156 points.
Number of adjusted points in projection: 0
... projection OK.
... point merge OK.
Number of merged master points: 1
Number of adjusted slave points: 1
Processing slave edges
..........x..+ ..........x.+ ..........x.+ ..........x+ ..........x...+ m..........x.+ ..........x..+
bool slidingInterface::projectPoints() for object spoolSlider : Finished projecting points. Topology = (Detached interface) changing.
void slidingInterface::coupleInterface(polyTopoChange& ref) : Coupling sliding interface spoolSlider
Inserting point merge pair: 14871 : 33
Inserting merge pair off edge: 14872 15980 cut point: (0.02 -0.000251301 0) orig: (0.0199882 -0.000251301 0) proj: (0.02 -0.000251301 0) master point: 14872
e15980 = (0.02 -0.000251301 0)

Processing slave edges
..+ nxn-nxn-n-n-n-n-n-n-n-n-nxn-nxn-n-n-n-n-n-un-n-
.+ n-un-n-un-n-nxn-nxn-uun-n-
.+ n-n-n-n-n-n-n-nxunxun-n-n-n-uu
+ n-nxun-n-nxn-
...+ n-n-n-n-n-n-n-n-n-uuun-n-n-n-n-n-n-n-n-n-n-n-n-n-n-un-uun-un-n-n-n-n-n-n-
.+ nxuun-n-n-n-n-n-n-n-un-un-
..+ n-n-n-n-n-n-n-n-n-n-n-n-n-nxn-nxnxn-nxn-n-un-n-
Number of orphaned faces: master = 1 out of 4174 slave = 1 out of 2190
Retired 2 out of 1156 points.
void slidingInterface::coupleInterface(polyTopoChange& ref) : Finished coupling sliding interface spoolSlider
void slidingInterface::updateMesh(const mapPolyMesh& m) const for object spoolSlider : Updating topology.
Moving points post slider attach
Sliding interfaces coupled: 1
Point usage OK.
Upper triangular ordering OK.
Topological cell zip-up check OK.
Face vertices OK.
Face-face connectivity OK.
Mesh topology OK.
Boundary openness (1.99221e-19 1.52705e-20 3.25819e-19) Threshold = 1e-06 OK.
Max cell openness = 1.56105e-16 OK.
Max aspect ratio = 6.26009 OK.
Minumum face area = 5.92017e-08. Maximum face area = 1.3168e-06. Face area magnitudes OK.
Min volume = 6.29488e-12. Max volume = 4.19076e-10. Total volume = 6.28495e-06. Cell volumes OK.
Mesh non-orthogonality Max: 63.9959 average: 20.6205 Threshold = 70
Non-orthogonality check OK.
Face pyramids OK.
Max skewness = 0.844542 OK.
Mesh geometry OK.
Mesh OK.
ExecutionTime = 171.58 s ClockTime = 185 s

Time = 0.006
In function: linearSpoolValveFvMesh::update()
linearSpoolValveFvMesh::update() => Status (slider attached): 1
Decoupling sliding interfaces
bool slidingInterface::changeTopology() const for object spoolSlider : Couple-decouple mode.
void slidingInterface::decoupleInterface(polyTopoChange & ref) const : Decoupling sliding interface spoolSlider
void slidingInterface::clearCouple(polyTopoChange& ref) const for object spoolSlider : Clearing old couple points and faces.
void slidingInterface::clearCouple(polyTopoChange& ref) const for object spoolSlider : Finished clearing old couple points and faces.
void slidingInterface::coupleInterface(polyTopoChange& ref) const : Finished decoupling sliding interface spoolSlider
void slidingInterface::updateMesh(const mapPolyMesh& m) const for object spoolSlider : Updating topology.
void Foam::slidingInterface::calcAttachedAddressing() const for object spoolSlider : Calculating zone face-cell addressing.
void Foam::slidingInterface::calcAttachedAddressing() const for object spoolSlider : Finished calculating zone face-cell addressing.
linearSpoolValveFvMesh::update() => Status (meshChanged1): 1
linearSpoolValveFvMesh::update() => Sliders disabled
linearSpoolValveFvMesh::update() => Number of points seen by motion solver = 15981
linearSpoolValveFvMesh::update() => Calling motion solver now...
[[Aborts here with a "floating point exception"]]

So the questions:

1. When the sliding interface is used with the "Partial" type of match option, it is supposed to convert only those parts which are actually intersecting into internal faces, and leave all the other faces as part of the original boundary patches.... could I get a pointer as to where exactly this part of the code is in the source code for the sliding interface?

2. When the sliding interface "decouples", does it reset the master and slave patches to their completely original states as far as number of points and faces are concerned? If so, in the time-step "0.006", shouldn't the number of points seen by the motion solver be 15980 rather than 15981 ? The additional point was created by the sliding interface, but that should only exist when the two patches are coupled right?

3. Even if the decoupled patches are modified by the sliding interface and are no more in their original form, what could be the reasons for the motion solver to abort, as long as all the changes have been reflected in the faces, points, owner and neighbour files for the current time step?

4. Is there anything special I need to do to the linearValveFvMesh library when I convert from an "INTEGRAL" type of match to a "PARTIAL" type of match other than changing that one line in the sliding interface definition?

Have a nice Saturday, and a great weekend :-)!

Philippose

[philippose]

Hello again,

And as always, a very good evening to everyone too :-)!

I have only two very short questions this time...:

** Is the Sliding Interface in OpenFOAM 1.4.1-dev (SVN) known to work in combination with pure tetrahedral meshes?

** If so, is there anyone out there who has used the Sliding Interface in cases where the two sliding patches are completely separate from one another to start with, and as the simulation progresses one part moves (or slides...) into the other.... Specific being, the existence of a corner at the point where the two patches make contact?

Hoping for some positive replies :-)!

Have a great evening!

Philippose

[hjasak]

Heya:

** Is the Sliding Interface in OpenFOAM 1.4.1-dev (SVN) known to work in combination with pure tetrahedral meshes?

Yes. There is no limitation to the cell of face shape. This is full polyhedral support

** If so, is there anyone out there who has used the Sliding Interface in cases where the two sliding patches are completely separate from one another to start with, and as the simulation progresses one part moves (or slides...) into the other.... Specific being, the existence of a corner at the point where the two patches make contact?

Yes - have a look at eg. Tommaso's two-stroke internal combustion engines.

Hrv

[philippose]

Hello again Hrv,

And a Good Evening to you too :-)!

Thanks a lot for confirming that the sliding interface system in OpenFOAM not only supports tets, but even polyhedral cells.... so thats one thing out of the way....

I have been looking into the two stroke internal combustion engine source-code because I too assumed that since a typical 2-stroke engine has ports rather than valves, there has to be some kind of system there which looks like mine :-)!

Anyway.... shall have to look deeper into the code to see if I am missing something... so far, the linearValveFvMesh system is very similar to his setup...

In addition....

I was able to get the simulation to go past the first contact point by tuning the motion velocity, such that at the time when first contact occurs, the moving part of the mesh is already some way within the fixed part... not an almost edge to edge contact (which was the case so far)...

In this case, the checkMesh comes up with errors and non-orthogonality shoots up to 90° in the first time step after contact... and then higher to over 105° in the next time step, and then checkMesh aborts the simulation with an error....

Do you think it could be that the mesh is not fine enough for the sliding interface to be able to function properly?

Have a nice remaining evening!

Philippose

[xyt]

i want to get slideinterface between two mesh, how can i set up a case,are there some exsamples