[topspook]

I've been working on a multiphase case with 10 shallow draft barges (rigid bodies) connected with revolute joints and have run into an issue with the solver blowing up. I am using a deforming mesh as the cell count(~35 mil) is already massive for the resolution I'd like and using overset would likely present memory problems with my hpc resources. I am pretty sure that this blow up is due to added mass instability causing the coupling between the DFBI and fluid solver to oscillate the pressure from high to low and then exert a massive force on the rigid body. The added mass refers to the fluid that the floating body must displace when the rigid body moves, and the closer this mass is to the mass of the body the worse the instability. This is similar to how the mass of a pendulum is effectively higher when submerged in a fluid due to needing to displace fluid which increases the period.

I did find an openFoam solver that addresses this exact issue, although unfortunately it currently does not support multiple rigid bodies and is also in uncharted territory with regards to turbulence modeling which I am looking into.

A simple way to represent this issue is presented in this thesis (High-Fidelity Computational Modelling of
Fluid–Structure Interaction for
Moored Floating Bodies, Tristan de Lataillade 2019, excerpt attached) on moored floating bodies where the calculated force has a lag effect with the added mass force lagging behind 1 timestep which causes this pressure oscillation.



In the Lataillade paper he was able to directly modify the rigid body solver and that is an option with openFoam albeit very involved. I cannot directly modify the solver for STARCCM, but I am wondering if I can exploit this lag by 1 timestep effect to counteract the incorrect force calculations. If I estimated the added mass and then multiplied this with acceleration obtained from a 6DOF body report within STARCCM, and then added this calculated added mass force vector as a user defined coupling onto each of my rigid bodies respectively, could it work? Is there any more elegant approach to fixing this problem since I cannot directly modify the solver within STARCCM? Has anyone run into this issue before and been able to implement a fix?

openFoam solver that fixes added mass instability: https://github.com/FloatStepper/Floa...er/tree/master

Video detailing added mass instability and explaining the openfoam solver fix: https://www.youtube.com/watch?v=Nn3Zl1jnr5U

And yes I did already try extending the grid refinment down to the bottom and had the same results.