CFD Online Discussion Forums - [swak4Foam] GroovyBC for 2D wave flume!

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)

- OpenFOAM Community Contributions (https://www.cfd-online.com/Forums/openfoam-community-contributions/)

- - [swak4Foam] GroovyBC for 2D wave flume! (https://www.cfd-online.com/Forums/openfoam-community-contributions/88832-groovybc-2d-wave-flume.html)

Hisham

May 27, 2011 04:55

GroovyBC for 2D wave flume!

Hi

My goal is to establish a 2D wave flume in OpenFOAM. As a start, I would try groovyBC for wave generation. I have downloaded groovyBC from the swak4Foam wiki page (http://openfoamwiki.net/index.php/Contrib/swak4Foam). I, then, aim to run the groovyWaveTank example from the Contrib groovyBC wiki page (http://openfoamwiki.net/index.php/Co...e_implemented:). I have installed bison (2.4.1) and flex. I have gcc ver 4.4.5. I work on Ubuntu 10.10 64bit. It seems I have compiled the library for the groovyBC successfully. I cannot find any ".so" file but as I run "wmake all" inside the swak4Foam directory I get a message that all .so files are up to date.

As I run the script in ./copySwakFilesToSite.sh I get:
.: 3: theFiles.sh: not found

What does this error mean? Can I copy the ".o" files to /opt/openfoam171/lib/linux64GccDPOpt manually?

Best regards,
Hisham ElSafti

gschaider

May 30, 2011 07:53

Quote:

Originally Posted by Hisham (Post 309465)

Please ignore the "Global installation"-section in the README unless you know what you're doing (a straight Allwmake installs swak into your user directories and that should be sufficient for a first try)

Hisham

May 30, 2011 08:24

Hi Bernhard,

I found the libraries after a "wmake all" in /home/<UserName>/lib/linux64GccDPOpt

Is that enough for a user to include a library in the ControlDict? Or should I include a copy of the libraries somewhere else?

I tried to run the groovyWaveTank example ... Due to different versions (I think) I changed gamma into alpha1 ... pd into p_rgh

As I run interFoam (after blockMesh & setFields) I get:

Reading field p_rgh

Reading field alpha1

Reading field U

Reading/calculating face flux field phi

Reading transportProperties

Selecting incompressible transport model Newtonian
Selecting incompressible transport model Newtonian

--> FOAM FATAL IO ERROR:
keyword cAlpha is undefined in dictionary "/home/numubuntu/ElSaftiOpenFoamRuns/groovyWaveTank/system/fvSolution::PISO"

file: /home/numubuntu/ElSaftiOpenFoamRuns/groovyWaveTank/system/fvSolution::PISO from line 115 to line 126.

From function dictionary::lookupEntry(const word&, bool, bool) const
in file db/dictionary/dictionary.C at line 395.

FOAM exiting

Please advise!

ngj	May 30, 2011 10:10

Hi Hisham

The solution is given by OF. It tells you that the parameter cAlpha is unknown in fvSolution in the sub-dictionary PISO. If you go into that file, you will find that the parameter is called cGamma. Make the appropriate changes to all gamma-parameters, and you should be able to run the case.

Best regards

Niels

Hisham

May 30, 2011 11:20

Hi Niels

Thanks a lot for the tip. After some tedious modifications, the problem ran OK. Nevertheless, the output is not. Changing wave's amplitude (A) & length (l) do not change the output. Also the wave maker seems to fluctuate OK but the wave does not propagate ... strange

https://picasaweb.google.com/1169016...28954537872258

Any ideas?

Best regards,
Hisham El Safti

Hisham

June 1, 2011 10:35

Hi

Thanks a lot .. I figured it out ... For some reason the equation was written only in the alpha1 but not also in the U file ... I re-downloaded the case and it's OK.

I have a question about using grrovyBC with turbulence models ... How does one define the boundaryField in the parameters files for turbulence models (e.g. the 'k' file for the LES model)

Best regards,
Hisham El Safti

gschaider

June 7, 2011 07:02

Quote:

Originally Posted by Hisham (Post 310150)

You mean on walls? For patches the regular groovyBC should do. For walls the question is whether you'll want to set the values directly. But if you want to and the value is static but inhomogenous you can use funkySetBoundaryFields. Otherwise if you use a wall-function that really has parameters that you want to prescribe you'll have to write a subclass of it that can use the groovyBC-machinery (there re examples of such boundary conditions - not turbulence - in the swak4Foam-sources)

bojiezhang

August 1, 2011 03:22

Quote:

Originally Posted by Hisham (Post 310150)

Dear Hisham:
Have you soloved the problem of using grrovyBC with turbulence models? I do not know how to set it, could you tell me something or send me your successful case? Thank you in advance!
bojiezhang

holodeck10

January 18, 2012 05:44

groovyBC and some *.so errors

1 Attachment(s)

Hi Foamers,

I am currently installing swak4Foam in order to use groovyBC for some interFoam simulations. I installed OF in $HOME/OpenFOAM/OpenFOAM-1.7.1 and build the sources with $WM_PRECISION_OPTION=SP. I have Bison 2.5 and flex 2.5.35 installed.

I downloaded the swak4Foam files into $HOME/pingu-1.7.1/applications/swak4Foam. I also included the swak4Foam_M_PI_patch for single precision support in this directory. ./Allwmake goes well. Libraries are in $HOME/OpenFOAM/pingu-1.7.1/lib/linux64GccSPOpt. Only SWAK_PYTHON_INCLUDE is not defined.

Now, I would like to run a numerical wave tank using the interFoam solver, but I get the following error:

PHP Code:


		
			
Starting time loop

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

#0  Foam::error::printStack(Foam::Ostream&) in "/home/pingu/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccSPOpt/libOpenFOAM.so"
#1  Foam::sigFpe::sigFpeHandler(int) in "/home/pingu/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccSPOpt/libOpenFOAM.so"
#2   in "/lib/libc.so.6"
#3  Foam::LimitedScheme<float, Foam::Limited01Limiter<Foam::vanLeerLimiter<Foam::NVDTVD> >, Foam::limitFuncs::magSqr>::limiter(Foam::GeometricField<float, Foam::fvPatchField, Foam::volMesh> const&) const in "/home/pingu/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccSPOpt/libfiniteVolume.so"
#4  Foam::limitedSurfaceInterpolationScheme<float>::weights(Foam::GeometricField<float, Foam::fvPatchField, Foam::volMesh> const&) const in "/home/pingu/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccSPOpt/libinterfaceProperties.so"
#5  Foam::surfaceInterpolationScheme<float>::interpolate(Foam::GeometricField<float, Foam::fvPatchField, Foam::volMesh> const&) const in "/home/pingu/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccSPOpt/libinterfaceProperties.so"
#6  Foam::fv::gaussConvectionScheme<float>::interpolate(Foam::GeometricField<float, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::GeometricField<float, Foam::fvPatchField, Foam::volMesh> const&) const in "/home/pingu/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccSPOpt/libfiniteVolume.so"
#7  Foam::fv::gaussConvectionScheme<float>::flux(Foam::GeometricField<float, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::GeometricField<float, Foam::fvPatchField, Foam::volMesh> const&) const in "/home/pingu/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccSPOpt/libfiniteVolume.so"
#8  
 in "/home/pingu/OpenFOAM/OpenFOAM-1.7.1/applications/bin/linux64GccSPOpt/interFoam"
#9  
 in "/home/pingu/OpenFOAM/OpenFOAM-1.7.1/applications/bin/linux64GccSPOpt/interFoam"
#10  __libc_start_main in "/lib/libc.so.6"
#11  
 in "/home/pingu/OpenFOAM/OpenFOAM-1.7.1/applications/bin/linux64GccSPOpt/interFoam"
Floating point exception (core dumped)

It tells me that interFoam is not satisfied with some content in libOpenFOAM.so, but there I am stuck. Is there something what I can do about? Do I have to change schemes in fvSchemes when working with single precision? Thank you for your suggestions!

Best regards
Stefan

gschaider

January 18, 2012 17:11

Quote:

Originally Posted by holodeck10 (Post 339892)

PHP Code:


		
			
Starting time loop



Courant Number mean: 0 max: 0

Interface Courant Number mean: 0 max: 0

deltaT = 0.0049999999

Time = 0.0049999999



#0  Foam::error::printStack(Foam::Ostream&) in "/home/pingu/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccSPOpt/libOpenFOAM.so"

#1  Foam::sigFpe::sigFpeHandler(int) in "/home/pingu/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccSPOpt/libOpenFOAM.so"

#2   in "/lib/libc.so.6"

#3  Foam::LimitedScheme<float, Foam::Limited01Limiter<Foam::vanLeerLimiter<Foam::NVDTVD> >, Foam::limitFuncs::magSqr>::limiter(Foam::GeometricField<float, Foam::fvPatchField, Foam::volMesh> const&) const in "/home/pingu/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccSPOpt/libfiniteVolume.so"

#4  Foam::limitedSurfaceInterpolationScheme<float>::weights(Foam::GeometricField<float, Foam::fvPatchField, Foam::volMesh> const&) const in "/home/pingu/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccSPOpt/libinterfaceProperties.so"

#5  Foam::surfaceInterpolationScheme<float>::interpolate(Foam::GeometricField<float, Foam::fvPatchField, Foam::volMesh> const&) const in "/home/pingu/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccSPOpt/libinterfaceProperties.so"

#6  Foam::fv::gaussConvectionScheme<float>::interpolate(Foam::GeometricField<float, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::GeometricField<float, Foam::fvPatchField, Foam::volMesh> const&) const in "/home/pingu/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccSPOpt/libfiniteVolume.so"

#7  Foam::fv::gaussConvectionScheme<float>::flux(Foam::GeometricField<float, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::GeometricField<float, Foam::fvPatchField, Foam::volMesh> const&) const in "/home/pingu/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccSPOpt/libfiniteVolume.so"

#8  

 in "/home/pingu/OpenFOAM/OpenFOAM-1.7.1/applications/bin/linux64GccSPOpt/interFoam"

#9  

 in "/home/pingu/OpenFOAM/OpenFOAM-1.7.1/applications/bin/linux64GccSPOpt/interFoam"

#10  __libc_start_main in "/lib/libc.so.6"

#11  

 in "/home/pingu/OpenFOAM/OpenFOAM-1.7.1/applications/bin/linux64GccSPOpt/interFoam"

Floating point exception (core dumped)

The problem you have is not in libOpenFOAM.so, it is in libfiniteVolume.so, but that's beside the points. During a surface interpolation the program experiences a floating point exception (usually a division by zero or such a thing). The problem DOESN'T occur with the double precision setup? Also try replacing all groovyBCs with stock boundary-conditions to see if swak4Foam is the problem (it doesn't show up in the stack-trace you posted)

holodeck10

January 18, 2012 22:58

Hi Bernhard,

thanks for your hint! I replaced groovyBC with somethign else (could not find out what stock BC is, so I replaced it with some fixedValue and zeroGradient conditions). ...and the problem persists. It does not occur with double Precision. So, I guess my problem is not related to swak4Foam.

I should add, that I previously ran the dambreak test case with single precision. It works well.

In search for an indication where the error might lie I started from scratch. So far, I did not do blockMesh and setFields with the SP installation. I just took the cases as I prepared them with a DP installation. So, I switched back to DP and did the same as in SP. Here is a summary:

2D case:
blockMesh with SP and DP:
same warning

PHP Code:


		
			
Default patch type set to empty
--> FOAM Warning : 
    From function polyMesh::polyMesh(... construct from shapes...)
    in file meshes/polyMesh/polyMeshFromShapeMesh.C at line 576
    Found 102 undefined faces in mesh; adding to default patch.

checkMesh with DP and SP:
same error:

PHP Code:


		
			
***Number of edges not aligned with or perpendicular to non-empty directions: 11674
  <<Writing 14741 points on non-aligned edges to set nonAlignedEdges

The simulation still runs with DP, but not with SP.

3D case:
blockMesh in DP and SP: runs well
checkMesh in DP: runs well
checkMesh in SP:

PHP Code:


		
			
***Boundary openness (-2.5132938e-08 -2.626166e-06 4.2165716e-06) possible hole in boundary description.

The simulation runs with DP, but not with SP.

I have no clue what to do next. Do you have a suggestion for me?

Best regards
Stefan

gschaider

January 19, 2012 19:03

Quote:

Originally Posted by holodeck10 (Post 340026)

Hi Bernhard,

thanks for your hint! I replaced groovyBC with somethign else (could not find out what stock BC is, so I replaced it with some fixedValue and zeroGradient conditions).

Stock for me means "the way it comes out of the factory" - like in stock car racing - so what you did is exactly what I meant. Maybe a native speaker can tell me how to say it better ...

Quote:

Originally Posted by holodeck10 (Post 340026)

...and the problem persists. It does not occur with double Precision. So, I guess my problem is not related to swak4Foam.

I should add, that I previously ran the dambreak test case with single precision. It works well.

In search for an indication where the error might lie I started from scratch. So far, I did not do blockMesh and setFields with the SP installation. I just took the cases as I prepared them with a DP installation. So, I switched back to DP and did the same as in SP. Here is a summary:

2D case:
blockMesh with SP and DP:
same warning

PHP Code:


		
			
Default patch type set to empty

--> FOAM Warning : 

    From function polyMesh::polyMesh(... construct from shapes...)

    in file meshes/polyMesh/polyMeshFromShapeMesh.C at line 576

    Found 102 undefined faces in mesh; adding to default patch.

checkMesh with DP and SP:
same error:

PHP Code:


		
			
***Number of edges not aligned with or perpendicular to non-empty directions: 11674

  <<Writing 14741 points on non-aligned edges to set nonAlignedEdges

The simulation still runs with DP, but not with SP.

3D case:
blockMesh in DP and SP: runs well
checkMesh in DP: runs well
checkMesh in SP:

PHP Code:


		
			
***Boundary openness (-2.5132938e-08 -2.626166e-06 4.2165716e-06) possible hole in boundary description.

The simulation runs with DP, but not with SP.

I have no clue what to do next. Do you have a suggestion for me?

Best regards
Stefan

Sorry. No. Maybe the limited precision of SP is bigger than the tolerances for some mesh checks, but that is only a wild guess.

Apart from the obvious ("use ldd to check that you're not using a DP-library by accident") my only advice I can give you is to write a bug-report to the OpenCFD-Mantis. We've agreed that it is not a swak-issue and I don't have a SP-installation so I can't reproduce it

Bernhard

holodeck10

January 19, 2012 21:15

Thank you again Bernhard!

Beside realizing now what stock car racing is, I learnt to use ldd. Referring to your previous answer, I typed

ldd $FOAM_LIBBIN/libfiniteVolume.so

and got

PHP Code:


		
			
 linux-vdso.so.1 =>  (0x00007fffac1ff000)
 libtriSurface.so => /home/pingu/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccSPOpt/libtriSurface.so (0x00007f1e7d1d6000)
 libmeshTools.so => /home/pingu/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccSPOpt/libmeshTools.so (0x00007f1e7cd77000)
 libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f1e7ca48000)
 libm.so.6 => /lib/libm.so.6 (0x00007f1e7c7c5000)
 libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f1e7c5ad000)
 libc.so.6 => /lib/libc.so.6 (0x00007f1e7c22a000)
 libdecompositionMethods.so => /home/pingu/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccSPOpt/libdecompositionMethods.so (0x00007f1e7c00b000)
 liblagrangian.so => /home/pingu/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccSPOpt/liblagrangian.so (0x00007f1e7bdef000)
 /lib64/ld-linux-x86-64.so.2 (0x00007f1e7e3ae000)
 libscotchDecomp.so => /home/pingu/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccSPOpt/libscotchDecomp.so (0x00007f1e7bbe2000)
 libmetisDecomp.so => /home/pingu/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccSPOpt/libmetisDecomp.so (0x00007f1e7b9d3000)
 libparMetisDecomp.so => /home/pingu/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccSPOpt/openmpi-1.4.1/libparMetisDecomp.so (0x00007f1e7b7bf000)
 libscotch.so => /home/pingu/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccSPOpt/libscotch.so (0x00007f1e7b55d000)
 libscotcherrexit.so => /home/pingu/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccSPOpt/libscotcherrexit.so (0x00007f1e7b35b000)
 libmetis.so => /home/pingu/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccSPOpt/libmetis.so (0x00007f1e7b107000)
 libGKlib.so => /home/pingu/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccSPOpt/libGKlib.so (0x00007f1e7aeec000)
 libmetis-parmetis.so => /home/pingu/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccSPOpt/openmpi-1.4.1/libmetis-parmetis.so (0x00007f1e7aca1000)
 libparmetis.so => /home/pingu/OpenFOAM/OpenFOAM-1.7.1/lib/linux64GccSPOpt/openmpi-1.4.1/libparmetis.so (0x00007f1e7aa60000)
 libmpi.so.0 => /home/pingu/OpenFOAM/ThirdParty-1.7.1/platforms/linux64Gcc/openmpi-1.4.1/lib/libmpi.so.0 (0x00007f1e7a7bf000)
 libopen-rte.so.0 => /home/pingu/OpenFOAM/ThirdParty-1.7.1/platforms/linux64Gcc/openmpi-1.4.1/lib/libopen-rte.so.0 (0x00007f1e7a572000)
 libopen-pal.so.0 => /home/pingu/OpenFOAM/ThirdParty-1.7.1/platforms/linux64Gcc/openmpi-1.4.1/lib/libopen-pal.so.0 (0x00007f1e7a2fa000)
 libdl.so.2 => /lib/libdl.so.2 (0x00007f1e7a0f6000)
 libnsl.so.1 => /lib/libnsl.so.1 (0x00007f1e79edc000)
 libutil.so.1 => /lib/libutil.so.1 (0x00007f1e79cd8000)
 libpthread.so.0 => /lib/libpthread.so.0 (0x00007f1e79abb000)

I started to chek what all these libraries in the foam folder do and started with libtriSurface.so, which also sounds a bit like that it could be involved in the surface treatment, where problems occur. Google leads to 4 links in which some mention something about 32bit and some about 64bit ... But to be honest, I enter regions where I never have gone before. Do you see from a glance, if there are DP libraries in the list?

I will wrote a bug report to mantis. While double-checking on the files I uploaded, I noticed something interesting: When I forget to "setFields", then the time loop is started correctly and the simulation seems to run normally ...

Best regards
Stefan

holodeck10

January 20, 2012 05:04

Hi Bernhard,

fyi, this is the reason why the status of my bug report has been changed from "new" to "closed":

"Transient complex physics problems should be run double precision; single precision is generally not sufficient to represent the important small changes and interactions going on in the system."

i asked for some more details and here is then the final answer, which I will accept:

"We cannot guarantee that VoF can be run single-precision and would recommend that you run interFoam double-precision. When we release OpenFOAM we first run the test-loop both double-precision and single-precision and while we require that all of the cases run double-precision some of the complex physics cases fail single-precision due to the limitations of this floating-point representation.

We invest a fair amount of time testing and maintaning the single-precision operation of OpenFOAM and maybe for some cases under some conditions it would be possible to extend the range of applicability of this mode of operation by tuning stabilisation factors for example, or adding boundedness clipping ...
However it is unlikely that this would work for VoF which is VERY sensitive to round-off error for cases with large density ratio."

FYI, I will still try to use OF 2.1 and Ubuntu 10.10 to see how the result looks like in SP, hoping that in my case it may not be very good, but maybe good enough for my needs.

Best regards
Stefan

All times are GMT -4. The time now is 03:13.