[ibe]

I'd like to run a set of hulls using the DTCHull as a starting basis.

The approach I'm considering uses

1) a script to convert the points to a case*.stl file

2) where the script resets the waterline to z=0 based on the design displacement prior to outputing the .stl file.
This way, different hulls can be run without changing the blockMeshDict file.

I have two questions on the blockMeshDict file:



I ___believe the 12:15 vertices

(-26 -19 0.244)
(16 -19 0.244)
(16 0 0.244)
(-26 0 0.244)


define the vertices that air and water share at the interface.
I thought I'd set z_waterline from 0.244 to 0.0 and things would work out,
but the mesh creation is complaining.
also
I don't quite get how blockmeshdict maps the vertices to the blocks.
I've attached a .pdf with the vertices labeled that I"m using to sort things out.
Where are these blocks (each hex line ) assigned to atmo/inlet, outlet,bottom,side, midplane . blocks
(
hex (0 1 2 3 4 5 6 7) (42 19 50) simpleGrading (1 1 0.05)
hex (4 5 6 7 8 9 10 11) (42 19 50) simpleGrading (1 1 1)
hex (8 9 10 11 12 13 14 15) (42 19 4) simpleGrading (1 1 1)
hex (12 13 14 15 16 17 18 19) (42 19 4) simpleGrading (1 1 1)
hex (16 17 18 19 20 21 22 23) (42 19 40) simpleGrading (1 1 1)
hex (20 21 22 23 24 25 26 27) (42 19 20) simpleGrading (1 1 5)
);

[myozinaung]

Quick answer:
When you fully understand how blcokMeshDict works, your problems will be solved.

Those hex blocks are the blocks stacked on top of each other.
e.g. first hex --> 0 1 2 3 are lower corners of rectangular block, 4 5 6 7 are the upper corners.
Second hex block lies on top of first block. That is why they share the corners 4 5 6 and 7.
Those hex blocks define the mesh refinement in the z-direction of the whole domain including the free surface region. You will see third and fourth hex blocks are just below and above the water surface. So, if you change the draft of the ship, you should also move z coordinate of vertices 12:15. At the same time you should also adjust the other z coordiantes just below and above vertices 12:15 so that vertices 12:15 still lie between them.
That is only modifying the mesh. The actual water level is defined in setFieldDict. That has to be modified too.

The boundaries: inlet, outlet, bottom, etc. are defined using the faces of those stacked blocks.
e.g. inlet, outlet, midplane, side will use the faces of all six hex blocks while bottom and atmosphere(top) will only use the lower and upper faces of bottom hex block and top most hex block respectively.

I hope this helps you.

[pj_design]

Hello everyone,
thank you myozinaung for sharing your simulation setup! It is really helpfull and I was able to run your setup.


I have also tried to run the simulation with a different typ of hull, a planning hull. The problem that I am facing is, that I get very high vertical velocity oscillations at the beginning of the simulation. Similar to your setup but way larger and the solution diverges.


Has anyone experienced a similar behaviour? Things I have tried so far:


1. restrict linear motion in z-direction so that the hull can only rotate around the y-axes => soltion converges, but as soon as I allow linear motion in z-direction I get very high oscillations in z direction again



2. set up a velocity ramp at the inlet => problem persists


3. set the timestep to a very low value dt=1e^-5 => problem persists


4. use a linear damping constraint in dynamicMeshDict => problem persists


Has anyone got an idea how to dampen the rigidBody motions at the beginning of the simulation? Thank you for your help!

[myozinaung]

Have you tried increasing the damping coefficients in the dynamicMeshDict?

restraints
{
translationDamper
{
type linearDamper;
body hull;
coeff 8596; // THIS ONE
}

rotationDamper
{
type sphericalAngularDamper;
body hull;
coeff 11586;
}
}

And also these:

accelerationRelaxation 0.8; // Check the documentation --> to increase or decrease
accelerationDamping 0.9; // Check the documentation --> to increase or decrease

[pj_design]

Hallo myozinaung,
thank you for your fast reply! The damping restraints did not help. Even with absurd high numbers.


But accelerationRelaxation and accelerationDamping do help. At the moment I don't know how low I should go with these values, but I will give you a feedback after I have done some experimenting.


Thank you!

[myozinaung]

Originally Posted by pj_design

Hallo myozinaung,
thank you for your fast reply! The damping restraints did not help. Even with absurd high numbers.


But accelerationRelaxation and accelerationDamping do help. At the moment I don't know how low I should go with these values, but I will give you a feedback after I have done some experimenting.


Thank you!

Any progress or update?

[Shakhawat]

Originally Posted by myozinaung

The problem is now resolved. The resistance values are similar for both morphing and overset cases.
If you are interested in the case files, check the link below.

https://github.com/myozinaung/DTCMoving_Overset

I have gone through your files...while running overinterDyMFoam its saying error...I tried in openfoam 2312 version...the error is below-

--> FOAM FATAL IO ERROR: (openfoam-2206 patch=221104)
Unexpected EOF while reading dictionary entry

file: constant/dynamicMeshDict at line 100.

From static bool Foam::entry::New(Foam::dictionary&, Foam::Istream&, Foam::entry::inputMode, int)
in file db/dictionary/entry/entryIO.C at line 166.

FOAM exiting


Update- It was mistake of setting up the dynamicMeshDict...

[Shakhawat]

Originally Posted by pj_design

Hallo myozinaung,
thank you for your fast reply! The damping restraints did not help. Even with absurd high numbers.


But accelerationRelaxation and accelerationDamping do help. At the moment I don't know how low I should go with these values, but I will give you a feedback after I have done some experimenting.


Thank you!

Hello would you kindly mention your hull speed??
I have also decreased the value of relaxation and damping...