View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0003885OpenFOAMBugpublic2022-09-14 13:342022-09-16 09:59
Reporterheinten Assigned Tohenry  
PrioritylowSeveritytrivialReproducibilityalways
Status closedResolutionno change required 
PlatformGNU/LinuxOSOtherOS Version(please specify)
Product Versiondev 
Summary0003885: meshToMesh crashes with displacement*Laplacian
DescriptionThe movingCone tutorial runs fine when it is set up with velocityComponentLaplacian in combination with meshToMesh (just as in the tutorial case). However, it always crashes when set up with displacementComponentLaplacian and an otherwise comparable setup.
Steps To ReproduceTake the movingCone tutorial case and change its setup to use point displacement instead of velocity:

(1) constant/dynamicMeshDict - change motion solver from velocityComponentLaplacian to displacementComponentLaplacian
(2) system/fvSolution - change solver from cellMotionUx to cellDisplacementx
(3) rename file 0/pointMotionUx to pointDisplacementx, adjust units and boundary type for moving wall to

    movingWall
    {
        type uniformFixedValue;
        uniformValue table
        (
            ( 0 0 )
            ( 1 1 )
        );
    }

This results in exactly the same movement as with pointMotionUx.

Start the Allrun script and observe the crash soon after the first meshToMesh interpolation took place at 0.0015 s.

I have attached the changed tutorial case as a zip folder.
TagsNo tags attached.

Activities

heinten

2022-09-14 13:34

reporter  

movingCone_displacement.zip (176,955 bytes)

peksa

2022-09-14 14:53

reporter   ~0012729

In your test case, the deformation does not yield one-to-one match between old and new "farfield" patch at the time of mapping. The original tutorial does not do that either, but the difference is smaller which is not enough to induce instability to the case.

The reason for this mismatch seems to originate due to Laplacian deformation is not moving the top boundary faces as much as the actual cone moves (expected, because that's how the laplacian mover works when the boundary condition is set to slip and you are a distance apart from the moving object). Then the new mesh is created by assuming that the patches move as much as the cone --> inconsistency.

You can quantify this inconsistency by looking at the log file at the time of mapping, which shows that interpolating weights are not achieving high values.

"""
Creating AMI between source patch farField and target patch farField using faceAreaWeightAMI
    AMI: Creating addressing and weights between 28 source faces and 26 target faces
    AMI: Patch source sum(weights) min/max/average = 0.777143, 1, 0.995187
    AMI: Patch target sum(weights) min/max/average = 0.685694, 1, 0.990178
"""

heinten

2022-09-14 20:27

reporter   ~0012730

I do not thing this is the issue as the interpolation weights are not much better when using velocityComponentLaplacian. For example at 0.0015 s, when the first interpolation takes place:

Creating patchToPatch between source patch farField and target patch farField using intersection
    patchToPatch: Calculating couplings between 28 source faces and 26 target faces
        Source min/average/max coverage = 0.820431/0.996317/1
        Target min/average/max coverage = 0.121718/0.972554/1

or

Creating patchToPatch between source patch farFieldMoving and target patch farFieldMoving using intersection
    patchToPatch: Calculating couplings between 50 source faces and 50 target faces
        Source min/average/max coverage = 0.159923/0.969465/1
        Target min/average/max coverage = 0.794586/0.995892/1

peksa

2022-09-15 14:19

reporter   ~0012731

I think you are right that there is something else involved as well.

I modified the mesh diffusion setup to achieve better interpolation result but still got a crash.

Then I modified the cuttingPlane setup to write cutplanes every time step. By doing this you can see that after meshToMesh execution, the cone jumps far ahead in one time step.

The "jump distance" is 0.0015m which is equal to displacement before meshToMesh execution. So I wonder if the displacement distance gets re-initialised to zero and then jumps immediately farther to respect the displacement boundary condition?????

henry

2022-09-15 18:51

manager   ~0012732

I have corrected the mesh geometry to make sure the wedge planes are exactly flat and changed the farFieldMoving to a fixed velocity which removes the NCC mapping error:
 
commit f8bb763b2941fadf2385f27e1067eba93ee2de80 (HEAD -> master, origin/master, origin/HEAD)
Author: Henry Weller <http://cfd.direct>
Date: Thu Sep 15 18:48:24 2022 +0100

    tutorials/modules/incompressibleFluid/movingCone: Corrected mesh and improved motion

Now

Courant Number mean: 0.0570316 max: 0.495054
Mapping to mesh meshToMesh_0.0015
Creating mesh-to-mesh addressing for region0 and meshToMesh_0.0015 regions using cellVolumeWeight
    Overlap volume: 1.73614e-09
Creating patchToPatch between source patch internal and target patch internal using intersection
Creating patchToPatch between source patch movingWall and target patch movingWall using intersection
    patchToPatch: Calculating couplings between 85 source faces and 85 target faces
        Source min/average/max coverage = 1/1/1
        Target min/average/max coverage = 0.999998/1/1
        Source average openness/error/depth/angle = 8.54039e-14/4.65177e-14/1.83621e-13/1.69031e-07
        Source max openness/error/depth/angle = 1.80411e-12/9.02056e-13/1.87186e-12/1.20742e-06
        272 couplings calculated in 0.006892s
Creating patchToPatch between source patch farFieldMoving and target patch farFieldMoving using intersection
    patchToPatch: Calculating couplings between 50 source faces and 50 target faces
        Source min/average/max coverage = 1/1/1
        Target min/average/max coverage = 1/1/1
        Source average openness/error/depth/angle = 4.49179e-15/5.39567e-15/1.23386e-15/0
        Source max openness/error/depth/angle = 1.42087e-14/1.39586e-14/4.7574e-15/0
        198 couplings calculated in 0.001874s
Creating patchToPatch between source patch fixedWall and target patch fixedWall using intersection
    patchToPatch: Calculating couplings between 35 source faces and 35 target faces
        Source min/average/max coverage = 1/1/1
        Target min/average/max coverage = 1/1/1
        Source average openness/error/depth/angle = 4.26705e-15/4.07481e-15/0/0
        Source max openness/error/depth/angle = 1.32745e-14/2.28696e-14/0/0
        70 couplings calculated in 0.003472s
Creating patchToPatch between source patch axis and target patch axis using intersection
Creating patchToPatch between source patch left and target patch left using intersection
    patchToPatch: Calculating couplings between 30 source faces and 30 target faces
        Source min/average/max coverage = 1/1/1
        Target min/average/max coverage = 0.999998/1/1
        Source average openness/error/depth/angle = 8.3805e-15/1.06439e-14/8.61054e-15/0
        Source max openness/error/depth/angle = 3.4769e-14/7.12727e-14/3.38172e-14/0
        60 couplings calculated in 0.002874s
Creating patchToPatch between source patch farField and target patch farField using intersection
    patchToPatch: Calculating couplings between 28 source faces and 26 target faces
        Source min/average/max coverage = 1/1/1
        Target min/average/max coverage = 1/1/1
        Source average openness/error/depth/angle = 1.59949e-15/2.30267e-15/1.32775e-15/0
        Source max openness/error/depth/angle = 8.50256e-15/6.44562e-15/3.61772e-15/0
        104 couplings calculated in 0.001109s
Creating patchToPatch between source patch back and target patch back using intersection
    patchToPatch: Calculating couplings between 1690 source faces and 1580 target faces
        Source min/average/max coverage = 1/1/1
        Target min/average/max coverage = 1/1/1
        Source average openness/error/depth/angle = 1.23373e-08/6.1689e-09/1.33753e-07/3.84057e-07
        Source max openness/error/depth/angle = 8.67157e-07/4.33579e-07/2.93014e-07/5.46682e-06
        11698 couplings calculated in 0.202124s
Creating patchToPatch between source patch front and target patch front using intersection
    patchToPatch: Calculating couplings between 1690 source faces and 1580 target faces
        Source min/average/max coverage = 1/1/1
        Target min/average/max coverage = 1/1/1
        Source average openness/error/depth/angle = 1.23373e-08/6.1689e-09/1.33753e-07/3.77789e-07
        Source max openness/error/depth/angle = 8.67157e-07/4.33579e-07/2.93014e-07/5.46682e-06
        11698 couplings calculated in 0.203408s

henry

2022-09-15 18:53

manager   ~0012733

Note that a simple displacement solver will not work with meshToMesh unless provision is made to reset the displacement to 0 after mapping as the motion restarts relative to the new mesh not the original mesh, of course.

peksa

2022-09-16 08:05

reporter   ~0012738

Makes sense.

henry

2022-09-16 09:59

manager   ~0012739

The displacementComponentLaplacian does not work reliably for this case but the velocityComponentLaplacian does which is why it was chosen.

Issue History

Date Modified Username Field Change
2022-09-14 13:34 heinten New Issue
2022-09-14 13:34 heinten File Added: movingCone_displacement.zip
2022-09-14 14:53 peksa Note Added: 0012729
2022-09-14 20:27 heinten Note Added: 0012730
2022-09-15 14:19 peksa Note Added: 0012731
2022-09-15 18:51 henry Note Added: 0012732
2022-09-15 18:53 henry Note Added: 0012733
2022-09-15 18:54 henry Priority normal => low
2022-09-15 18:54 henry Severity crash => trivial
2022-09-16 08:05 peksa Note Added: 0012738
2022-09-16 09:59 henry Assigned To => henry
2022-09-16 09:59 henry Status new => closed
2022-09-16 09:59 henry Resolution open => no change required
2022-09-16 09:59 henry Note Added: 0012739