|
|
|
|
|
Have you tested the Newmark scheme for the rigidBodyModel? |
|
|
With the default parameters Newmark and CrankNicolson are exactly the same scheme. I have run the rigidBodyModel with the Newmark scheme. I see the same results as for the CN. |
|
|
- sixDofRigidBodyMotion (symplectic): the nonlinear motion is captured correctly What are the problems with this method? I would expect it to be most appropriate for your case. |
|
|
Thanks for your effort on this. Yes, the symplectic scheme when applied with sixDofRigidBodyMotion can capture the nonlinear motion correctly in this test case. However, I believe you must have a reason for introducing the CN/Newmark scheme in the package. If you think there are bugs in these solvers, we should fix them. Here the symplectic scheme works OK for the sixDofRigidBodyMotion but not for the rigidBodyModel. |
|
|
I do not think there are bugs in the CN/Newmark schemes but if you believe there are and can provide patches to fix them I would be happy to apply them. I am not sure why the symplectic scheme in the rigidBodyModel does not behave the same as for the sixDofRigidBodyMotion, could you investigate and provide any changes necessary? |
|
|
I agree that the problem with CN/Newmark schemes can not be fixed straight away. The symplectic scheme in the sixDofRigidMotion has problems with stability when the coupling between the flow solution and the motion is strong. This tiny modification (pls. see the patch attached to this note) should help to improve the stability of the symplectic scheme. symplectic.patch (2,086 bytes) |
|
|
> I agree that the problem with CN/Newmark schemes can not be fixed straight away. I do not see anything wrong with these schemes or that they need to be "fixed" in anyway. I think they are just not appropriate for your case unless you use a very small time-step (this is conjecture). > This tiny modification (pls. see the patch attached to this note) should help to improve the stability of the symplectic scheme. Does it help? It appears that you have enabled the use of the symplectic scheme with outer-iterations which I am not sure is consistent with the formulation of the scheme. |
|
|
From what I have seen in my tests I will never use CN/Newmark in a case where the nonlinear interaction between the rotational dof is expected. For the symplectic scheme I have overlooked the existent of the underrelaxation in the acceleration. Indeed it is not consistent to reset the 6dof solution due to the underrelaxation. However, simply allow the outer-iterations with the resetting will do just fine because the vel. & pos. at the previous time step will not be updated until a new call to newTime(). The following is the algorithm for the symplectic scheme (without the translational dof) //1. compute ang.vel. at haft step using acc. at 0 pi() = pi0() + 0.5*deltaT0*tau0(); //2. compute orientation at full time step using the haft step vel. Tuple2<tensor, vector> Qpi = rotate(Q0(), pi(), deltaT); pi() = Qpi.second(); //3. compute acc. at full time step (this is where the outer-iter. makes a difference) updateAcceleration(fGlobal, tauGlobal); //4. compute vel. at full time step pi() += 0.5*deltaT*tau(); In steps 1 & 2 the solution will be recomputed using the previous state (0) In steps 3 & 4 the outer-iteration will make sure the the acceleration is consistently computed from the flow solution at a full time step. In my tests this tiny modification is making a huge difference. Attached is the results of one of the cases where the outer-iteration really helps !!! Btw, why is there aDamp() in the algorithm? I cannot imaging why anyone would want to reduce/amplify the acceleration by a constant amount like this. symplectic-2iters.png (29,606 bytes) |
|
|
Thanks for the analysis, I will apply the change. > Btw, why is there aDamp() in the algorithm? Useful for stabilizing runs during the early stages of motion development or to aid convergence to a steady-state. However, I would not choose the symplectic scheme for steady-state runs, the Newmark scheme is more robust, stable and convergent. |
|
|
sorry, i've noticed a critical typos in my previous post. it should have been ... allow the outer-iterations "without" the resetting ... and thank you for considering pushing this change into the code. |
|
|
The algorithm you propose only updates pi() and is missing the application of the constraints so I cannot apply it. Could you clarify which part of the algorithm you have changes because apart from the missing functionality it appears to be the same. |
|
|
Please see the patch below. diff --git a/src/sixDoFRigidBodyMotion/sixDoFSolvers/symplectic/symplectic.C b/src/sixDoFRigidBodyMotion/sixDoFSolvers/symplectic/symplectic.C --- a/src/sixDoFRigidBodyMotion/sixDoFSolvers/symplectic/symplectic.C +++ b/src/sixDoFRigidBodyMotion/sixDoFSolvers/symplectic/symplectic.C @@ -67,14 +67,6 @@ void Foam::sixDoFSolvers::symplectic::solve scalar deltaT0 ) { - if (!firstIter) - { - FatalErrorIn("sixDoFSolvers::symplectic::solve") - << "The symplectic integrator is explicit " - "and can only be solved once per time-step" - << exit(FatalError); - } - // First simplectic step: // Half-step for linear and angular velocities // Update position and orientation |
|
|
That just removes the check for the use of symplectic scheme with outer iteration; is that sufficient? Is no other change necessary? |
|
|
yes, simply remove this check and allow the outer iteration is sufficient c.f. note ~0007039 |
|
|
Resolved in OpenFOAM-dev by commit 7ae0766a311fd09377ce97bcc83d73915cd9274c |
- Anonymous
