[markc]

Hi Eric,

Yes he did and yes I am. But as usual, things are not as easy as I hoped. I tried to build the solvers Hrv sent me but these rely on OF 1.4.1-dev. I did not manage to build this on OF 1.5, nor did I to build 1.4.1-dev from source. So I am still not in full swing. However I am studying the solvers from Hrv and try to get them to work with less functionality, step by step. I am learning a lot from this and from his hints. However I still can't say what is going wrong in my case, it is probably much more than a small programming error.
I also found your Milan presentation on google. I was amazed about the functionality, as with Hrv's files. I really hope that once these solvers become accessible. It looks so much better than my trials.
Brgds,

Mark

Hi Mark,
is there a chance that you copy Hrv's solvers into this forum, with his approval, of course?

I experienced similar instabilities like you describe. I would like to test Hrv's suggestions on my OF 1.4.1-dev installation, and on OF-1.5, too, if possible.

Unless the distribution of that specific code is restricted, a few more developers sharing efforts by using this forum can probably accelerate the transition to OF 1.5.

By the way, has the group http://openfoamwiki.net/index.php/Si..._Hydrodynamics died? Is their email list alive although the link at the Wiki page says it doesn't exist?

Regards
Karl

[kjmaki]

Dear Karl and Mark,

There are competing implementations of total pressure in the OpenFOAM community that I have seen. 1, that I have seen in use by Hrv and Eric, uses a Poisson equation to solve for the total pressure, after the dynamic pressure is found in the usual manner. 2, the classical way of saying that p = pd + rho g z. If you look in 1.5, you will see that it is implemented in the classical way, no 2. Note, that this is only important for finding the force on the body, and not necessary for solving the fluid equations. Thus, if you are having difficulties in your solver, I don't think it is due to the way total pressure is calculated. If you are using the method of Hrv and Eric, they do solve another Poisson equation, and that could be a challenge. If this is the case, I would suggest trying the implementation that you can find in the 1.5 version of interFoam.

I that hope the Ship Hydro Group does not die. Is there a leader at present?

[markc]

Hello,
1.
You better ask Hrv or Eric. It is their solvers, their work and if it is not here, there will probably be a good reason.
However I am eager to know whats going wrong and also in applying the solvers, we have a lot of cases waiting to be run.
2.
I was not aware of the Ship Hydrodynamics group. Would be something for me as well.
3.
Did some tests again and with respect to hydrostatic pressure I am convinced that the proposed solvers are ok (both methods). Tried it without mesh motion and it works. The call in createFields to p shall contain the keyword pd, so that it is related to pd. I initially made the mistake to relate it to mesh. This simply works, I found out but probably Eric and Hrv know already for long this works. The problem comes in after the first mesh motion. This is most probably due to the way I implement mesh motion. I based my solvers on the ones from Thiago, as found in this thread and he experienced the same errors.
Today I found something again: without meshmotion, U on the motion patch stays 0. After the first mesh motion this patch gets a certain velocity. In my case this velocity was pretty high. My solver calculates mesh displacement but this is divided by a small dT, yielding a pretty substantial velocity. If I have time again I will go after this and try to calculate motionU.

Someday it will work!

Brgds,

Mark

[kjmaki]

Hi Mark,

In create fields, give pd + rho*gh to the p field, so that you get the correct hydrostatic force on the total pressure field at the first time step. This may help the start up problems on your equation of motion solver.

Kevin

[carsten]

Dear Mark,

though I'm not experienced with OpenFOAM, I'd like to share some experience which I've made with Comet (CD-Adapco), when simulating floating objects. Maybe it helps you in some way. So, here are my comments:

If you update the mesh only every n-th timestep, a spike in the pressure field is unevitable as a reaction to the sudden displacement. And thus, the velocity field will react on this with a spike, too.

We solved this problem by computing the forces on the hull every (n-1)-th timestep (n~=10) and moving the body every n-th timestep (and ignored the spikes). I tried also to compute the forces and move the body every timestep, but this approach is not generally stable. Thus, a lot of underrelaxation for the motion was required.

Good luck,

Carsten

[markc]

Hello Carsten,

Thanks for your input. Basically you are doing the same as I did. But like we are doing it is likely to cause instability crashes, it may cost a lot more time and you are still not able to perform calculations on transient situations, like e.g. motions in a seaway.
However, it must be possible to do it in a more elegant way, it has been shown by Hrv.

Brgds,

Mark

[musahossein]

Gentlemen:

Does anyone know whether a file of displacements can be read by openfoam for 2d slohing case? Does Open Foam have that feature?

Thanks

[markc]

Musaddeque,

Could you be a little more specific?

Mark

[musahossein]

Mark:
Thanks for your response. The 2D tank sloshing problem oscillations are produced by functions. But what I am trying to do is produce sloshing based on discreet data that you cannot necessarily assign a function to. For example suppose I move the tank 0.1 meter to the left at t=0, and then 0.5 meter to the right from the last position at time t=1 and so on. If I have a ascii / text file of such values where I have discreet displacements at fixed time increments, is it something open foam can read?

[markc]

Musaddeque,

One of the interDyMFoam tutorials (sloshingTank3D6DoF) has a dynamic mesh dict which calls SKA. This class is intended to read in a file with discrete data. The solver then integrates between the given values for intermediate time steps. There is also a C++ source code file in the tutorial used to create such a data file. With a little bit of programming experience it should be possible to modify it to output your discretised motion versus time. Note that the solver integrates for intermediate time steps so you will propbably never obtain a truly step response, but I think you would not want that too, it may give stability problems...
Hope this helps you a bit further,

Mark

[musahossein]

Mark:

Your time and effort to look this up and let me know is very much appreciated.

Thanks

Musa

[musahossein]

Gentelmen:

I had a post under another solver. however I feel it would be more appropriate here as it has to do with inerDyMFoam and not interFoam. The post is at the following link:

http://www.cfd-online.com/cgi-bin/Op...2064#POST32064

Any comments suggestions would be greatly appreciated. Thanks

[markc]

Hello All,

Here it is: a solver which can be used to solve moving ships-problems (and many others), like roll decay, falling objects.
It is basically interDymFoam, extended with some classes which have the purpose to solve the ODE F=m*x" + damping*x' + spring*x for all 6 DOF (or less if the user wants).
Forces can be external forces, gravity and pressure forces.
The solver is partly constructed with the help of snippets found on this forum.
The problems which have been discussed in this thread (unstable pressure field) are find to be caused by accellerations of the moving object. So if your body is moving at constant speed, pressure will be perfectly stable. In order to obtain usefull pressurefield with accellerating bodies, 2 damping methods are implemented:
1. relaxationFactors in pdEqn
2. using weighting factors on the forces which are calculated with the pressure field.

Both are user input.

There are yet two problems, 1 minor and 1 less minor:
1. (minor). The classes which are added have the purpose to set pointMotionU for the respective motionPatch. One object corresponds with one motionPatch. However I do not know how to decide at runtime how many objects are to be created. This is decided using a dictionary (shipDict). In C++ I found out how to assign variable memory and objects (by using an array) but than one is not able to pass arguments/variables. I found a very ugly workaround by hard coding 4 objects which are also constructed at runtime and then further with if statements it is decided how many of those half-filled objects are further being used. Any ideas?
2. Less minor: the solver fails in parallel, although it is completely derived from interDyMFoam. With different cases it fails in different stadia. I hope anyone can comment on this.

Hope this solver is useful for others and others can possibly correct the above issues.




Brgds,

Mark

[markc]

The attachments:
shipFoam.tar.gz
shipFoamDemos.tar.gz

Mark

[markc]

O ja,

the demo cases are run using:
1. blockMesh
2. snappyHexMesh
3. setFields
4. shipFoam

Mark

[markc]

O ja,

the demo cases are run using:
1. blockMesh
2. snappyHexMesh
3. setFields
4. shipFoam

Mark

[tian]

Hi Mark

good job. I fell sorry that I can not test your case with your solver. During compiling I got this erros:

bodyMotion/motionCalc.H:15: error: no matching function for call to 'Foam:DESolver::solve(motionODE&, int, double&, Foam::scalarField&, Foam::scalar&, Foam::scalar&)'

Maybe you can send me your BINs (64-bit)?

Thanks a lot
Thomas

[markc]

Hi Thomas,

are you using OF1.5? I do, and 32 bit.

Brgds,

Mark

[tian]

Hi Mark,

I use OF1.5-dev version and 64bit. I am very interested in ship simulation.

Bye
Thomas