Problem for negative cell volumes and float point exception with overset mesh

Hi all,

I am simulating a planing boat with overset mesh (I gave up triying with moving deforming mesh). The simulation has a strong fluid-solid interaction. I generated the overset mesh already with no orphan cells and was able to simulate with a still boat. However, when I activate the dynamic mesh and assign the rigid body features with the udf and start running the simulation, it fails at a low number of iterations, say 200-300 (I need more than 50.000 iterations). The usual messages are "Floating point exception", which I understand is due to high unstable pressure formation around the hull so the forces soar up to infiite values, or "Negative cell volume detected", which I understand is because the time-step size is not large enough to allow the mesh to be updated before a cell pierces another cell, or because of a bad quality mesh.

I have tried setting the mesh implicit update every iteration, up to 50 iterations per time step, with a time step of 0.001 seconds, reducing the relaxation factors, activating solution stabilization for the pressure, triying with lower flow velocities (5 m/s) but nothing seems to work. This settings in fluent, makes me thing that is a low quality mesh issue, though I have triying refining and reducing high skewed cells with no positive results.

I am using polyhedral for the overset mesh around the hull and cutcell hexahedral cells for the background mesh, I attach a picture next. Note that the domain is very small because of low computational resources. I have seen everyone which simulate planing boats, use the same type of mesh for both the overset and background domains so a question arises: ¿Is it easier to achieve a smoother mesh motion and convergence in the calculation if both meshes have the same geometries for the purpose of simulating with overset meshes?

I also attach pictures of some monitors for pressure, lift and drag forces, momentum and some mesh motion variables. It seems the boat sinks (as expected), but rotation around CG_Z is zero (should be greater than zero).

After the simulation failed with "Negative cell volume detected", I plotted in the posprocessor isosurfaces with "cell volume error" and "low quality cells". I attach some pictures of that result too. The low quality elements have minimum ortogonalities of 0.08-0.1, which should be enough to perform the calculation.

Help! it was supposed the overset mesh was easier to setup than the moving deforming mesh

 

Comments

  • RobRob UKForum Coordinator
    edited February 10

    How is the mesh deforming if you're using overset? 

  • esgiraldopesgiraldop Member
    edited February 10
    I am wondering the same. I have not activated any dynamic remeshing method . Is'n it possible that a cell is somehow piercing another cell?
  • DrAmineDrAmine GermanyForum Coordinator
    edited February 10

    Check the quality of your mesh before running the case. Moreover increase the verbosity of overset and ensure that mesh motion does not exceed the length of the smallest cell at the overset interface.

  • jjjianjunjjjianjun Member
    edited February 17

    Hello,A few years ago I tried to simulate ship motion with dynamic remeshing method,But i failed,And last week I wanted to try with overset mesh,I got the same problem as you, Even if the time step is reduced, It still failed with "Negative cell volume detected",  So I think it is the compatibility problem between 6dof model and vof model in Fluent.

  • esgiraldopesgiraldop Member
    edited February 15

    Many thanks for your comments.

    I think I just have found how. The solution was to reduce the timestep size down to 0.0001 seconds together with using solution stabilization for the pressure around the rigid body, using mesh implicit update every single iteration and reducing relaxation factors for the mesh motion, momentum, pressure and volume fraction. The boat at least is moving, residuals are going down enough and pressure and force monitors are oscillating but seem to be converging though the simulation computational cost grew absurdly (A 3 seconds simulation could take me up to a month! I am figuring out how to move my simulations to a HPC machine).

    Thanks again for your help guys!

  • RobRob UKForum Coordinator
    edited February 17

    Sounds like the mesh was moving too quickly, once the system stabilises you may be able to increase the time step again. 

    jjjianjun - it's not model compatibility as such as solver requirements. When starting these models off you can get non-physical velocities if you put the hull in the wrong place and aren't careful with time step selection. 

  • esgiraldopesgiraldop Member
    edited February 18

    Actualization: The simulation is failing at around 0.1 seconds (1020-1030 timesteps) no matter what velocity I put in the inlet. 12, 10, 7 or 5 m/s, it always fails. I guess it is due to the boat got to a point where the it suddenly changes its orientation. Should I further reduce the timestep? the simulation would never finish with the computational resources I have!  . I will attach some pictures for you to see what is happening. Observe in the output file of fluent that the mesh is ok until timestep 1028, the timestep finishes and then after updating the mesh, somehow a few orphan cells appear. After 1 or 2 timesteps, the 11 orphan cells skyrockets to 20744 and then the simulation fails.

    I was thinking on starting the boat position in a orientation closer to final one, say 3° or 4° of trim angle. Should it yield better results?

  • kkanadekkanade Forum Coordinator
    edited February 18

    As Amine has pointed out, please check the mesh quality before run. The min orthogonal quality should be more than 0.1. 

    Some initial check you can do.

    As you are suing overset mesh, make sure that the mesh for two volumes (or domains) are separate and not connected at all. 

     

  • esgiraldopesgiraldop Member
    edited February 18

    What do you mean with the mesh for two volumes is separate and not connected at all? how do I check that? Could the bad orthogonal cells be causing the mesh failing even if the cells are not located in the overset connection region? I remember to have checked mesh quality, but the bad quality cells were relatively far away the overset boundaries

  • esgiraldopesgiraldop Member
    edited February 19

    Hi there!

    I plotted the orphan generated cells and this came out (see attached images). I think the mesh is apparently enough of high quality for the overset region to behave like that. The background and overset cells are hexahedrical and are very similar in size and the timstep was working perfectly. Why are this orphan cells appearing if the mesh seems to be ok?

Sign In or Register to comment.