[deepsterblue]

Hello Giancarlo,

Perhaps you could print out your "T" field after mesh.update() and see if the values are within the range that you expect? I'm looking to see if the field remapping after topology changes is correct.

Thanks,
Sandeep

[Giancarlo_IngChimico]

Hello Sandeep,
thanks for your reply.
I have checked the temperature field after the mesh.update and the remapping seems to work well.
I insert what I see from the bash

Create time

Create dynamic mesh for time = 0

Selecting dynamicFvMesh dynamicTopoFvMesh
Selecting metric Knupp
--> FOAM Warning : 
    From function dlLibraryTable::open(const fileName& functionLibName)
    in file db/dlLibraryTable/dlLibraryTable.C at line 85
    could not load libtetMetrics.so: cannot open shared object file: No such file or directory
Selecting motion solver: mesquiteMotionSolver
Selecting quality metric: AspectRatioGamma
Selecting objective function: LPtoP
Selecting optimization algorithm: FeasibleNewton
Outer termination criterion (tcOuter) was not found. Using default values.
Reading field T

Reading transportProperties

Reading diffusivity DT

Time = 0.001
before mesh update  
 * T gas min/max   = 300, 773


************** QualityAssessor(free only) Summary **************

  Evaluating quality for 40521 elements.
  There were no inverted elements detected. 
  No entities had undefined values for any computed metric.

          metric     minimum     average         rms     maximum    std.dev.
AspectRatioGamma  1.00071332 1.251984571 1.262627653 2.5725376290.1635946915

************** QualityAssessor(free only) Summary **************

  Evaluating quality for 40521 elements.
  There were no inverted elements detected. 
  No entities had undefined values for any computed metric.

          metric     minimum     average         rms     maximum    std.dev.
AspectRatioGamma 1.000839219 1.251709074 1.262370641  2.573260010.1637193572

 ~~~ Mesh Quality Statistics ~~~ 
 Min: 0.5325301726
 Max: 0.999440912
 Mean: 0.8683070914
 Cells: 40521
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 

 Topo modifier time: 0.166229 s
 Bisections :: Total: 0, Surface: 0
 Collapses  :: Total: 0, Surface: 0
 Swaps      :: Total: 430, Surface: 3
 Mapping time: 0.037745 s
 Reordering time: 0.038874 s
 ~~~ No flux correction ~~~ 

 ~~~ Mesh Quality Statistics ~~~ 
 Min: 0.5669694553
 Max: 0.999440912
 Mean: 0.8671070099
 Cells: 40523
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 

    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 (5.813326312e-16 -2.317997225e-19 -4.530630939e-19) Threshold = 1e-06 OK.
    Max cell openness = 2.179222994e-16 OK.
    Max aspect ratio = 4.19270934 OK.
    Minumum face area = 7.109358104e-08. Maximum face area = 1.695177569e-06.  Face area magnitudes OK.
    Min volume = 1.202657362e-11. Max volume = 6.654840401e-10.  Total volume = 4.185231801e-06.  Cell volumes OK.
    Mesh non-orthogonality Max: 51.15319832 average: 16.46141962 Threshold = 70
    Non-orthogonality check OK.
    Face pyramids OK.
    Max skewness = 0.6017764185 OK.
    Mesh geometry OK.
Mesh OK.
after mesh update  
 * T gas min/max   = 300, 773

GAMG:  Solving for T, Initial residual = 1, Final residual = 2.009590784e-09, No Iterations 6
after compute laplacian  
 * T gas min/max   = 277.230632, 773

As you can see, after the mesh update,the temperature is within the initial range [300-700]. After the laplacian, the minimal temperature is under the 300 K.


Best regards

Giancarlo

[deepsterblue]

This then suggests that you have problems in your solution set up. You should check your schemes and boundary conditions. Since you're solving a laplacian, do you have fixedValue boundary conditions? You might have a saddle-point problem otherwise.

[Giancarlo_IngChimico]

Yes, I have fixedValue BC for temperature field:

dimensions      [0 0 0 1 0 0 0];

internalField   uniform 300;

boundaryField
{
    
    outlet
    {
        type            fixedValue;
        value           uniform 773;
    }

}

Moreover, I have this fvSchemes:

ddtSchemes
{
    default         Euler;
}

gradSchemes
{
    default         cellLimited Gauss linear 1.0;
    grad(T)         cellLimited Gauss linear 1.0;
}

divSchemes
{
    default         Gauss skewCorrected linear;
}

laplacianSchemes
{
    default         Gauss linear corrected;
    laplacian(DT,T) Gauss linear corrected; 
}

interpolationSchemes
{
   
}

snGradSchemes
{
    default        limited 0.5;
}

fluxRequired
{
    default         no;
    T               ;
}

Do you have any suggestions about these schemes?

[Giancarlo_IngChimico]

Hello Sandeep,
I worked about the problem that I explained you last week, but I think that it's not a problem of the discretization schemes.
I have made a very simple case in order to better explain the discrepancy during the solution of the laplacian equation.
My mesh is a box of 16 cells. I move only a face of the box in order to have the restriction of the initial volume. I set the temperature of the domain to 700 (boundary and internal field). Moreover, I compute the temperature laplacian:

fvm::ddt(T) - fvm::laplacian(DT, T)

Since, I set an initial temperature that it's uniform in the domain, after the laplacian I expect that the temperature should remain constant.
If, I don't move the mesh the temperature is always constant to 700. The solver is able to properly solve the laplacian.
On the other hand, if I set the mesh motion, I register no feasible temperature field. (the solution is not bounded to 700).

I post the results, after the first iteration:

Time = 0.01
First Time = 0.01
before mesh update  
 * T gas min/max   = 700, 700


************** QualityAssessor(free only) Summary **************

  Evaluating quality for 16 elements.
  This mesh had 16 tetrahedron elements.
  There were no inverted elements detected. 
  No entities had undefined values for any computed metric.

     Element Quality Statistics

     minimum     average         rms     maximum    std.dev.
     2.31432      3.9077     4.06364     5.36664     1.11494

     Number of statistics = 16
     Metric = Inverse Mean Ratio
     Element Quality not based on sample points.


************** QualityAssessor(free only) Summary **************

  Evaluating quality for 16 elements.
  This mesh had 16 tetrahedron elements.
  There were no inverted elements detected. 
  No entities had undefined values for any computed metric.

     Element Quality Statistics

     minimum     average         rms     maximum    std.dev.
     2.32711     3.90594     4.06299     5.37956     1.11869

     Number of statistics = 16
     Metric = Inverse Mean Ratio
     Element Quality not based on sample points.


 ~~~ Mesh Quality Statistics ~~~ 
 Min: 0.18607
 Max: 0.430672
 Mean: 0.280001
 Cells: 16
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 

 Topo modifier time: 0.000501 s
 Bisections :: Total: 0, Surface: 0
 Collapses  :: Total: 0, Surface: 0
 Swaps      :: Total: 4, Surface: 4
 Mapping time: 0.000575 s
 Reordering time: 9.8e-05 s

 ~~~ Mesh Quality Statistics ~~~ 
 Min: 0.18607
 Max: 0.430672
 Mean: 0.280001
 Cells: 16
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 

    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 (0 0 0) OK.
    Max cell openness = 1.00066e-16 OK.
    Max aspect ratio = 20.6157 OK.
    Minimum face area = 1.40167e-06. Maximum face area = 2.49375e-05.  Face area magnitudes OK.
    Min volume = 1.05712e-09. Max volume = 4.43364e-09.  Total volume = 4.9875e-08.  Cell volumes OK.
    Mesh non-orthogonality Max: 80.9498 average: 62.9846
   *Number of severely non-orthogonal (> 70 degrees) faces: 8.
    Non-orthogonality check OK.
    Face pyramids OK.
    Max skewness = 0.467541 OK.
    Mesh geometry OK.
Mesh OK.
after mesh update  
 * T gas min/max   = 700, 700

DICPCG:  Solving for T, Initial residual = 1, Final residual = 7.56663e-07, No Iterations 6
after solution  
 * T gas min/max   = 698.49, 704.226

I dont't think it's a problem of the discretization scheme, because if I don't move the mesh, the solution is correct.
Now, I'm working with OF-2.3, but I try to solve the same system with (OF-1.6-ext and OF-3.1-ext) and I have always the same problem.
I think that, maybe, not all the mesh fields are updated with the mesh motion.
Do you have any suggestion? I attach the test case and solver.

Thanks in advance

Best regards

Giancarlo

[alexB]

Hello Sandeep,

I am interested in using dynamicTopoFVmesh, but can't pull it from github for OF2.3.0 .
Perhaps it is on purpose because of some updates of the files or something like that.
In that case don't mind this post.

If i try to pull dynamicTopoFVmesh for OF2.3.x I get the Version for OF-ext instead. By clicking the link for OF2.3.x a pretty cool Tatooine error 404 shows. (for everybody who has 2 Seconds time here is the link https://github.com/smenon/dynamicTop...new/Port-2.3.x )

kind regards
Alex

[deepsterblue]

You need to do this to switch to the Port-2.3.x branch after a git clone:

git checkout Port-2.3.x

This will switch from the 'master' branch to the 'Port-2.3.x' branch

[alexB]

Thanks for the fast reply.

With your hint I tried the clone command with following option.

git clone -b Port-2.3.x https://github.com/smenon/dynamicTopoFvMesh/ /home/user/dynamicTopoFVmesh/

Now i have the right files and try on with yout tool.

kind regards
Alex

[maalan]

t appears that the oscillatingDisplacement patchField provides an absolute value of displacement (from the mean), while the applyFixedValuePatches() function in mesquiteMotionSolver expects an incremental displacement vector for each time-step.

You see the acceleration because the displacement is continuously updated as:

refPoints_ += dPointField; in mesquiteMotionSolver.C

You could write a new boundary condition similar to oscillatingDisplacement which provides displacement increments, or alternatively, I also provide a timeVaryingDisplacement patchField in the repository that uses an interpolation table from file, which might be easier. I would have to look into a fix for the absolute vs. incremental confusion.

Can you try changing the "+=" operator in applyFixedValuePatches to simply "=" and see if that makes a difference?

Hi Sandeep! Did you manage this issue? I am using your tool with 2 cylinders moving harmonically but unfortunately they don't stop and go back, just go forward... Hope you could help.

Best regards,
Antonio

[deepsterblue]

Hello Antonio,

Could you use this option in mesquiteMotionSolver (under mesquiteOptions in constant/dynamicMeshDict):

usePointDisplacement    yes;

and specify your boundary conditions using the pointDisplacement file?

[mneben]

Originally Posted by deepsterblue

Ah... I know what the problem is:

It appears that the oscillatingDisplacement patchField provides an absolute value of displacement (from the mean), while the applyFixedValuePatches() function in mesquiteMotionSolver expects an incremental displacement vector for each time-step.

You see the acceleration because the displacement is continuously updated as:

refPoints_ += dPointField; in mesquiteMotionSolver.C

You could write a new boundary condition similar to oscillatingDisplacement which provides displacement increments, or alternatively, I also provide a timeVaryingDisplacement patchField in the repository that uses an interpolation table from file, which might be easier. I would have to look into a fix for the absolute vs. incremental confusion.

Can you try changing the "+=" operator in applyFixedValuePatches to simply "=" and see if that makes a difference?

Hello Sandeep,

actually I'm playing around with different mesh motion methods in OpenFOAM. Therefore I've created a simple test case, which is a carman flow around a moving cylinder (see attachment)
At first I've run moveDynamicMesh without boundary motion to optimize the mesh (as you recommended), afterwards I enabled the boundary motion and run the simulation with pimpleDyMFoam (adjustTimeStep enabled).
Regarding to your post this will fail due to the adjustable time step and the way you've implemented the mesh motion. Thats why I changed
"refPoints_ += dPointField" to "refPoints_ = dPointField". But with both versions of the dynamicTopoFvMesh library (of31 and your git version) I get a floating point exception. Is there any other way to fix this except the timeVaryingDisplacement patchField? How can I achieve the full range of available patchFields?

Best regards
Matthias

[Giancarlo_IngChimico]

Dear all,
I'm a Ph.D. student of chemical Enginnering. The aim of my work is to develop a solver within the OpenFOAM framework for the combustion of spherical/cylindrical particle of biomass. To reach this object I have to introduce a moving mesh in order to allow the shrinking of the particle. I'm currently working with the dynamicTopoFvMesh library developed by Sandeep Menon and it works very good for a sphere, but I have several problems for the cylinder.
For sake of clarity, I attach you the picture of my mesh at time 0. I have three boundary patch (inlet, outlet, lateralSurface) and I need to move, at the same time, all the point of each boundary with a prefix velocity along the face normal direction.
As you can see from the second picture that I've attached, the mesh does not evolve with a uniform shrinking in both directions (axial and radial), but the border points, that belong at the same time to two different patches, seem to move with different velocity.
My question is, Is it possible to perform this kind of mesh shrinking with this library?
I attach you my case, I use moveDynamicMesh as solver.

Thanks in advance

Giancarlo

time0.jpg
time2.jpg

cylinder.zip

[wyldckat]

Quick answer @Giancarlo_IngChimico: I haven't done the math nor tested the case yet, but I'm guessing that the problem is that the sides must be defined to move at 50% the speed of the cylinder.
I suggest that you do a test in ParaView and use the Transform filter to scale down to 0.5 on all directions and then check what were the distance changes that occurred on each surface.

By the way, which OpenFOAM version are you using?

[Giancarlo_IngChimico]

Dear Bruno,
Currently I'm using openFoam 2.3.x. Thanks for your help. In my opinion the border points are update twice depending the patch order in the fixedValuePatches subDict. It leads, for some reason, a no uniform mesh motion in both radial and axial coordinates.

Originally Posted by wyldckat

Quick answer @Giancarlo_IngChimico: I haven't done the math nor tested the case yet, but I'm guessing that the problem is that the sides must be defined to move at 50% the speed of the cylinder.
I suggest that you do a test in ParaView and use the Transform filter to scale down to 0.5 on all directions and then check what were the distance changes that occurred on each surface.

By the way, which OpenFOAM version are you using?

[wyldckat]

Hi Giancarlo,

I've tried to run your case with the following software stack:

• OpenFOAM 2.3.x
• dynamicTopoFvMesh's branch "Port-2.3.x"
• Mesquite 2.1.2 build from foam-extend 3.2
• swak4Foam 0.3.2

And I see what you mean. When I overlay the scale down of the original surface with 0.92, the edges only moved for the curved surface, as shown in the attached image.

The first suspect is the "toPoints" function: http://openfoamwiki.net/index.php/Co...s_are_defined:

toPoint

Takes a scalar (or vector) field defined on the faces and interpolates it to the points

A quick search for "toPoints" and I found this:

Originally Posted by gschaider

a) to construct a pointVectorField it must be "vector(toPoint(0),toPoint(0.05*(sin(pi*time()))), toPoint(0))"

I've done some considerable trial-and-error testing and it seems that you will need to do specific mathematics for the corner points, because the point mesh field is being overridden by the final boundary condition that is done on "lateralSurface".
This can easily occur, because OpenFOAM's main calculations are done on the faces and cells. And since these points on the edges are common to 2 boundaries and not only one, it currently has no other way to assign dedicated boundary conditions for a group of points.
Therefore, you will need to do specific calculations for the points on the edges of the cylinder... although I haven't really thought about how that can be done with GroovyBC

A quick thinking about it leads me to believe that you can use "inline-if" conditions for defining how calculations are done based on specific conditions. And those conditions you can calculate only for the final boundary.
Hopefully you can draw ideas from here: https://openfoamwiki.net/index.php/C...Usage_Examples

The other possibility would be to rely on pointSets to manipulate specific point groups and assign dedicated point conditions to them.

Best regards,
Bruno

[Giancarlo_IngChimico]

Dear Bruno,
thanks again for your help.
Today I've fixed my problem. dPointField defined in the file mesquiteMotionSolver.C is a pointField where all points displacement are stored. This field doesn't take into account multiple displacement of border points but is being overridden by the final boundary condition that, in my case, is done on "lateralSurface" patch. Adding multiple movements (radial and axial) of the border points in the dPointField , I've fixed my problem.
Currently I can mange shrinking of my cylinder both in radial and axial directions.
Nevertheless, I have another problem with the surface smoothing.
Fist of all, I tried the mesh motion specifying only the outlet and inlet patches in the slipPatches subDict, as follow.

slipPatches
    {
	outlet;	
	inlet;
    }

As you can see, in the first picture, the mesh motion in both directions is ensured until crush due to lower mesh quality.

In the second test, I perform the mesh motion with the following slipPatches subDict

slipPatches
    {
	lateralSurface;	
    }

Again, I'm able to perform the mesh motion, until solver crush (always due to lower mesh quality)as explained in the picture 2.

At the end, I added all my patches in the slipPatches subDict

slipPatches
    {
     inlet;
     outlet
     lateralSurface;	
    }

The result is a complete no sense distortion of my mesh, as highlighted in figure 3.

In other words, it seems the dynamicTopoFvMesh has a bug in multiple patches smoothing.
Do you have any idea about these strange behavior?

Thanks again

Giancarlo

one.jpg
two.jpg
three.jpg

[wyldckat]

Hi Giancarlo,

Sorry for the late reply, but only today did I finally manage to take a better look into your question.

If my memory doesn't fail me, the "slip patches" feature is for defining the patches that allow the mesh to slide along those patches.
For example, attached are two images from OpenFOAM's tutorial case "mesh/moveDynamicMesh/SnakeRiverCanyon", where:

1. "snakeRiverCanyon_0.png" shows the initial mesh position, looking at it from one of the sides.
2. "snakeRiverCanyon_5.png" shows the final position.

The boundary conditions defined in "0/pointDisplacement" are as follows:

1. The top patch is set to a fixed value, i.e. it doesn't move.
2. The bottom patch is the one that moves and is using the boundary condition "surfaceDisplacement".
3. All of the remaining 4 patches on the sides are using the boundary condition "fixedNormalSlip".

As you can see from the 2 images, these 4 lateral patches are the "slip patches", which in this case, they do not change the position along the normal direction to they own surface, but the mesh points on those patches can move along the other 2 directions. This is why they are "slipping".

This was possible in this case, because these 4 patches have strict normal definitions that allow the calculations to be performed properly. But in your case, dynamicTopoFvMesh is trying to deduce the normal directions automatically, but since all directions are changing simultaneously, it's not able to know for certain which side is up, because everything is changing.

I don't know if you've figured out how to solve these issues, but I believe that the trick is to use a boundary condition that uses the original position as a reference for all other iterations. But this will likely require coding said boundary condition.

Best regards,
Bruno

[Arne87]

Hi all,

I am trying to use dynamicTopoFvMesh to refine a mesh (tets) around a surface in a VOF method with or without the mesquite smoother.
Does anybody have a testcase where this is done in a small scale application? At the moment I am trying figure out what the correct settings in the dynamicMeshDict are. However, I am not experinced with the tool and I dont have a runing test case and the default setting seem not to work. Therefore, it is a lot of try and error.

If anybody has experince with the field refinement tools of dynamicTopoFvMesh and or a testcase. I would be glad about some input.

Best

Arne

[daron]

Hello Bruno and Sandeep,


did you figure out the 6dof problem in this 'volvmov-topo' case


sincerely
daron

Originally Posted by wyldckat

Hi Sandeep,

OK, I've got mixed results...

First for the partially-good news:

While using the hack to use the file system and by adding the sphere (named "oggetto") to the "noModificationPatches" and "noSwapPatches", it does allow to keep the sphere's surface in perfect condition while it moves.
The downside is that it crashes when the cells in the way start to get too tight and eventually collapse into negative volumes.

The error message:

Courant Number mean: 0.04541765902 max: 4.191785362
deltaT = 3.333333333e-05
Time = 0.0202

sixDoFRigidBodyMotion constraints converged in 1 iterations
Constraint force: (0.6537136637 0.02252467437 0)
Constraint moment: (0 0 0)
Centre of mass: (-1.842749434e-08 1.08451596e-08 0.2001177404)
Linear velocity: (-0.0004352669538 8.108849543e-05 0.04280597798)
Angular velocity: (1.573833728 -1.569414796 -0.03449086776)

************** QualityAssessor(free only) Summary **************

  Evaluating quality for 72216 free elements of 72375 total elements.
  THERE ARE 1 INVERTED ELEMENTS. 
  (Elements invalid at 1 of 72216 sample locations.)

  1 OF 72216 ENTITIES EVALUATED TO AN UNDEFINED VALUE FOR AspectRatioGamma

          metric     minimum     average         rms     maximum    std.dev.
AspectRatioGamma 1.002851198   15.115086 3721.202667     1000000 3721.171969

 Warning: Minimum cell quality is: -0.07980588317 at cell: 68575

 ~~~ Mesh Quality Statistics ~~~ 
 Min: -0.07980588317
 Max: 0.9981037065
 Mean: 0.8637096283
 Cells: 72375
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 



--> FOAM FATAL ERROR: 
Encountered negative cell-quality!
Edge: 89295: (3253 3261)
vertexHull: 5(227 9861 10215 9856 3297)
Minimum Quality: -0.07980588317

    From function scalar dynamicTopoFvMesh::computeMinQuality(const label eIndex, labelList& hullVertices) const
    in file edgeSwap.C at line 2246.

FOAM aborting

#0  Foam::error::printStack(Foam::Ostream&) in "/home/bmss/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#1  Foam::error::abort() in "/home/bmss/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#2  Foam::dynamicTopoFvMesh::computeMinQuality(int, Foam::List<int>&) const in "/home/bmss/OpenFOAM/bmss-2.1.x/platforms/linux64GccDPOpt/lib/libdynamicTopoFvMesh.so"
#3  Foam::dynamicTopoFvMesh::swap3DEdges(void*) in "/home/bmss/OpenFOAM/bmss-2.1.x/platforms/linux64GccDPOpt/lib/libdynamicTopoFvMesh.so"
#4  Foam::dynamicTopoFvMesh::threadedTopoModifier() in "/home/bmss/OpenFOAM/bmss-2.1.x/platforms/linux64GccDPOpt/lib/libdynamicTopoFvMesh.so"
#5  Foam::dynamicTopoFvMesh::update() in "/home/bmss/OpenFOAM/bmss-2.1.x/platforms/linux64GccDPOpt/lib/libdynamicTopoFvMesh.so"
#6  
 in "/home/bmss/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64GccDPOpt/bin/pimpleDyMFoam"
#7  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#8  
 in "/home/bmss/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64GccDPOpt/bin/pimpleDyMFoam"
Aborted (core dumped)

The "dynamicMeshDict":

/*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM Extend Project: Open Source CFD        |
|  \\    /   O peration     | Version:  1.6-ext                               |
|   \\  /    A nd           | Web:      www.extend-project.de                 |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    location    "constant";
    object      dynamicMeshDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

//- Select the type of dynamicFvMesh
dynamicFvMesh           dynamicTopoFvMesh;

//- Select the type of motionSolver
motionSolverLibs ("libmesquiteMotionSolver.so" "libfvMotionSolvers.so");
solver                  mesquiteMotionSolver;

mesquiteOptions
{
    usePointDisplacement yes;
  
    //- Optimization metric
    optMetric               AspectRatioGamma;

    //- Objective function
    objFunction             LPtoP;

    //- Optimization algorithm
    optAlgorithm            FeasibleNewton;

    //- Termination criteria sub-dictionaries
    //- (takes default values if not specified)
    //-   Specifying an empty sub-dictionary
    //-   terminates with available options
    tcInner
    {
        absGradL2            1e-4;
        cpuTime              0.5;
        // lele: iterationLimit 10;
    }

    // tcOuter
    // {}

    //- For composite functions, two objectives need to be specified
    // firstFunction           LPtoP;
    // secondFunction          LInf;

    //- For scaled functions, scale and objective needs to be specified
    // scaleFunction        PMeanP;
    // scale                1.5;

    //- Power value for the LPtoP objective function
    pValue                  2;
    power                   2;

    //- Specify a tolerance for the surface-smoothing CG solver
    tolerance               1e-2;

    //- Specify number of CG sweeps for surface-smoothing
    nSweeps                 2;

    //- Specify slip patches for the motionSolver
    slipPatches
    {
        //wall;
        //oggetto;
    }

    //- Constrain surface mesh-motion on a specified cylinder
    cylindricalConstraints
    {
        //- Specify options per slip patch
    //    sideWall
    //    {
    //        axisPoint      (0.0 0.0 0.0);
    //        axisVector     (0.0 0.0 1.0);
    //        radius          1.0;
    //    }
    }

    //- Specify fixedValue patches for the motionSolver
    fixedValuePatches
    {
      oggetto
      {
          type            sixDoFRigidBodyDisplacement;
          centreOfMass    (0 0 0.2);
          momentOfInertia (0.000001 0.000001 0.000001);
          mass            0.01;
          rhoName         rhoInf;
          rhoInf          1000;  // needed only for solvers solving for kinematic pressure
          report          on;
          value           uniform (0 0 0);
          constraints
          {
            maxIterations 500000000;
            fixedLine1
            {
              sixDoFRigidBodyMotionConstraint fixedLine;
              tolerance 1e-6;
              relaxationFactor 0.7;
              fixedLineCoeffs
              {
                refPoint (0 0 0.2);
                direction (0 0 1);
              }
            }
          }
      }
    }
    
    //Other fixedValuePatch types can be found here:
    //src/dynamicMesh/meshMotion/fvMotionSolver/pointPatchFields/derived
    
    // angularOscillatingDisplacement
    // angularOscillatingVelocity
    // oscillatingDisplacement
    // oscillatingVelocity
    // surfaceDisplacement
    // surfaceSlipDisplacement

    //- Specify interval for surface smoothing
    surfInterval            1;
}

//- Options for dynamicTopoFvMesh
dynamicTopoFvMesh
{
    //- Should all options be made mandatory?
    //- Useful for first-time use.
    allOptionsMandatory no;

    //- Set run-time debug level [0-5]
    //debug               2;

    //- Specify the number of threads
    threads             1;

    //- Specify re-meshing interval
    //- Negative value implies no re-meshing
    interval            1;

    //- Specify whether the length-scale field
    //- should be dumped to disk
    dumpLengthScale     false;

    //- sliverThreshold specifies the
    //- quality criteria for sliver removal.
    sliverThreshold     0.35;

    //- Should the tool attempt to remove slivers
    //- that fall below the sliverThreshold value?
    removeSlivers       true;

    //- Skip mapping step. Useful while using
    //- this tool as a pre-processor
    // skipMapping         true;

    // Toggle edgeRefinement on/off
    edgeRefinement      no;

    //- Options for edge-bisection/collapse.
    //-   The edgeRefinement flag must be set for
    //-   the following options to have effect
    refinementOptions
    {
        collapseRatio   0.5;
        bisectionRatio  1.5;
        growthFactor    1.0;

        //- By default, existing boundary edge-lengths
        //- are used for length-scales.
        //- Length-scale can be fixed for certain patches.
        fixedLengthScalePatches
        {
            oggetto     0.2;
        }

        //- Avoid refinement on certain patches, if necessary
        noModificationPatches
        {
            inlet;
            outlet;
            wall;
            oggetto;
        }

        FreeSurfacePatch
        {
            oggetto;
        }
        
        
        //- Set floating length-scale values on certain patches
        freeLengthScalePatches
        {
            inlet;
            outlet;
            wall;
        }

        //- Limit lengthScales to specified values, if necessary
        // minLengthScale   0.1;
        // maxLengthScale   0.3;

        //- Field-based refinement options
        // fieldRefinement  gamma;
        // fieldLengthScale 0.005;
        // lowerRefineLevel 0.001;
        // upperRefineLevel 0.999;
        // maxRefineLevel   4;
        // meanScale        0.015;
    }

    //- If the number of modifications are to be limited, set this option
    // maxModifications   1000;

    //- Load custom libraries for metrics
    // tetMetricLibs      ("libtetMetrics.so");

    //- Tetrahedral mesh quality metric
    tetMetric          Knupp;

    //- Avoid 2-2 swapping on certain patches
    noSwapPatches
    {
      oggetto;
    }
}

// ************************************************************************* //

Attached are the two images that show the initial position and the final position nearly before the crash, due to a collapsed cell.

The bad news:

I still haven't been able to make the proper update to work. I've tried to use the following code, but without success (this is the patch for the code):

----------------- mesquiteMotionSolver/mesquiteMotionSolver.C -----------------
index 468be60..a482416 100644
@@ -4738,6 +4738,18 @@ void mesquiteMotionSolver::update(const mapPolyMesh& mpm)
         Info<< "Clearing out mesquiteMotionSolver for topo-changes" << endl;
     }
 
+    // pointMesh
+    if (Mesh_.thisDb().foundObject<pointMesh>(pointMesh::typeName))
+    {
+        const_cast<pointMesh&>
+        (
+            Mesh_.thisDb().lookupObject<pointMesh>
+            (
+                pointMesh::typeName
+            )
+        ).updateMesh(mpm);
+    }
+
     motionSolver::updateMesh(mpm);
 
     if (surfaceSmoothing_)

The crash occurs just the same, namely whenever the "boundaryConditions_()" are accessed after the mesh has been changed.

Other attempts I did in the past were, both in "mesquiteMotionSolver::update(...)":

• Force points to move:

      const_cast<pointMesh&>(boundaryConditions_().mesh())
          .movePoints(Mesh_.points());

• Force an update of the mesh:

      const_cast<pointMesh&>(boundaryConditions_().mesh())
          .updateMesh(mpm);

Both crashed while trying to make the move, presumably due to a non-existing mesh to be moved...

Best regards,
Bruno

Originally Posted by wyldckat

Hi Sandeep,

You're very welcome about the bug report! And many thanks for the fix and for the suggestions!

And no wonder I couldn't figure it out... I was only looking at the source code for "mesquiteMotionSolver"

Best regards,
Bruno

[wyldckat]

Originally Posted by daron

did you figure out the 6dof problem in this 'volvmov-topo' case

Quick answer: No.

Depending on what you want to do, perhaps it's best that you look into the Overset Mesh feature in OpenFOAM.com (not OpenFOAM.org which doesn't have this feature yet ).