[blaise]

Hello all,

I am currently trying to integrate waves2Foam with the overInterDyMFoam solver in OpenFOAM-v1712. I have previously achieved to do the same with interDyMFoam, so I thought I could give this also a try.
My solver (overWaveDyMFoam) compiles successully, but when I run a simple case with a floating box, I get the following error in the very first time step:

Starting time loop

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

PIMPLE: iteration 1
forces forces:
    Not including porosity effects

6-DoF rigid body motion
    Centre of rotation: (10.08 -0.0999727951411 0.25)
    Centre of mass: (10.08 -0.0999727951411 0.25)
    Orientation: (1 -1.6653719982e-09 -2.12718304828e-20 1.6653719982e-09 1 -1.36991915347e-21 2.1271830485e-20 1.36991911805e-21 1)
    Linear velocity: (0 0.00544097178199 0)
    Angular velocity: (2.73983829821e-19 -4.25436609694e-18 3.33074399639e-07)
    Euler angles: (7.84905857681e-20 -1.21878610918e-18 9.54187868158e-08)

inverseDistance : detected 1 mesh regions
    zone:0 nCells:318568  voxels:(34 34 34) bb:(4.67999600671 -1.00000399329 -3.99329437933e-06) (8.10000399329 1.00000399329 0.500003993294)
Overset analysis : nCells : 318568
    calculated   : 300000
    interpolated : 0 (interpolated from local:0  mixed local/remote:0  remote:0)
    hole         : 18568

Execution time for mesh.update() = 1 s
smoothSolver:  Solving for alpha.water, Initial residual = 0, Final residual = 0, No Iterations 0
Phase-1 volume fraction = 0.5  Min(alpha.water) = 0  Max(alpha.water) = 1
MULES: Correcting alpha.water
[3] 
[3] 
[3] --> FOAM FATAL ERROR: 
[3] object of type N4Foam12waveTheories10waveTheoryE is not allocated
[3] 
[3]     From function T* Foam::autoPtr<T>::operator->() [with T = Foam::waveTheories::waveTheory]
[3]     in file /usr/local/OpenFOAM/OpenFOAM-v1712/src/OpenFOAM/lnInclude/autoPtrI.H at line 211.
[3] 
FOAM parallel run aborting
[3] 
[3] #0  Foam::error::printStack(Foam::Ostream&)-------------------------------
An MPI process has executed an operation involving a call to the
"fork()" system call to create a child process.  Open MPI is currently
operating in a condition that could result in memory corruption or
other system errors; your MPI job may hang, crash, or produce silent
data corruption.  The use of fork() (or system() or other calls that
create child processes) is strongly discouraged.  

The process that invoked fork was:

  Local host:          ofslave44 (PID 20874)
  MPI_COMM_WORLD rank: 3

If you are *absolutely sure* that your application will successfully
and correctly survive a call to fork(), you may disable this warning
by setting the mpi_warn_on_fork MCA parameter to 0.
--------------------------------------------------------------------------
 addr2line failed
[3] #1  Foam::error::abort() addr2line failed
[3] #2  Foam::waveAlphaFvPatchScalarField::signedPointToSurfaceDistance(Foam::Vector<double> const&) const addr2line failed
[3] #3  Foam::waveAlphaFvPatchScalarField::signedPointToSurfaceDistance(Foam::Field<Foam::Vector<double> > const&, Foam::Field<double>&) addr2line failed
[3] #4  Foam::convexPolyhedral::divideFace(long const&) addr2line failed
[3] #5  Foam::waveAlphaFvPatchScalarField::updateCoeffs() addr2line failed
[3] #6  Foam::mixedFvPatchField<double>::evaluate(Foam::UPstream::commsTypes) addr2line failed
[3] #7  Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::Boundary::evaluate()
[3] #8  void Foam::MULES::correct<double, Foam::geometricOneField, Foam::zeroField, Foam::zeroField>(double const&, Foam::geometricOneField const&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>&, Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::zeroField const&, Foam::zeroField const&)
[3] #9  ?
[3] #10  main
[3] #11  __libc_start_main addr2line failed
[3] #12  ?
--------------------------------------------------------------------------
MPI_ABORT was invoked on rank 3 in communicator MPI_COMM_WORLD 
with errorcode 1.

NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
You may or may not see output from other processes, depending on
exactly when Open MPI kills them.

Can anyone point me in a helpful direction on what is going wrong here?

Thank you!

Pascal.

[ngj]

Hi Pascal,


Interesting that you try waves2Foam with the overset functionality. It has long been on my to-do list.


Based on the error, I guess that you have forgotten to modify createFields.H or include the required header files in the *.C file.


An alternative explanation, on second thought, is that the overset mesh functionality modifies some of the member variables in the boundary conditions. If this deletes all pointers, it means that you get the missing autoPtrI-error. One possible work-around is the substitute waveAlpha with zeroGradient and waveVelocity with zeroGradient and rely solely on the relaxationZones.



If you make it work, I would very much like you to share some first experiences here in this thread.



Kind regards,


Niels

[blaise]

Hi Niels,

I am really happy to have you in this discussion!
I can confirm that things start to run correctly when I substitute waveAlpha and waveVelocity with zeroGradient types. I run the simulation for a few seconds and it seems to behave well...

I attach my little test case and my overWaveDyM solver as it has evolved so far. I do not know what else should be modified in the createFields.H file, so any hint is appreciated. It would be great if you had the chance to check the solver and the test case (to eliminate a possibly wrong setup).

I tried to track the error further down and found, that things run until
psi.correctBoundaryConditions();

is called in the MULES correction in file
OpenFOAM-v1712/src/finiteVolume/fvMatrices/solvers/MULES/CMULESTemplates.C

Beyond this point I am not able to follow the code any further... unfortunately...

@InterestedFolks: The attached solver files actually contain my waveDyMFoam solver as well, so everything should go to
waves2Foam/applications/solvers/solvers1712_PLUS

I am looking forward to reading your comments!

Best regards,

Pascal.

[ngj]

Interesting. It seems that something is not working in the boundary conditions.


I will try to get time to look at the bug; however, no promises at present.


Kind regards,


Niels

[blaise]

Hi Niels,

I am looking forward to your findings!
With regard to your request for sharing first experiences - have a short laugh with the attached animation of the case I posted before. It does not behave well at all... :-/ I suppose I have some boundary condition settings wrong...

https://drive.google.com/file/d/1w1H...ew?usp=sharing
(hope this works)

Anyway, next week I will be out of office, so I will not be able to respond to postings... just in case.

Best regards,

Pascal.

[ngj]

Hi Pascal,


That is actually pretty funny! My first guess is that your acceleration relaxation is too large or you are using too few pimple-type corrections per time step.


Are you initializing with setWaveFields? If yes, does it seem to recognize the multiple domains?



Kind regards,


Niels

[blaise]

Hi Niels,

back again...

As often, it turned out that the error sits in front of the screen... ;-)

On close inspection of the boundary conditions, I found some mistakes. Now things run smoothly (at least for the first 10 seconds) and the floating body does not seem to be jumping out of the domain again.

Anyway, the problem with the boundary condition for alpha.water at the inlet still persists. Things only work when I set the inlet condition to:

type            zeroGradient;

I attached the corrected case, for those who are interested.

Here is an animation of the corrected case:

https://drive.google.com/open?id=1KG...ihI3K5DEbykeGk

I am looking forward to hearing from you about the boundary condition issue!

Thank you and best wishes,

Pascal.

[shiyu]

Hi Pascal and Niels,
I am facing the same bug now. Do you find it out?
I can run correctly when I substitute waveAlpha and waveVelocity with zeroGradient types, as you said.
However, I am just wondering that does this subsitute that rely solely on the relaxationZones affect the finally wave generation? Because, I think, zerogradient at Inlet Boundary condition cannot gives the correctly wave elevation as waveAlpha BC.
Maybe I am worry.

best,
Shiyu

[blaise]

Hello Niels,

I think I might have stumbled across a weird behaviour of the relaxationZoneLayout tool in waves2Foam. When I use it in a non decomposed case, I get the output:

... snippet ...
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create mesh for time = 0

Reading g

Reading waveProperties
Creating field relaxationZoneLayout

Creating field relaxationZoneLayoutSigma

XMIN has 677158 cells

XMAX has 26460 cells

Write the fields to Time = 0

End

Herein XMIN and XMAX are the inlet and outlet boundaries. The announced cell numbers (shouldn't that actually be face numbers?) are utterly wrong; they should both contain 1470 cells - actually faces - (according to constant/polyMesh/boundary).
Now, when I run relaxationZoneLayout on the same case, but decomposed and so in parallel, I get:

... snippet ...
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create mesh for time = 0

Reading g

Reading waveProperties
Creating field relaxationZoneLayout

Creating field relaxationZoneLayoutSigma

XMIN has 19284 cells

XMAX has 0 cells

Write the fields to Time = 0

End
Finalising parallel run

Using the option for the decomposeParDict dictionary does not change anything.

At the time being I think this does not affect the actual simulation, but it is confusing. Am I doing something wrong here or might the tool be flawed? I am using a version downloaded on 2018-06-26.

Thank you and best regards,

Pascal.
--

[ngj]

Hallo,

You have now posted the same question in multiple threads, but you provide no information. Please refrain from cross-posting and please inform us, what it is you try to accomplish.

You state that waves2Foam is compiled, so I can only assume that you try to make a custom solver.

Kind regards

Niels

[cyyvenus]

Hi Niels,

back again...

As often, it turned out that the error sits in front of the screen... ;-)

On close inspection of the boundary conditions, I found some mistakes. Now things run smoothly (at least for the first 10 seconds) and the floating body does not seem to be jumping out of the domain again.

Anyway, the problem with the boundary condition for alpha.water at the inlet still persists. Things only work when I set the inlet condition to:

Code:
type zeroGradient;
I attached the corrected case, for those who are interested.

Here is an animation of the corrected case:

https://drive.google.com/open?id=1KG...ihI3K5DEbykeGk

I am looking forward to hearing from you about the boundary condition issue!

Thank you and best wishes,

Pascal.

Hi, Pascal,

I have tried your test case, and it gives out the error message as below:

--> FOAM FATAL IO ERROR:
Dictionary entry for patch XMIN not found

May I know how can I solve it or which directory should I look at, Thank you!

__________________________________________________ __________________

A quick update, the problem is solved.
The error came from the incomplete installation of overWaveDyMFoam.

Best,
Venus

[Yiny]

Hi, did you succeed in coupling the slovers of waves2foam and overinterdymfoam? I am also trying this work and have encountered an unsolvable problem:
I finished compiling overwavedymfoam and no error was reported. But when I run a case, I find the case diverged after 35s which is close to stability. I tried various modifications but couldn't change the divergence phenomenon and the version of OpenFoam I used is OF2206. Can you give me some advice? Thanks.
I will attach my case and solver below.

[sunweiyi2020]

Originally Posted by blaise

Hello all,

I am currently trying to integrate waves2Foam with the overInterDyMFoam solver in OpenFOAM-v1712. I have previously achieved to do the same with interDyMFoam, so I thought I could give this also a try.
My solver (overWaveDyMFoam) compiles successully, but when I run a simple case with a floating box, I get the following error in the very first time step:

Starting time loop

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

PIMPLE: iteration 1
forces forces:
    Not including porosity effects

6-DoF rigid body motion
    Centre of rotation: (10.08 -0.0999727951411 0.25)
    Centre of mass: (10.08 -0.0999727951411 0.25)
    Orientation: (1 -1.6653719982e-09 -2.12718304828e-20 1.6653719982e-09 1 -1.36991915347e-21 2.1271830485e-20 1.36991911805e-21 1)
    Linear velocity: (0 0.00544097178199 0)
    Angular velocity: (2.73983829821e-19 -4.25436609694e-18 3.33074399639e-07)
    Euler angles: (7.84905857681e-20 -1.21878610918e-18 9.54187868158e-08)

inverseDistance : detected 1 mesh regions
    zone:0 nCells:318568  voxels:(34 34 34) bb:(4.67999600671 -1.00000399329 -3.99329437933e-06) (8.10000399329 1.00000399329 0.500003993294)
Overset analysis : nCells : 318568
    calculated   : 300000
    interpolated : 0 (interpolated from local:0  mixed local/remote:0  remote:0)
    hole         : 18568

Execution time for mesh.update() = 1 s
smoothSolver:  Solving for alpha.water, Initial residual = 0, Final residual = 0, No Iterations 0
Phase-1 volume fraction = 0.5  Min(alpha.water) = 0  Max(alpha.water) = 1
MULES: Correcting alpha.water
[3] 
[3] 
[3] --> FOAM FATAL ERROR: 
[3] object of type N4Foam12waveTheories10waveTheoryE is not allocated
[3] 
[3]     From function T* Foam::autoPtr<T>::operator->() [with T = Foam::waveTheories::waveTheory]
[3]     in file /usr/local/OpenFOAM/OpenFOAM-v1712/src/OpenFOAM/lnInclude/autoPtrI.H at line 211.
[3] 
FOAM parallel run aborting
[3] 
[3] #0  Foam::error::printStack(Foam::Ostream&)-------------------------------
An MPI process has executed an operation involving a call to the
"fork()" system call to create a child process.  Open MPI is currently
operating in a condition that could result in memory corruption or
other system errors; your MPI job may hang, crash, or produce silent
data corruption.  The use of fork() (or system() or other calls that
create child processes) is strongly discouraged.  

The process that invoked fork was:

  Local host:          ofslave44 (PID 20874)
  MPI_COMM_WORLD rank: 3

If you are *absolutely sure* that your application will successfully
and correctly survive a call to fork(), you may disable this warning
by setting the mpi_warn_on_fork MCA parameter to 0.
--------------------------------------------------------------------------
 addr2line failed
[3] #1  Foam::error::abort() addr2line failed
[3] #2  Foam::waveAlphaFvPatchScalarField::signedPointToSurfaceDistance(Foam::Vector<double> const&) const addr2line failed
[3] #3  Foam::waveAlphaFvPatchScalarField::signedPointToSurfaceDistance(Foam::Field<Foam::Vector<double> > const&, Foam::Field<double>&) addr2line failed
[3] #4  Foam::convexPolyhedral::divideFace(long const&) addr2line failed
[3] #5  Foam::waveAlphaFvPatchScalarField::updateCoeffs() addr2line failed
[3] #6  Foam::mixedFvPatchField<double>::evaluate(Foam::UPstream::commsTypes) addr2line failed
[3] #7  Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::Boundary::evaluate()
[3] #8  void Foam::MULES::correct<double, Foam::geometricOneField, Foam::zeroField, Foam::zeroField>(double const&, Foam::geometricOneField const&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>&, Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::zeroField const&, Foam::zeroField const&)
[3] #9  ?
[3] #10  main
[3] #11  __libc_start_main addr2line failed
[3] #12  ?
--------------------------------------------------------------------------
MPI_ABORT was invoked on rank 3 in communicator MPI_COMM_WORLD 
with errorcode 1.

NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
You may or may not see output from other processes, depending on
exactly when Open MPI kills them.

Can anyone point me in a helpful direction on what is going wrong here?

Thank you!

Pascal.

Hi blaise and ngj,

I have a question about wave2foam. Does wave2foam support RBFMeshMotionSolver? From my test, wave2foam can't use RBFMeshMotionSolver. If not, I want to integrate RBFMeshMotionSolver into wave2foam. But I have no idea about how to do this. Could you share your experience and give me any advice?

[jeong1999911]

Originally Posted by Yiny

Hi, did you succeed in coupling the slovers of waves2foam and overinterdymfoam? I am also trying this work and have encountered an unsolvable problem:
I finished compiling overwavedymfoam and no error was reported. But when I run a case, I find the case diverged after 35s which is close to stability. I tried various modifications but couldn't change the divergence phenomenon and the version of OpenFoam I used is OF2206. Can you give me some advice? Thanks.
I will attach my case and solver below.

Hi,Yiny.I have also encountered similar problems.I am also trying this work and have encountered an unsolvable problem:when I run a case,generate wave model conflicts with inter foam wave model.Have you resolved the problem?Thanks.