[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...

[gjosse]

Hello, I'm also lookingto the DTCHull case, and i'm wondering how those coefficient are calculated here :

translationDamper
{
type linearDamper;
body hull;
coeff 8596; ←
}

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

I've been looking for documentation, and i found various answer, like it's F/d (displacement) or it's a value in Ns/m according to openfoamwiki..
Could someone help me to understand ?
Thanks

[ufocfd]

did you manage to figure this out - how to calculate the damping coefficient?

[myozinaung]

Originally Posted by gjosse

Hello, I'm also lookingto the DTCHull case, and i'm wondering how those coefficient are calculated here :

translationDamper
{
type linearDamper;
body hull;
coeff 8596; ←
}

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

I've been looking for documentation, and i found various answer, like it's F/d (displacement) or it's a value in Ns/m according to openfoamwiki..
Could someone help me to understand ?
Thanks

These restraints are not essential for the final steady-state results. (Using damping forces and moments could help the convergence allowing to use the larger time steps.)

You can get the same result without them. But you may need to use a smaller time step and/or max Courant number to get a nice convergence.
Depending on the values of those coefficients the transient time history will differ.

My guess for approximating those values is to use a seakeeping program. (Inviscid: Damping_B33 for heave [translational], Damping_B55 for pitch [rotational]). Or heave and pitch decay experiments

Note: Extremely Large damping coefficient values could lead to unsteady convergence or divergence.

[gjosse]

Hello, thank you for your tips, it works well!
I'm now looking at the post-processing of the DTCHull case, and I was wondering about the forces' calculation.
Looking at the control dict, we set up rhoInf to water density, and didn't specify air density. And looking at the source code, the forces' calculation doesn't seem to take alpha.water as a variable.
It made me ask about the consistence of this forces program in a multiphase case.

Does someone know if openfoam makes the difference between the aerodynamic component and the hydrodynamic component on the hull?

Thanks,

[myozinaung]

Originally Posted by gjosse

Hello, thank you for your tips, it works well!
I'm now looking at the post-processing of the DTCHull case, and I was wondering about the forces' calculation.
Looking at the control dict, we set up rhoInf to water density, and didn't specify air density. And looking at the source code, the forces' calculation doesn't seem to take alpha.water as a variable.
It made me ask about the consistence of this forces program in a multiphase case.

Does someone know if openfoam makes the difference between the aerodynamic component and the hydrodynamic component on the hull?

Thanks,

I think interFoam uses the dynamic rho field when calculating the forces. It already considers the densities of both air and water as well as alpha.water. (without specifying rho, I guess you will get the same result)

Regarding the rhoInf, it is only used for non-dimensionalisation or normalisation. So it won't also affect the absolute values of forces.

I have alternative case files for DTCHullMoving in case you are interested.
https://github.com/myozinaung/DTCHullMovingEnhanced/

[RafiHasanat]

How it works?
by removing the 'restraints' part?

[myozinaung]

Originally Posted by RafiHasanat

How it works?
by removing the 'restraints' part?

Yes. Comment out or remove the restraints part. But you may need smaller time steps (smaller maxCo, maxAlphaCo) for stability and convergence.