[amgh]

Hi

I have been using waves2foam together with the oceanwave3d coupling for a while now on OF230 and OF240. But recently I tried to use it on OF400 and I am having some problems even with the tuturial couplingOceanWave3D.
When I run this case I get this error:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Mapping the OceanWave3D solution to the OpenFoam domain
Applied ramping factor: 1

--> FOAM FATAL ERROR:
At least one plane coefficient must have a valuenctions are :

6
(
patchProbes
probes
psiReactionThermoMoleFractions
rhoReactionThermoMoleFractions
sets
surfaces
)

....
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

But if I change the starting time of wave2foam from 5s to 0s (identical with the oceanwave3d starting time) in waveProperties then I can run it successfully. I guess the problem happens when waves2Foam tries to initialize the domain with the solution from the oceanwave3d.

Has anybody encountered and maybe solved this problem?
Is this a known issue for other versions too?

Thank you in advance.
BR
Amin

[ngj]

Hi Amin,

The error you see is most likely related to the missing of the surfaceElevation tool in OpenFoam-400, which is a known issue (check the manual).

I do not understand why it runs with a different starting time. The error with missing functionObject should occur in all cases.

Please try to remove the surface sampling and see, whether the model executes correctly.

Kind regards,

Niels

[amgh]

Originally Posted by ngj

Hi Amin,

The error you see is most likely related to the missing of the surfaceElevation tool in OpenFoam-400, which is a known issue (check the manual).

I do not understand why it runs with a different starting time. The error with missing functionObject should occur in all cases.

Please try to remove the surface sampling and see, whether the model executes correctly.

Kind regards,

Niels

Thanks for the quick reply Niels.
Sorry the error message I posted was the case that I had not commented the objectFunction. After commenting the free surface elevation functionObject I get the following error.
The explanation I gave previously about the simulation running successfully after changing the start time of wavesProperties to zero is true for this case too.

As a check I also ran the waveFlume tuturial with OpenFOAM-400 and I saw that in general having the objectfunciton of the freesurfaceelevation in the controlDict does not crash the simulation but it only gives warnings and obviously doesn't dump the free surface elevation data.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Mapping the OceanWave3D solution to the OpenFoam domain
Applied ramping factor: 1

--> FOAM FATAL ERROR:
At least one plane coefficient must have a value

From function void Foam::plane::calcPntAndVec(const scalarList&)
in file meshes/primitiveShapes/plane/plane.C at line 51.

FOAM aborting

#0 Foam::error::printStack(Foam::Ostream&) in "/home/openfoam/OpenFOAM-4.0/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so"
#1 Foam::error::abort() in "/home/openfoam/OpenFOAM-4.0/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so"
#2 Foam::plane::calcPntAndVec(Foam::List<double> const&) in "/home/openfoam/OpenFOAM-4.0/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so"
#3 Foam::waveTheories::oceanWave3D::updatePhi() in "/home/amgh/OpenFOAM/amgh-4.0/platforms/linux64GccDPInt32Opt/lib/libwaves2Foam.so"
#4 Foam::waveTheories::oceanWave3D::timeStepOceanWave 3D() in "/home/amgh/OpenFOAM/amgh-4.0/platforms/linux64GccDPInt32Opt/lib/libwaves2Foam.so"
#5 Foam::waveTheories::oceanWave3D::step() in "/home/amgh/OpenFOAM/amgh-4.0/platforms/linux64GccDPInt32Opt/lib/libwaves2Foam.so"
#6 main in "/home/amgh/OpenFOAM/amgh-4.0/platforms/linux64GccDPInt32Opt/bin/waveFoam"
#7 __libc_start_main in "/lib64/libc.so.6"
#8 ? in "/home/amgh/OpenFOAM/amgh-4.0/platforms/linux64GccDPInt32Opt/bin/waveFoam"
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Thank you so much again.
BR
Amin

[ngj]

Good morning,

I have no idea of what is going on. Could you try to reproduce the error with the OceanWave3D tutorial for waveFoam?

All I can see is that something goes wrong with the initial mapping of OceanWave3D to OpenFoam. If the tutorial runs, it is likely something case dependent.

Kind regards

Niels

[amgh]

Originally Posted by ngj

Good morning,

I have no idea of what is going on. Could you try to reproduce the error with the OceanWave3D tutorial for waveFoam?

All I can see is that something goes wrong with the initial mapping of OceanWave3D to OpenFoam. If the tutorial runs, it is likely something case dependent.

Kind regards

Niels

The error I had put in my previous reply was from the OceanWave3D tutorial for waveFoam (I guess you mean couplingOceanWave3D, right?).
In my first post I copied the error I get when I run the tutorial without any change, and in my second post I copied the error I get when I comment the functionObjects and run the turtorial.
Thank you.

Kind Regards
Amin

[Jost K]

Originally Posted by amgh

Thanks for the quick reply Niels.
Sorry the error message I posted was the case that I had not commented the objectFunction. After commenting the free surface elevation functionObject I get the following error.
The explanation I gave previously about the simulation running successfully after changing the start time of wavesProperties to zero is true for this case too.

As a check I also ran the waveFlume tuturial with OpenFOAM-400 and I saw that in general having the objectfunciton of the freesurfaceelevation in the controlDict does not crash the simulation but it only gives warnings and obviously doesn't dump the free surface elevation data.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Mapping the OceanWave3D solution to the OpenFoam domain
Applied ramping factor: 1

--> FOAM FATAL ERROR:
At least one plane coefficient must have a value

From function void Foam:lane::calcPntAndVec(const scalarList&)
in file meshes/primitiveShapes/plane/plane.C at line 51.

FOAM aborting

#0 Foam::error:rintStack(Foam::Ostream&) in "/home/openfoam/OpenFOAM-4.0/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so"
#1 Foam::error::abort() in "/home/openfoam/OpenFOAM-4.0/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so"
#2 Foam:lane::calcPntAndVec(Foam::List<double> const&) in "/home/openfoam/OpenFOAM-4.0/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so"
#3 Foam::waveTheories:ceanWave3D::updatePhi() in "/home/amgh/OpenFOAM/amgh-4.0/platforms/linux64GccDPInt32Opt/lib/libwaves2Foam.so"
#4 Foam::waveTheories:ceanWave3D::timeStepOceanWave 3D() in "/home/amgh/OpenFOAM/amgh-4.0/platforms/linux64GccDPInt32Opt/lib/libwaves2Foam.so"
#5 Foam::waveTheories:ceanWave3D::step() in "/home/amgh/OpenFOAM/amgh-4.0/platforms/linux64GccDPInt32Opt/lib/libwaves2Foam.so"
#6 main in "/home/amgh/OpenFOAM/amgh-4.0/platforms/linux64GccDPInt32Opt/bin/waveFoam"
#7 __libc_start_main in "/lib64/libc.so.6"
#8 ? in "/home/amgh/OpenFOAM/amgh-4.0/platforms/linux64GccDPInt32Opt/bin/waveFoam"
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Thank you so much again.
BR
Amin

Hi Amin,


I just had the same problem.
Taking a closer look it is line 511 of the OceanWave3D.C class that is responsible the error when using OpenFOAM 4.1

(inside the "oceanWave3D::updatePhi()" function).
The line reads:

phi.boundaryField()[patchi] == phiTemp.boundaryField()[patchi];

I am unable to explain the error we are seeing but I can explain why setting the OpenFOAM startTime to the beginning of the interval defined in waveProperties.input works.


In this case the oceanWave3D::timeStepOceanWave3D() function does nothing because the OpenFOAM time is never smaller than the start time of the interval. Consequently oceanWave3D::updatePhi() is never executed.
OceanWave3D runs until the OpenFOAM startTime during the execution of oceanWave3D::alignTimes() called in the constructor.


This is a somewhat strange way to run the OceanWave3D coupling but it works surprisingly well.

The downside is that oceanWave3D::alignTimes() also runs during the setWaveField command which makes this take very long.



commenting out the line I mentioned above might be a slightly better workaround. I would really appreciate if someone could explain to me why this line causes the error and if there is a proper fix for this.



All the best,
Jost