[mturcios777]

Hello everyone,

I am currently working on on a mesh class the combines dynamicRefineFvMesh and dynamicMotionSolverFvMesh. A bit of history to bring you up to speed.

Back in 2.1.x, it was easy enough; I copied the motion calls and velocity boundary correction from dynamicMotionSolverFvMesh and put them in the update() function which also has the refinement from dynamicRefineFVMesh. This worked masterfully on a case based on aachenBomb with a moving boundary and refinement on the C7H16 field.

In 2.2.x, I tried using this mesh for a case with some non-hexahedral cells, and the refinement failed on these cells. They weren't being added to the protectedCells list as they should have. This was fixed with the following commit:
https://github.com/OpenFOAM/OpenFOAM...f842e027a0694e

I've been trying in both 2.2.x and 2.3.x to get them combining, but can't seem to get meshPhi to be properly updated at refinement. This causes a problem as meshPhi is required for updating the velocity boundary conditions after mesh motion.

I posted a bug report here: http://www.openfoam.org/mantisbt/view.php?id=1195, which solved another issue but hasn't quite allowed me to do what I want. Does anyone know how I can get these two mechanisms to "play nice"?

Many thanks to you all!

[wyldckat]

Hi Marco,

Although you did give a good summary of the changes you've made and tried, it feels a bit like flying blind here, as there is no clear indication of where you tried to change what exactly.

I did however find this piece of lost code in OpenFOAM 2.3.x, in the file "src/dynamicFvMesh/dynamicRefineFvMesh/dynamicRefineFvMesh.C", a bit lost in the methods "refine":

    // Move mesh
    /*
    pointField newPoints;
    if (map().hasMotionPoints())
    {
        newPoints = map().preMotionPoints();
    }
    else
    {
        newPoints = points();
    }
    movePoints(newPoints);
    */

It does give the idea that this is the right place to use something like:

newPoints = motionPtr_->newPoints()

Although it feels that the right thing to do would be to somehow load up the point motion to be done onto the "meshMod" variable, as it seemed to be hinted in the comments above it:

    // Change mesh and generate map.
    //autoPtr<mapPolyMesh> map = meshMod.changeMesh(*this, true);

Although the "true" argument is only for setting "syncParallel" to true.

You could try:

meshMod.movePoints(newPoints);

but it clearly states in its comments that:

Move all points. Incompatible with other topology changes.

which might not allow the other topology changes to occur...

Either way, from the small experience I have with mesh manipulation (mostly from creating a variant of stitchMesh, named stitchMeshMultiPatch), it seems to be better to perform all mesh manipulations by a single operator (in my case, using a single instance of "polyTopoChanger"), rather then using 2 consecutive operators.

Best regards,
Bruno

[mturcios777]

Thanks for the reply Bruno. What I had done back in 2.1.x was add the call for

dynamicFvMesh::movePoints(motionPtr->newPoints())

before the refine/unrefine calls. What is interesting is that the motion and refinement work fine, its the subsequent call to meshPhi (either in correctBoundaryConditions or correctPhi) that fails.

I've put up a new bug report, which may or may not help better understand:
http://www.openfoam.org/mantisbt/view.php?id=1305

If I turn off correctPhi in system/fvSolution and use fixedValue boundary condition on the moving wall the case runs, though the velocity near the wall is wrong unless I explicitly setting it as the value. This works for the very simple case I made for the bug report, but may not be for engine cases or similar.

At any rate, its only the call to meshPhi that crashes things, which makes it feel like it dissapears during the refinement. I will try moving the mesh movement to where you mentioned and see what happens. Expect a report!

EDIT: Tried moving the mesh motion to commented out code and the same result was obtained.

[wyldckat]

Originally Posted by mturcios777

EDIT: Tried moving the mesh motion to commented out code and the same result was obtained.

At the risk of sending you on a very wild goose chase into dynamic meshing, a good/advanced source code for dynamic meshing is "dynamicTopoFvMesh", for which the port for 2.2.x is available here: https://github.com/smenon/dynamicTop...ree/Port-2.2.x
It essentially does point motion, re-meshing and motion optimization with Mesquite... or at least it's my interpretation of it.
It only works with tetrahedral cells, but the way it handles the mesh manipulation is different from how OpenFOAM does it, which is why I do think this might come in handy for you. I say this because re-meshing is conceptually similar to mesh refinement and this library also handles motion driven by outside forces.

My memory is very fuzzy from when I looked into it last year, so I don't remember much about what I learned from that source code. Nonetheless, a few memory breadcrumbs are registered on this thread: http://www.cfd-online.com/Forums/ope...opofvmesh.html - On that thread, the initial case discussed (which had some issues running) was a ball floating inside a tube.

[wyldckat]

Hi Marco,

I remembered to come back to this issue to leave a comment for other forum readers.
The fix was eerily simple and it didn't needed any change in "dynamicRefineFvMesh":

https://github.com/OpenFOAM/OpenFOAM...641733c8cc7e2a

@@ -107,7 +107,7 @@ void Foam::movingWallVelocityFvPatchVectorField::updateCoeffs()
 
     const fvMesh& mesh = dimensionedInternalField().mesh();
 
-    if (mesh.changing())
+    if (mesh.moving())
     {

         const fvPatch& p = patch();

         const polyPatch& pp = p.patch();

Best regards,
Bruno

[mturcios777]

Thanks Bruno, I was relieved to see the fix go though and pulled that commit faster than you can say Courant Number.

[Q.E.D.]

Hi Marco,

do you succeeded in generating a new class which combines dynamicRefineFvMesh and dynamicMotionSolverFvMesh?

I'm eager to hear your update.

Best wishes
Q.E.D.

[mturcios777]

I was able to get it to work. The fix above was the answer, and I think I also had to do the move after the refinement.

[Q.E.D.]

Great news! I wonder whether you would mind to share your library? I'm currently working on a case where it might prove very useful!

Anyway, I think the community would be glad to see this library in the next release!

Best Wishes
QED

[mturcios777]

Unfortunately I can't as it was developed for work with some other functionality. But the basics are reasonably straightforward. Just clone dynamicFvRefinementMesh into a new mesh class and add the motion solver creation in the constructor and the mesh motion calls from dynamicFvMotionSolverMesh in the update() member function.

You will also need to include all the necessary libraries and source files for it to compile. Depending on which version of OF you have and how your pEqn.H file looks, moving the mesh may need to happen before or after refinement. Only testing will tell you for sure.

Good luck!

[Q.E.D.]

Ah, I suspected something Like this. Thank you nonetheless Marco for your valueable tips! I will try to implement it myself! I just thought that maybe I don't have to reinvent the wheel. (As we say here in Germany) :-)

Have a nice weekend!

[Q.E.D.]

Hi Marco,

I did as you suggested and the new class compiles well. But I encounter an error which says:

Cannot move points: size of given point list smaller than the number of active points.

It happens in the second iteration, because I put the motion part before the refinement. The first iteration is ok, because it moves and then refines correctly. But then the mentioned error comes up. I guess I have to update the internal mesh numbering somehow. I tried to do this, but failed.

Do you have another tip for me?

Best wishes
Q.E.D.

[Q.E.D.]

Hey everyone,

just a small update: I managed to solve the problem. But I used a chalmers report as a basis, where a new class is derived from dynamicRefineFvMesh and a solidBodyMotionFunction is added as the motion solver. With some minor changes the class works well in OpenFOAM-5.x. The change in the movingWallVelocity BC is not necessary anymore.

In the attachment you will find the library and a test case. The test case is Tobis interfaceAndColumnRefine (www.holzmann-cfd.de) which I modified slightly. Thats because I tried to replace the standard dynamicRefineFvMesh by Tobis dynamicInterfaceRefineFvMesh (Since I was interested in the motion and refinement of an InterDyMFoam-Case), but some error occured which I could not resolve due to my lack of C++ skills.

Best wishes,
Q.E.D.

[Q.E.D.]

With some small adjustments in Make/options you are able to include Tobis interface refinement library with the motion solver. Have a look at the attached files.

[Q.E.D.]

Ok, something is still wrong with this library. I was able to stabilize the computation only by setting the frequency of the movement to zero. (Which is equal to no movement obviously)

Now I have no clue at all....

[agade]

Hello I have created a video about the procedure of merging two libraries dynamicMotionFvMesh and dynamicRefineFvMesh. Hope it helps all existing and future users.

https://youtu.be/Yq-ySlXE5JQ