[kjetil]

Originally Posted by ngj

I am not aware of any other solver. However, if you are can share your setup, I will try to give it a look and see, if I can spot where this un-physical pressure originates from.

Thanks. Well, I paste here what I believe is most crucial. If needed the entire case tree can be found online here http://folk.ntnu.no/kjetilbi/openfoam/nr5-auto2/ .

Content of 0/U:

internalField uniform (0 0 0);

boundaryField

{
inlet
{
type zeroGradient;
}
outlet
{
type zeroGradient;
}
pipewall
{
type fixedValue;
value uniform (0 0 0);
}
}

Content of 0/P:

internalField uniform 0;

boundaryField
{
inlet
{
type fixedValue;
value uniform 0;
}
outlet
{
type zeroGradient;
}
pipewall
{
type zeroGradient;

}
}

And a snippet from transportProperties:

// liq
phase2
{
transportModel Newtonian;
nu nu [0 2 -1 0 0 0 0] 1e-6;
rho rho [1 -3 0 0 0 0 0] 1000;
rho0 rho0 [1 -3 0 0 0 0 0] 1000;
psi psi [ 0 -2 2 0 0 ] 1e-05;
}

// gas
phase1
{
transportModel Newtonian;
nu nu [0 2 -1 0 0 0 0] 1.2e-5;
rho rho [1 -3 0 0 0 0 0] 1.2;
rho0 rho0 [1 -3 0 0 0 0 0] 1.2;
psi psi [ 0 -2 2 0 0 ] 1e-05;
}

pMin pMin [ 1 -1 -2 0 0 0 0 ] 0;

sigma sigma [ 1 0 -2 0 0 0 0 ] 0.07;

Basically, I only "know" the outlet pressure - which should be 1 atm. The inlet is not pressurized from outside, but instead the (negative) hydrostatic pressure is supposed "pull the water" from the outside reservoir.

I would very much appreciate any comments on how to improve this approach.

Thanks.

[ngj]

Hi Kjetil

I have looked at your setup, and the reason behind your strange results might be due to several things, or more likely a combination of the items below.

1. You specify a pressure at the inlet and a zero gradient at the outlet, however you do not specify the flux in any way. Hence the model is not sufficiently constrained. There are two possible solutions to this:
a: Specify an outlet pressure
b: Specify a uniform or varying velocity field at the inlet (use uniform to start with just to simplify things) and set the pressure at the outlet with a zeroGradient of the pressure at the inlet.
2. You specify that the minimum pressure is 0, and the pressure at the inlet is zero as well. You will not be able to drive any flow from the inlet to the outlet in that way, as pressures below zero (everywhere else than at the inlet), will be set to zero, i.e. no resulting net forcing on the fluid volume.

Regarding the above, I have a couple of comments (based on a assumption that the goal is to reach a steady state condition and one single phase):

ad 1a: Specifying a pressure gradient as forcing yields an asymtotic convergence, which can be shown mathematically (cannot recall the reference), hence the time to reach steady state is considerable.
ad 1b: Specifying the velocity at the inlet on the other hand is similar to enforce a certain flux, thus the time it will take to achieve steady state typically shorter, i.e. the development of the boundary layer.

These thought will probably be influenced by the introduction of a second phase, but my intuition tells me that the general idea is still valid.

Best regards and good luck,

Niels

[kjetil]

Thank you Niels,

on 1) : if I define an outlet pressure, wouldn't that also imply a pressure difference between inlet and outlet? Because I don't think I know that pressure, I believe I only know the outlet, which is ambient - or 1 atm. I think I tried setting an outlet pressure, and having zeroGradient as inlet - but then the flow started moving from the outlet and to the inlet.

[kjetil]

... porting the case files to use interFoam solver instead, still using single phase (water), yields excellent results! That is, pressure field looks the way it should. Even when I used a fixed inlet velocity in previous case and compressibleInterFoam, the "pMin" seems to overrule any 'p', and it fixes entire internal pressure to the 'pMin'. But then, choosing interFoam instead, the problem is solved. For single phase. Very odd. And I cannot find anything about this pMin anywhere in the userguide or here on the forum ...

[ngj]

Try setting pMin to some large negative value, e.g. -1e10, and see if you can solve the problem using compressibleInterfoam.

Bests

Niels

[kjetil]

There is something fishy going on here, because the behaviour of this solver is far from predictable. Regardless any low pressure - I tried both -2.5e5 (which I believe is just below the actual minimum pressure) and -1e10 - results in a continuing fluctuating pressure field. Like this: http://folk.ntnu.no/kjetilbi/openfoam/ani1.gif . The time step between each frame is 0.02sec.



Still, this is single phase, water only, and 1m/s inlet velocity. And to me this "shouldn't" be this difficult to set up ...

[kjetil]

I did some investigation in the solver itself, and "everything" seems fine - even the velocity field. The only exception is this pMin. And reading the source file and pEqn.H, I find this

p.max(pMin);

My C-skills are not that good to determine the exact purpose of this. But it is the only place that pMin occurs - at least in the files I have been looking through...

[ngj]

Hi Kjetil

One thought. Could it be that the compressibility needs to have the total pressure, hence a negative pressure would suggest something being un-physical. Try setting the pressure at the boundary to 1 atm and then rerun everything.

Good luck,

Niels

[kjetil]

Thanks Niels, I really appreciate your suggestions here.
Though, it seems like what pressure that is being stored, is set to the pMin, no matter what the other pressures are. Though the flow acts perfectly and the velocity field is as it is supposed to - the pressured used in the simulation must be right... it is just not stored properly.

May there be a way to disable this malfunctioning pMin feature you think? At the moment I am unable to continue a paused simulation using 'latestTime' .. as the pressure in the 'p' files is stored equivalent to the pMin, which then of course is wrong ...

[piprus]

Could any one of you explain me shortly what is the meaning or difference between rho and rho0 in the transportProperties?

[cwang5]

Hi guys,

I'm wondering if there's a version of the code for shipFoam that would work in OF-1.6? Thanks.

John

[Ralph M]

Hello all,

I'm trying to compile shipFoam under OF 1.7.1. I had to change some of the directories but I got an error which I don't understand:

EDIT: I got a version of shipFoam from http://openfoam-extend.svn.sourcefor...ydrodynamicIG/

It seems to work under 1.6 (gamma is changed into alpha1) but some work has to be performed to get it right for 1.7.1.

After changing p into p_rgh and changing some other files the wmake process goes well. However, when I run shipFoam I got the following error:

Spring coefficients are updated every 10 timesteps.
Selecting ODE solver RK

Starting time loop

Interface Courant Number mean: 0 max: 0
Courant Number mean: 0 max: 0
deltaT = 0.0011976
Time = 0.0011976

DICPCG: Solving for cellMotionUx, Initial residual = 0, Final residual = 0, No Iterations 0
DICPCG: Solving for cellMotionUy, Initial residual = 0, Final residual = 0, No Iterations 0
DICPCG: Solving for cellMotionUz, Initial residual = 0, Final residual = 0, No Iterations 0
Execution time for mesh.update() = 2.33 s
time step continuity errors : sum local = 0, global = 0, cumulative = 0
GAMGPCG: Solving for pcorr, Initial residual = 0, Final residual = 0, No Iterations 0
GAMGPCG: Solving for pcorr, Initial residual = 0, Final residual = 0, No Iterations 0
time step continuity errors : sum local = 0, global = 0, cumulative = 0
MULES: Solving for alpha1
MULES: Solving for alpha1
Liquid phase volume fraction = 0 Min(alpha1) = 0 Max(alpha1) = 0
smoothSolver: Solving for Ux, Initial residual = 0.999999, Final residual = 2.54205e-08, No Iterations 2
smoothSolver: Solving for Uy, Initial residual = 0.999999, Final residual = 2.53028e-08, No Iterations 2
smoothSolver: Solving for Uz, Initial residual = 0.999999, Final residual = 8.68022e-08, No Iterations 2
GAMG: Solving for p_rgh, Initial residual = 1, Final residual = 6.14819e-07, No Iterations 19
GAMG: Solving for p_rgh, Initial residual = 0.142886, Final residual = 6.76717e-07, No Iterations 12
Relaxation: p_rgh = 0.2
time step continuity errors : sum local = 3.12128e-15, global = 1.5957e-15, cumulative = 1.5957e-15
GAMG: Solving for p_rgh, Initial residual = 0.240736, Final residual = 6.02055e-07, No Iterations 16
GAMG: Solving for p_rgh, Initial residual = 0.285422, Final residual = 6.55771e-07, No Iterations 13
Relaxation: p_rgh = 0.2
time step continuity errors : sum local = 1.19739e-15, global = 6.0978e-16, cumulative = 2.20548e-15
GAMG: Solving for p_rgh, Initial residual = 0.171709, Final residual = 8.60057e-07, No Iterations 15
GAMGPCG: Solving for p_rgh, Initial residual = 0.209926, Final residual = 1.81723e-07, No Iterations 5
Relaxation: p_rgh = 0.2
time step continuity errors : sum local = 3.61807e-16, global = -2.70325e-18, cumulative = 2.20278e-15


--> FOAM FATAL ERROR:

request for volScalarField p from objectRegistry region0 failed
available objects of type volScalarField are

11
(
K
rho
p_rgh
alpha1_0
nu
gh
nu1
rho_0
nu2
alpha1
p_rghPrevIter
)


From function objectRegistry::lookupObject<Type>(const word&) const
in file /opt/openfoam171/src/OpenFOAM/lnInclude/objectRegistryTemplates.C at line 139.

FOAM aborting

#0 Foam::error:rintStack(Foam::Ostream&) in "/opt/openfoam171/lib/linuxGccDPOpt/libOpenFOAM.so"
#1 Foam::error::abort() in "/opt/openfoam171/lib/linuxGccDPOpt/libOpenFOAM.so"
#2 Foam::Ostream& Foam:perator<< <Foam::error>(Foam::Ostream&, Foam::errorManip<Foam::error>) in "/home/ralphmoolenaar/OpenFOAM/ralphmoolenaar-1.7.1/applications/bin/linuxGccDPOpt/shipFoam"
#3 Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const& Foam:bjectRegistry::lookupObject<Foam::Geometric Field<double, Foam::fvPatchField, Foam::volMesh> >(Foam::word const&) const in "/home/ralphmoolenaar/OpenFOAM/ralphmoolenaar-1.7.1/applications/bin/linuxGccDPOpt/shipFoam"
#4
in "/home/ralphmoolenaar/OpenFOAM/ralphmoolenaar-1.7.1/applications/bin/linuxGccDPOpt/shipFoam"
#5
in "/home/ralphmoolenaar/OpenFOAM/ralphmoolenaar-1.7.1/applications/bin/linuxGccDPOpt/shipFoam"
#6 __libc_start_main in "/lib/tls/i686/cmov/libc.so.6"
#7
in "/home/ralphmoolenaar/OpenFOAM/ralphmoolenaar-1.7.1/applications/bin/linuxGccDPOpt/shipFoam"
Aborted

I can't find a source for the problem, where do I have to look?

Regards,

Ralph

[Ralph M]

I already solved the problem; in some of the files there was still a reference to "p". The solver is now running smoothly, although I have some questions about the shipDict.

1) What is Amax
2) How is the damping defined? is it a number between 0 and 1?
3) What is the "weightFactor" supposed to do?

[Ralph M]

Hello all,

1) What is Amax
-->maximum acceleration (duh)
2) How is the damping defined? is it a number between 0 and 1?
--> this number is multiplied with the specified unit
3) What is the "weightFactor" supposed to do?
--> this is used to use the results from earlier calculations. 1st entry is weighting of current force/moment, 2nd of the previous time step and the 3rd entry of two timesteps ago.

The updated version of shipFoam can be found in the OF Ship Hydromechanics group http://www.cfd-online.com/Forums/gro...mechanics.html

[msbealo]

MarkC (and others?)

I've just read through this thread and have a couple of questions.

I'm interested in simulating yacht hulls resistance and lift with 2DoF (pitch and heave). I've only just started but I was using interDyMFoam with dynamicMotionSolverFvMesh and sixDoFRigidBodyMotionConstraint.

1) What does shipFoam do that interDyMFoam does not?
2) Has interDyMFoam been updated since shipFoam was conceived?
3) If I'm trying to simulate a towing tank, what would be the best approach.
4) (Slightly related) Should I be using fixedValue or movingWallVelocity on my hull patch?

Kind Regards,

Mark

[Ralph M]

Hello Mark,

1) The problem with interDyMFoam is that for some cases the pressure explodes. therefore shipFoam is developed; is does the same as interDyMFoam but uses a weighted pressure from (i think) previous time steps. In this way the solver is more stable. ShipFoam was first developed for OF 1.5 (dev?) but I tried to rewrite it for OF 1.7. I think there are still some issues with the pressure but at the moment I don't have time to finish this.

2) I don't know

3) That depends on your problem. If you are looking for steady state trim/sinkage I think it is the easiest way to keep the ship fixed in flow direction and to let the water have a velocity.

4) I would use buoyantPressure for the pressure patch and for the velocity
type movingWallVelocity;
value uniform (0 0 0);

Cheers,

Ralph

[Curro5150]

Hello, I am trying to do some multiphase ship hydrodynamics tests, and would like to try the shipFoam as I think it could save me quite a bit of work. However, I managed to compile the waveBC and the setHydrostatics on 1.6-ext, but I am having problems with the shipFoam solver. I tried to compile the ODE solver from 1.5, as suggested above, but it won't compile, most likely due to the different OF versions. Still, the error seems to be related with the ODE solver. Any clues/suggestions? Below you can find what I am getting:

Making dependency list for source file rotationMatrix/rotationMatrix.C
Making dependency list for source file motionODE/motionODE.C
Making dependency list for source file bodyMotion/bodyMotion.C
Making dependency list for source file writeMotionFile/writeMotionFile.C
Making dependency list for source file shipFoam.C
SOURCE=rotationMatrix/rotationMatrix.C ; g++ -m32 -Dlinux -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -O3 -DNoRepository -ftemplate-depth-40 -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/applications/solvers/multiphase/interFoam -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/src/transportModels -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/src/transportModels/incompressible/lnInclude -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/src/transportModels/interfaceProperties/lnInclude -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/src/turbulenceModels/incompressible/turbulenceModel -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/src/finiteVolume/lnInclude -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/src/dynamicMesh/dynamicMesh/lnInclude -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/src/meshTools/lnInclude -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/src/dynamicMesh/dynamicFvMesh/lnInclude -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/src/sampling/lnInclude -I/home/cfd02/OpenFOAM/cfd02-1.6-ext/applications/solvers/ODE2/lnInclude -IrotationMatrix -ImotionODE -IbodyMotion -IwriteMotionFile -IlnInclude -I. -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/src/OpenFOAM/lnInclude -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/src/OSspecific/POSIX/lnInclude -fPIC -c $SOURCE -o Make/linuxGccDPOpt/rotationMatrix.o
SOURCE=motionODE/motionODE.C ; g++ -m32 -Dlinux -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -O3 -DNoRepository -ftemplate-depth-40 -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/applications/solvers/multiphase/interFoam -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/src/transportModels -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/src/transportModels/incompressible/lnInclude -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/src/transportModels/interfaceProperties/lnInclude -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/src/turbulenceModels/incompressible/turbulenceModel -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/src/finiteVolume/lnInclude -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/src/dynamicMesh/dynamicMesh/lnInclude -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/src/meshTools/lnInclude -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/src/dynamicMesh/dynamicFvMesh/lnInclude -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/src/sampling/lnInclude -I/home/cfd02/OpenFOAM/cfd02-1.6-ext/applications/solvers/ODE2/lnInclude -IrotationMatrix -ImotionODE -IbodyMotion -IwriteMotionFile -IlnInclude -I. -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/src/OpenFOAM/lnInclude -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/src/OSspecific/POSIX/lnInclude -fPIC -c $SOURCE -o Make/linuxGccDPOpt/motionODE.o
SOURCE=bodyMotion/bodyMotion.C ; g++ -m32 -Dlinux -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -O3 -DNoRepository -ftemplate-depth-40 -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/applications/solvers/multiphase/interFoam -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/src/transportModels -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/src/transportModels/incompressible/lnInclude -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/src/transportModels/interfaceProperties/lnInclude -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/src/turbulenceModels/incompressible/turbulenceModel -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/src/finiteVolume/lnInclude -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/src/dynamicMesh/dynamicMesh/lnInclude -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/src/meshTools/lnInclude -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/src/dynamicMesh/dynamicFvMesh/lnInclude -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/src/sampling/lnInclude -I/home/cfd02/OpenFOAM/cfd02-1.6-ext/applications/solvers/ODE2/lnInclude -IrotationMatrix -ImotionODE -IbodyMotion -IwriteMotionFile -IlnInclude -I. -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/src/OpenFOAM/lnInclude -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/src/OSspecific/POSIX/lnInclude -fPIC -c $SOURCE -o Make/linuxGccDPOpt/bodyMotion.o
SOURCE=writeMotionFile/writeMotionFile.C ; g++ -m32 -Dlinux -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -O3 -DNoRepository -ftemplate-depth-40 -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/applications/solvers/multiphase/interFoam -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/src/transportModels -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/src/transportModels/incompressible/lnInclude -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/src/transportModels/interfaceProperties/lnInclude -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/src/turbulenceModels/incompressible/turbulenceModel -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/src/finiteVolume/lnInclude -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/src/dynamicMesh/dynamicMesh/lnInclude -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/src/meshTools/lnInclude -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/src/dynamicMesh/dynamicFvMesh/lnInclude -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/src/sampling/lnInclude -I/home/cfd02/OpenFOAM/cfd02-1.6-ext/applications/solvers/ODE2/lnInclude -IrotationMatrix -ImotionODE -IbodyMotion -IwriteMotionFile -IlnInclude -I. -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/src/OpenFOAM/lnInclude -I/home/cfd02/OpenFOAM/OpenFOAM-1.6-ext/src/OSspecific/POSIX/lnInclude -fPIC -c $SOURCE -o Make/linuxGccDPOpt/writeMotionFile.o
In file included from bodyMotion/bodyMotion.C:28:
bodyMotion/bodyMotion.H:63: error: cannot declare field ‘Foam::bodyMotion:de’ to be of abstract type ‘motionODE’
motionODE/motionODE.H:42: note: because the following virtual functions are pure within ‘motionODE’:
/home/cfd02/OpenFOAM/cfd02-1.6-ext/applications/solvers/ODE2/lnInclude/ODE.H:71: note: virtual Foam::scalarField& Foam::ODE::coeffs()
/home/cfd02/OpenFOAM/cfd02-1.6-ext/applications/solvers/ODE2/lnInclude/ODE.H:74: note: virtual const Foam::scalarField& Foam::ODE::coeffs() const
/home/cfd02/OpenFOAM/cfd02-1.6-ext/applications/solvers/ODE2/lnInclude/ODE.H:94: note: virtual void Foam::ODE::update(Foam::scalar)
In file included from bodyMotion/forceBalance.H:64,
from bodyMotion/bodyMotion.C:118:
bodyMotion/motionCalc.H: In member function ‘void Foam::bodyMotion::forceBalance()’:
bodyMotion/motionCalc.H:39: error: no matching function for call to ‘Foam::ODESolver::solve(motionODE&, int, double&, Foam::scalarField&, Foam::scalar&, Foam::scalar&)’
/home/cfd02/OpenFOAM/cfd02-1.6-ext/applications/solvers/ODE2/lnInclude/ODESolver.H:117: note: candidates are: virtual void Foam::ODESolver::solve(Foam::scalar&, Foam::scalarField&, Foam::scalarField&, Foam::scalar, const Foam::scalarField&, Foam::scalar, Foam::scalar&, Foam::scalar&) const
/home/cfd02/OpenFOAM/cfd02-1.6-ext/applications/solvers/ODE2/lnInclude/ODESolver.H:130: note: virtual void Foam::ODESolver::solve(Foam::scalar, Foam::scalar, Foam::scalar, Foam::scalar&) const
In file included from bodyMotion/forceBalance.H:94,
from bodyMotion/bodyMotion.C:118:
bodyMotion/motionCalc.H:39: error: no matching function for call to ‘Foam::ODESolver::solve(motionODE&, int, double&, Foam::scalarField&, Foam::scalar&, Foam::scalar&)’
/home/cfd02/OpenFOAM/cfd02-1.6-ext/applications/solvers/ODE2/lnInclude/ODESolver.H:117: note: candidates are: virtual void Foam::ODESolver::solve(Foam::scalar&, Foam::scalarField&, Foam::scalarField&, Foam::scalar, const Foam::scalarField&, Foam::scalar, Foam::scalar&, Foam::scalar&) const
/home/cfd02/OpenFOAM/cfd02-1.6-ext/applications/solvers/ODE2/lnInclude/ODESolver.H:130: note: virtual void Foam::ODESolver::solve(Foam::scalar, Foam::scalar, Foam::scalar, Foam::scalar&) const
make: *** [Make/linuxGccDPOpt/bodyMotion.o] Error 1
make: *** Se espera a que terminen otras tareas....

Regards,

Francisco

[JanL]

Hi,

I hope somebody is still following this thread as I do have exactly the same problem as in the post before by Francisco.
Does anybody have an answer on that problem?

Here is what I've done:
(1) I downloaded all files from this URL: http://openfoam-extend.svn.sourcefor...ydrodynamicIG/ and copied them into the folders in my OpenFoam-1.6-ext directory.
(2) Afterwards I went to /applications/solvers/shipFoam1.6.2 and typed wmake, which produced the same error as mentioned before.
(3) Then i tried to compile setHydrostatic with wmake which went through.
(4) At last I tried to compile waveBC which produced an error as dynamicFvMesh.H couldn't be found.

Can I simply copy the dynamicFvMesh from OF-1.5-dev e.g. into my OF-1.6-ext and compile it, so that waveBC has acces to this file? Does anybody know if that also solves the problem with the bodyMotion.o file as mentioned in the previous post when running wmake in the shipFoam-solver?

My original intention was to evaluate the shipFoam solver. Does anybody have more experience with this solver? Are there any papers about it (e.g. how does it perform against benchmarks, etc.)?


Best Regards


Jan

[Ralph M]

Dear Jan,

It has been a while since I used shipFoam for the last time. I think that your problems can be solved by changing the wmake files a bit; did you already had a look at the hydro-group (see link below in my signature)?

Furthermore I'm quit sure that no benchmarks have been performed for shipFoam. Can you send me a PM what you are planning to do and what your background is?

Cheers,

Ralph

[miliante]

Thank you Hrv,

but I have already seen and downloaded the "interFoamPressure" file. My problem is that, probably duo to boundary conditions, the field does not converge correctly and the p field is useless during simulation. The use of simmetryPlane on the bottom does solve correctly the p field, but the overall simulation diverges. And Using the fixed values for the pressure on the bottom and top for the p field give me much better results, but there is some kind of "pressure loss", leading to error further in the simulation, which I have not looked into very deeply.

Thanks again for the reply.

T.