[jason]

Hi,

I managed to compile shipFoam with OF 1.5, no problems. Then I use blockMesh and snappyHexMesh with no problem. But when I try setFields I get this error from your 'jar' case.



/*---------------------------------------------------------------------------*\
| ========= | |
| \ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \ / O peration | Version: 1.5 |
| \ / A nd | Web: http://www.OpenFOAM.org |
| \/ M anipulation | |
\*---------------------------------------------------------------------------*/
Exec : setFields
Date : Feb 26 2009
Time : 12:16:50
Host : linux
PID : 15515
Case : /home/OpenFOAM/user-1.5/run/tutorials/shipFoamDemos/jar
nProcs : 1

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create mesh for time = 0

Reading setFieldsDict

Setting field default values
--> FOAM Warning :
From function void setFieldType(const fvMesh& mesh, const labelList& selectedCells,Istream& fieldValueStream)
in file setFields.C at line 100
Field gamma not found


wrong token type - expected word found on line 27 the label 0

file: /home/OpenFOAM/user-1.5/run/tutorials/shipFoamDemos/jar/system/setFieldsDict::de faultFieldValues at line 27.

From function operator>>(Istream&, word&)
in file primitives/strings/word/wordIO.C at line 77.

FOAM exiting

InterFoam works fine when I use setFields.

Have I done something wrong?

Thanks

Jason

[markc]

1. Replace the polyMesh in constant with the polyMesh as created in the last timeStep from snappyHexMesh.
2. Remove the timesteps created by SHM.
3. Copy gamma.org~ into gamma.
Now you can use setFields.

Succes,

Mark

[jason]

Hi,
Thanks, it's working now and its fantastic.
Out if interest, could this be used to predict the rotation of wind turbine?
Cheers
Jason

[bjr]

Perhaps Jason can answer this...

Do I simply put this in

applications/solvers/multiphase/shipfoam

and then run wmake?

[bjr]

I can answer my own question now. Yes. But in my case I have had to add "_region0" to some boundaries in the gamma files. Not sure if that is something specific to my setup or not.

[bjr]

This is what I get when I try to run shipFoam. I successfully ran setFields and made the changes mentioned above. Any ideas?

i3enhamin@i3enhamin-laptop:~/OpenFOAM/OpenFOAM-1.5/i3enhamin-1.5/run/shipFoamDemos/drop$ shipFoam
/*---------------------------------------------------------------------------*\
| ========= | |
| \ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \ / O peration | Version: 1.5 |
| \ / A nd | Web: http://www.OpenFOAM.org |
| \/ M anipulation | |
\*---------------------------------------------------------------------------*/
Exec : shipFoam
Date : Mar 02 2009
Time : 17:33:03
Host : i3enhamin-laptop
PID : 9951
Case : /home/i3enhamin/OpenFOAM/OpenFOAM-1.5/i3enhamin-1.5/run/shipFoamDemos/drop
nProcs : 1

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create mesh for time = 0

Selecting dynamicFvMesh dynamicMotionSolverFvMesh
Selecting motion solver: velocityLaplacian
Selecting motion diffusion: inverseDistance

Reading environmentalProperties
Reading field pd

Reading field gamma

Reading field U

Reading/calculating face flux field phi

Reading transportProperties

Selecting incompressible transport model Newtonian
Selecting incompressible transport model Newtonian
Selecting RAS turbulence model laminar
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
Courant Number mean: 0 max: 0
motionPatches :
1
(
Hull
)

Selecting ODE solver RK

Starting time loop

Courant Number mean: 0 max: 0
deltaT = 0.00119048
Time = 0.00119048

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() = 1.79 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 gamma
MULES: Solving for gamma
Liquid phase volume fraction = 0.599683 Min(gamma) = 0 Max(gamma) = 1
smoothSolver: Solving for Ux, Initial residual = 1, Final residual = 8.93232e-11, No Iterations 2
smoothSolver: Solving for Uy, Initial residual = 1, Final residual = 9.09726e-11, No Iterations 2
smoothSolver: Solving for Uz, Initial residual = 1, Final residual = 9.68685e-11, No Iterations 2
GAMG: Solving for pd, Initial residual = 1, Final residual = 7.12641e-07, No Iterations 11
GAMG: Solving for pd, Initial residual = 0.00155158, Final residual = 7.54051e-07, No Iterations 6
Relaxation: pd = 0.2
time step continuity errors : sum local = 3.79405e-10, global = 8.69136e-11, cumulative = 8.69136e-11
GAMG: Solving for pd, Initial residual = 0.48721, Final residual = 8.24422e-07, No Iterations 10
GAMG: Solving for pd, Initial residual = 0.00124111, Final residual = 6.03502e-07, No Iterations 6
Relaxation: pd = 0.2
time step continuity errors : sum local = 3.04151e-10, global = 6.96972e-11, cumulative = 1.56611e-10
GAMG: Solving for pd, Initial residual = 0.296932, Final residual = 5.01771e-07, No Iterations 10
GAMGPCG: Solving for pd, Initial residual = 0.000993064, Final residual = 3.62699e-07, No Iterations 3
Relaxation: pd = 0.2
time step continuity errors : sum local = 1.83076e-10, global = -7.82268e-12, cumulative = 1.48788e-10
#0 Foam::error::printStack(Foam:stream&) in "/home/i3enhamin/OpenFOAM/OpenFOAM-1.5/lib/linuxGccDPOpt/libOpenFOAM.so"
#1 Foam::sigSegv::sigSegvHandler(int) in "/home/i3enhamin/OpenFOAM/OpenFOAM-1.5/lib/linuxGccDPOpt/libOpenFOAM.so"
#2 Uninterpreted: [0xb7fa4420]
#3 Foam::tmp<foam::field<foam::innerproduct<foam::ten sor<double>, Foam::Vector<double> >::type> > Foam::operator&<foam::tensor<double>, double, 9, Foam::Vector<double> >(Foam::VectorSpace<foam::tensor<double>, double, 9> const&, Foam::UList<foam::vector<double> > const&) in "/home/i3enhamin/OpenFOAM/i3enhamin-1.5/applications/bin/linuxGccDPOpt/shipFoam"
#4 Foam::bodyMotion::forcesCalc() in "/home/i3enhamin/OpenFOAM/i3enhamin-1.5/applications/bin/linuxGccDPOpt/shipFoam"
#5 main in "/home/i3enhamin/OpenFOAM/i3enhamin-1.5/applications/bin/linuxGccDPOpt/shipFoam"
#6 __libc_start_main in "/lib/tls/i686/cmov/libc.so.6"
#7 Foam::regIOobject::writeObject(Foam::IOstream::str eamFormat, Foam::IOstream::versionNumber, Foam::IOstream::compressionType) const in "/home/i3enhamin/OpenFOAM/i3enhamin-1.5/applications/bin/linuxGccDPOpt/shipFoam"
Segmentation fault

[markc]

Hi All,

recommended installation directory is user/applications and then yes: wmake

snappyHexMesh adds the word region0 to patches. Remove this in polyMesh/boundary file

Jason,
I think you need a sliding mesh for wind turbine simulation. As far as I know this is not implemented in OF and not implemented in shipFoam. You probably have to look in the dev repos (svn).

Good luck,

Anyone any comments about the questions I placed here:
1. how to dynamically assign a variable number of objects?
2. shipFoam does not run in parallel.

Brgds,

Mark

[jason]

Hi,

Thanks Mark for the comment.

Ben, in addition to creating the gamma file, I think you also need to specify a pointMotionU in the 0/pointMotionU file. For example in the jar case I specified the walls to move (0 0.01 0) and that seemed to make it work. I haven't studied it in depth though.

DICPCG: Solving for cellMotionUx, Initial residual = 0, Final residual = 0, No Iterations 0

indicates that its not solving anything I think.

Jason

[markc]

No need to specify pointMotionU. The jar picks up a velocity because a constant force is specified in the shipDict. The first few time steps no mesh motion occurs because in shipDict startUpdate is set at a value (5 I believe), which is making the 6DOF solver to start once the fluid solver (the bare interDyMFoam) has done 5 time steps. Doing so some possible initialising spikes are avoided to enter the 6DOF solver.
Brgds,
Mark

[bjr]

How does this effort relate to the 6DOF solver that Hrvoje posted at

http://www.cfd-online.com/OpenFOAM_D...tml?1204813244

??

Thanks again,

[markc]

The additions making interDyMFoam shipFoam are for a large part based on snippets found on this forum, also that specific 6DOF solver from Hrv. Hrv helped me with other parts as well. However there are no classes which can be interchanged.

Brgds,

Mark

[bjr]

Wow Mark. So many thanks for this. I got the drop and the roll tutorials working, but not the jar (yet). I am going to join the foamToTecplot thread and mention an issue that came up in my otherwise correctly run cases. I want to look for some benchmark data for the sphere drop case and wondering if anyone know of any data sources offhand? I am looking into how other models have added turb models to them in an attempt to do the same here with shipFoam.

[juliuslein]

Hello Mark,

Thanks a lot for your solver. I'm working on a quite similar ship simulation with free surfaces. My plan was to implement the mesh movement as a linearized translation / rotation and not as a velocity. After determining the spring coefficient I wanted to translate / rotate the ship with the calculated force / moment.

In your old solvers you did nearly exactly what I'm looking for but now you're using the velocities and the differential equations. Are there any special reasons for it? I hope that I'm not wrong, but the direct translation / rotation should be a lot faster, shouldn't it?

Thanks for the answer

Regards, Julius

[albcem]

Hi Mark,

Good work indeed. Pertaining to your questions, I am not clear on the nature of the first question. If you could point to the exact lines where you are doing the dirty way of hard coding multiple objects, then I may be able to produce a comment.

On the parallel run crash issue, I remember reading somewhere interDyMfoam having parallel run issues as well. May be someone can comment based on that...

Can anyone recommend a debugging tool like gdbx to work with the wmake system? I am not able to utilize a C++ developer kit kind of application due to the non-standard form of the make files. With such tools we could look into the parallel failure problem more effectively...

Cem

[markc]

Hello Cem,

Regarding 1 (variable number of objects which are assigned during runtime):
I do not have the code at hand but this happens in the shipFoam.C file (which is basically the interDyMFoam.C). In the main scope, but before the time step loop, there is a part which assigns 4 objects of type bodyMotion, which are called body1, body2 etc. So there are always 4 objects of this type, initilized by the same basic constructor which reads the dictionary. Then further in the code some member functions are needed (e.g. initialize, forceCalc, forceBalance). These member functions are being called depending on the number of motionPatches which are declared in the dictionary.
This works but there must be a nicer way. As far as I understand you can assign a variable number of objects by using an array and pointers to the objects, but than you can not pass any variables to the objects. Quite a restriction, isn't it? But I am convinced that solutions exist for this ugly workaround.

Regarding 2: I found that the solver has no problems with parallel run! Possible problems are due to the way of decomposition. On the forum I read that in general decomposition for a moving mesh is more challenging than for static meshes. So if one experiences problems with parallel run with this solver, try some other settings for decomposition (I simply use the decomposePar utility with simple method).

Brgds,

Mark

[markc]

Hello Julius,


You can use the approach of setting a displacement on your motionPatch. The reasons I used velocity instead:

• The full motion ODE : sum F = m*x" + d*v' + k*x. Solving this using the OF ODE "toolbox" gives you velocity directly. So why integrating / differentiating before applying this on a motionPatch?
• In principle pd answers become unstable when the motionPatch gets an accelleration (not a constant velocity). Using velocity it is much easier to control the accelleration than using displacement. Though at the end I used relaxationFactors to control the unstability.

But, you can choose whatever you like.

Brgds,

Mark

[albcem]

Hello Mark,

I looked into the issue, it seems you would have to use the Standard Template Library (STL) features to construct an array of the bodyMotion objects. I tried implementing this, but I had issues with wmake recognizing the STL headers.

Relevant to this issue, I am a bit confused with the way you define your "body"'s. From what it looks, each of the 4 bodies is defined by a single patch and is an object that will move independently in solid body motion. So if you have a case for an object consisting of multiple patches, then the approach will fail or the body will deform and disintegrate... Do you agree?

I tend to define my bodies in terms of multiple patches as you can visualize the separate components, control local offsets and the type of boundary conditions assigned on them. Am I out of the norm in here?

Cem

[markc]

Cem, you are absolutely right. One motionPatch needs to be one body. I never realized that there is a need for approaches like yours. I wonder how one would need to couple different motionPatches into one single body for the motion equation. It will be possible but isn't it easier to make it one single body in the mesh and define regions/cell/face sets for the individual parts?

Brgds,

Mark

[albcem]

Mark,

You are right, it is a little more complex to deal with patches in the way I define them. However considering practical scenarios for design data, say for a yacht consisting of multiple faces/parts, when you bring in its STL mesh file into OpenFOAM the components will be directly interpreted as patches. If you bring in a GMSH volumetric mesh, the same happens. It seems you have another way to assign seperate components to seperate entities, but not patches from your last statement. I am not clear on it though.

Having to go with multiple patches per body, my approach is the following: Collect the individual forces and moments on the patches in the way I define them and then solve the motion equations on these sums and then assign the motions back to each individual patch. Body translations will be passed exactly, but body rotations will need to be processed a little before they can be passed to the patches...
Of course the dictionary needs to be defined appropriately.
What do you think?
Cem

[velan]

Dear Mark,

I have downloaded your source file and try to compile it. But i got the error message while compiling

[tetra@scram shipFoam]$ wmake
SOURCE=bodyMotion/bodyMotion.C ; g++ -m32 -Dlinux -DDP -Wall -Wno-strict-aliasing -Wextra -Wno-unused-parameter -Wold-style-cast -O3 -DNoRepository -ftemplate-depth-40 -I/home/tetra/OpenFOAM/OpenFOAM-1.5-dev/src/transportModels -I/home/tetra/OpenFOAM/OpenFOAM-1.5-dev/src/transportModels/incompressible/lnInclude -I/home/tetra/OpenFOAM/OpenFOAM-1.5-dev/src/transportModels/interfaceProperties/lnInclude -I/home/tetra/OpenFOAM/OpenFOAM-1.5-dev/src/turbulenceModels/RAS -I/home/tetra/OpenFOAM/OpenFOAM-1.5-dev/src/turbulenceModels/RAS/incompressible/lnInclude -I/home/tetra/OpenFOAM/OpenFOAM-1.5-dev/src/finiteVolume/lnInclude -I/home/tetra/OpenFOAM/OpenFOAM-1.5-dev/src/dynamicMesh/lnInclude -I/home/tetra/OpenFOAM/OpenFOAM-1.5-dev/src/meshTools/lnInclude -I/home/tetra/OpenFOAM/OpenFOAM-1.5-dev/src/dynamicFvMesh/lnInclude -I/home/tetra/OpenFOAM/OpenFOAM-1.5-dev/src/sampling/lnInclude -I/home/tetra/OpenFOAM/OpenFOAM-1.5-dev/src/ODE/lnInclude -IrotationMatrix -ImotionODE -IbodyMotion -IwriteMotionFile -IlnInclude -I. -I/home/tetra/OpenFOAM/OpenFOAM-1.5-dev/src/OpenFOAM/lnInclude -I/home/tetra/OpenFOAM/OpenFOAM-1.5-dev/src/OSspecific/Unix/lnInclude -fPIC -pthread -c $SOURCE -o Make/linuxGccDPOpt/bodyMotion.o
SOURCE=shipFoam.C ; g++ -m32 -Dlinux -DDP -Wall -Wno-strict-aliasing -Wextra -Wno-unused-parameter -Wold-style-cast -O3 -DNoRepository -ftemplate-depth-40 -I/home/tetra/OpenFOAM/OpenFOAM-1.5-dev/src/transportModels -I/home/tetra/OpenFOAM/OpenFOAM-1.5-dev/src/transportModels/incompressible/lnInclude -I/home/tetra/OpenFOAM/OpenFOAM-1.5-dev/src/transportModels/interfaceProperties/lnInclude -I/home/tetra/OpenFOAM/OpenFOAM-1.5-dev/src/turbulenceModels/RAS -I/home/tetra/OpenFOAM/OpenFOAM-1.5-dev/src/turbulenceModels/RAS/incompressible/lnInclude -I/home/tetra/OpenFOAM/OpenFOAM-1.5-dev/src/finiteVolume/lnInclude -I/home/tetra/OpenFOAM/OpenFOAM-1.5-dev/src/dynamicMesh/lnInclude -I/home/tetra/OpenFOAM/OpenFOAM-1.5-dev/src/meshTools/lnInclude -I/home/tetra/OpenFOAM/OpenFOAM-1.5-dev/src/dynamicFvMesh/lnInclude -I/home/tetra/OpenFOAM/OpenFOAM-1.5-dev/src/sampling/lnInclude -I/home/tetra/OpenFOAM/OpenFOAM-1.5-dev/src/ODE/lnInclude -IrotationMatrix -ImotionODE -IbodyMotion -IwriteMotionFile -IlnInclude -I. -I/home/tetra/OpenFOAM/OpenFOAM-1.5-dev/src/OpenFOAM/lnInclude -I/home/tetra/OpenFOAM/OpenFOAM-1.5-dev/src/OSspecific/Unix/lnInclude -fPIC -pthread -c $SOURCE -o Make/linuxGccDPOpt/shipFoam.o
In file included from bodyMotion/bodyMotion.C:1:
bodyMotion/bodyMotion.H:43: error: cannot declare field ‘Foam::bodyMotion:de’ to be of abstract type ‘motionODE’
motionODE/motionODE.H:14: note: because the following virtual functions are pure within ‘motionODE’:
/home/tetra/OpenFOAM/OpenFOAM-1.5-dev/src/ODE/lnInclude/ODE.H:71: note: virtual Foam::scalarField& Foam::ODE::coeffs()
/home/tetra/OpenFOAM/OpenFOAM-1.5-dev/src/ODE/lnInclude/ODE.H:74: note: virtual const Foam::scalarField& Foam::ODE::coeffs() const
/home/tetra/OpenFOAM/OpenFOAM-1.5-dev/src/ODE/lnInclude/ODE.H:94: note: virtual void Foam::ODE::update(Foam::scalar)
In file included from bodyMotion/forceBalance.H:34,
from bodyMotion/bodyMotion.C:96:
bodyMotion/motionCalc.H: In member function ‘void Foam::bodyMotion::forceBalance()’:
bodyMotion/motionCalc.H:15: error: no matching function for call to ‘Foam::ODESolver::solve(motionODE&, int, double&, Foam::scalarField&, Foam::scalar&, Foam::scalar&)’
/home/tetra/OpenFOAM/OpenFOAM-1.5-dev/src/ODE/lnInclude/ODESolver.H:126: 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/tetra/OpenFOAM/OpenFOAM-1.5-dev/src/ODE/lnInclude/ODESolver.H:135: note: virtual void Foam::ODESolver::solve(Foam::scalar, Foam::scalar, Foam::scalar, Foam::scalar&) const
In file included from bodyMotion/forceBalance.H:67,
from bodyMotion/bodyMotion.C:96:
bodyMotion/motionCalc.H:15: error: no matching function for call to ‘Foam::ODESolver::solve(motionODE&, int, double&, Foam::scalarField&, Foam::scalar&, Foam::scalar&)’
/home/tetra/OpenFOAM/OpenFOAM-1.5-dev/src/ODE/lnInclude/ODESolver.H:126: 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/tetra/OpenFOAM/OpenFOAM-1.5-dev/src/ODE/lnInclude/ODESolver.H:135: note: virtual void Foam::ODESolver::solve(Foam::scalar, Foam::scalar, Foam::scalar, Foam::scalar&) const
In file included from shipFoam.C:64:
bodyMotion/bodyMotion.H:43: error: cannot declare field ‘Foam::bodyMotion:de’ to be of abstract type ‘motionODE’
motionODE/motionODE.H:14: note: because the following virtual functions are pure within ‘motionODE’:
/home/tetra/OpenFOAM/OpenFOAM-1.5-dev/src/ODE/lnInclude/ODE.H:71: note: virtual Foam::scalarField& Foam::ODE::coeffs()
/home/tetra/OpenFOAM/OpenFOAM-1.5-dev/src/ODE/lnInclude/ODE.H:74: note: virtual const Foam::scalarField& Foam::ODE::coeffs() const
/home/tetra/OpenFOAM/OpenFOAM-1.5-dev/src/ODE/lnInclude/ODE.H:94: note: virtual void Foam::ODE::update(Foam::scalar)
/home/tetra/OpenFOAM/OpenFOAM-1.5-dev/src/finiteVolume/lnInclude/readPISOControls.H: In function ‘int main(int, char**)’:
/home/tetra/OpenFOAM/OpenFOAM-1.5-dev/src/finiteVolume/lnInclude/readPISOControls.H:3: warning: unused variable ‘nCorr’
make: *** [Make/linuxGccDPOpt/bodyMotion.o] Error 1
make: *** Waiting for unfinished jobs....
make: *** [Make/linuxGccDPOpt/shipFoam.o] Error 1



Can you help me to get rid out these errors.

- Velan