View Issue Details

IDProjectCategoryView StatusLast Update
0001763OpenFOAMBugpublic2015-10-12 21:38
Reporteryuanchuanliu Assigned Tohenry  
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
PlatformGNU/LinuxOSUbuntuOS Version15.04
Summary0001763: Behaviour of sixDoFRigidBodyMotion when moveMeshOuterCorrectors is enabled
DescriptionIn the updatePosition function, velocity and angular momentum are calculated for the intermediate time step using acceleration and torque from last time step. However, when moveMeshOuterCorrectors is enabled, meaning that the function will be called for every outer iteration in one time step, the acceleration and torque are actually those from previous iteration rather than from previous time step, which contradicts the procedure in the reference paper.
However, if the acceleration and torque from previous time step are saved and used in the updatePosition function, the velocity and angular momentum will not change at all for all iterations in one time step, resulting in an unchanged centre of rotation thus the mesh will never move during one time step. I am not sure if I understand it right, but if this is true, it seems not necessary to employ an iteration loop.
Additional InformationBesides, force and torque seem to be always one time step behind the position and orientation of the body. At the start of a new time step, the position and orientation are from previous time step while the force and torque for this position and this orientation has not been calculated after the updatePosition function has been called (refer to the function void Foam::sixDoFRigidBodyMotionSolver::solve()), which means the acceleration a() and old velocity v0() in this statement belong to different time levels:
v() = tConstraints_ & (v0() + aDamp_*0.5*deltaT0*a());
Again, this is different from what is presented in the reference paper.
TagsNo tags attached.

Activities

henry

2015-06-24 16:10

manager   ~0004989

> it seems not necessary to employ an iteration loop

For many moving-mesh 6-DoF problems it is essential to iterate between the motion and the pressure for stability.

It is not clear from your description and additional information what changes you are proposing or what their effect would be. Have you already implemented your proposed changes and tested them on a range of 6-DoF cases with mesh-motion?

yuanchuanliu

2015-06-24 16:46

reporter   ~0004990

I understand it is essential to iterate for the sake of stability. What I was trying to say is that the method implemented in the code might not be proper for an iterative procedure. As far as I understand, according to the reference paper the position and orientation are calculated using the information from last time step and no force or momentum from the current time step will be used. So if everything is calculated correctly at the previous time step, the position at current time step should not be affected by the updated force.

I am sorry I do not have any proposal right now. Maybe I have been thinking wrong about it. If I do, please accept my apologies and close this issue.

henry

2015-06-24 16:53

manager   ~0004991

> What I was trying to say is that the method implemented in the code might not
> be proper for an iterative procedure.

The current method runs correctly for the cases tested but maybe it can be improved. I can leave this report open if you or others plan to analyse this further and test alternative strategies otherwise I will close it.

yuanchuanliu

2015-06-24 16:59

reporter   ~0004992

Do you have any benchmark cases you can share with us? Or any reference paper? Thank you for your time.

henry

2015-06-24 17:34

manager   ~0004993

You could play with the tutorials/multiphase/interDyMFoam/ras/floatingObject case. Currently it is constrained but if you allow it to float freely it becomes VERY sensitive to the details of the numerics.

henry

2015-06-24 17:35

manager   ~0004994

Also there is the tutorials/multiphase/interDyMFoam/ras/DTCHull case

yuanchuanliu

2015-06-24 17:38

reporter   ~0004995

Thank you for kindly pointing them out. Best wishes.

henry

2015-06-29 16:45

manager   ~0005015

Please re-open when you have an alternative formulation to test.

henry

2015-10-12 21:38

manager   ~0005390

commit 57c32b05036b9157ce6de2cd8fd1f1b5e8523368
Author: Henry Weller <http://cfd.direct>
Date: Mon Oct 12 21:27:42 2015 +0100

    sixDoFRigidBodyMotion: Time integration now switches between symplectic and Crank-Nicolson
    
    For explicit motion (and the first iteration of iterative motion
    correction) the 2nd-order symplectic motion integrator is used.
    
    For iterative correction a form of lagged Crank-Nicolson is used in
    which the current time-step values correspond to the current iteration.
    This converges to a 2nd-order implicit solution.

Issue History

Date Modified Username Field Change
2015-06-24 16:05 yuanchuanliu New Issue
2015-06-24 16:10 henry Note Added: 0004989
2015-06-24 16:46 yuanchuanliu Note Added: 0004990
2015-06-24 16:53 henry Note Added: 0004991
2015-06-24 16:59 yuanchuanliu Note Added: 0004992
2015-06-24 17:34 henry Note Added: 0004993
2015-06-24 17:35 henry Note Added: 0004994
2015-06-24 17:38 yuanchuanliu Note Added: 0004995
2015-06-29 16:45 henry Note Added: 0005015
2015-06-29 16:45 henry Status new => closed
2015-06-29 16:46 henry Assigned To => henry
2015-06-29 16:46 henry Resolution open => fixed
2015-10-12 21:38 henry Note Added: 0005390