[Arnoldinho]

Does "new" mean you're using the version from SVN or from Mercurial?

I have always used the svn version from openfoam-extend.svn.sourceforge.net.

a) have a look the $FOAM_LIBBIN, $FOAM_USER_LIBBIN and $FOAM_SITE_LIBBIN. Whether there are different instances of libgroovyBC.so and the other swak-libraries

- $FOAM_LIBBIN does not give any library that sounds like groovy or swak4Foam.
- $FOAM_USER_LIBBIN gives: libgroovyBC.so, libswak4FoamParsers.so, libswakSourceFields.so, libgroovyStandardBCs.so, libswakFunctionObjects.so, libswakTopoSources.so
- $FOAM_SITE_LIBBIN: cannot be found.

b) check with ldd (ldd $FOAM_LIBBIN/libgroovyBC.so) which other libraries groovyBC actually is using

- ldd $FOAM_LIBBIN/libgroovyBC.so: cannot be found.
- ldd $FOAM_USER_LIBBIN/libgroovyBC.so:

linux-vdso.so.1 => (0x00007fffe13ff000)
libfiniteVolume.so => /opt/OpenFOAM/OpenFOAM-1.7.x/lib/linux64GccDPOpt/libfiniteVolume.so (0x00007f5c7d8a0000)
libOpenFOAM.so => /opt/OpenFOAM/OpenFOAM-1.7.x/lib/linux64GccDPOpt/libOpenFOAM.so (0x00007f5c7d274000)
libsampling.so => /opt/OpenFOAM/OpenFOAM-1.7.x/lib/linux64GccDPOpt/libsampling.so (0x00007f5c7cdca000)
libswak4FoamParsers.so => /home/stahlmann/OpenFOAM/stahlmann-1.7.x/lib/linux64GccDPOpt/libswak4FoamParsers.so (0x00007f5c7c886000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f5c7c563000)
libm.so.6 => /lib/libm.so.6 (0x00007f5c7c2e0000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f5c7c0c9000)
libc.so.6 => /lib/libc.so.6 (0x00007f5c7bd45000)
libtriSurface.so => /opt/OpenFOAM/OpenFOAM-1.7.x/lib/linux64GccDPOpt/libtriSurface.so (0x00007f5c7bad2000)
libmeshTools.so => /opt/OpenFOAM/OpenFOAM-1.7.x/lib/linux64GccDPOpt/libmeshTools.so (0x00007f5c7b670000)
libPstream.so => /opt/OpenFOAM/OpenFOAM-1.7.x/lib/linux64GccDPOpt/openmpi-1.4.1/libPstream.so (0x00007f5c7b465000)
libz.so.1 => /lib/libz.so.1 (0x00007f5c7b24e000)
libsurfMesh.so => /opt/OpenFOAM/OpenFOAM-1.7.x/lib/linux64GccDPOpt/libsurfMesh.so (0x00007f5c7af5c000)
liblagrangian.so => /opt/OpenFOAM/OpenFOAM-1.7.x/lib/linux64GccDPOpt/liblagrangian.so (0x00007f5c7ad40000)
/lib64/ld-linux-x86-64.so.2 (0x00007f5c7ead8000)
libdecompositionMethods.so => /opt/OpenFOAM/OpenFOAM-1.7.x/lib/linux64GccDPOpt/libdecompositionMethods.so (0x00007f5c7ab20000)
libmpi.so.0 => /opt/OpenFOAM/ThirdParty-1.7.x/platforms/linux64Gcc/openmpi-1.4.1/lib/libmpi.so.0 (0x00007f5c7a87e000)
libscotchDecomp.so => /opt/OpenFOAM/OpenFOAM-1.7.x/lib/linux64GccDPOpt/libscotchDecomp.so (0x00007f5c7a671000)
libmetisDecomp.so => /opt/OpenFOAM/OpenFOAM-1.7.x/lib/linux64GccDPOpt/libmetisDecomp.so (0x00007f5c7a462000)
libparMetisDecomp.so => /opt/OpenFOAM/OpenFOAM-1.7.x/lib/linux64GccDPOpt/openmpi-1.4.1/libparMetisDecomp.so (0x00007f5c7a24d000)
libopen-rte.so.0 => /opt/OpenFOAM/ThirdParty-1.7.x/platforms/linux64Gcc/openmpi-1.4.1/lib/libopen-rte.so.0 (0x00007f5c79fff000)
libopen-pal.so.0 => /opt/OpenFOAM/ThirdParty-1.7.x/platforms/linux64Gcc/openmpi-1.4.1/lib/libopen-pal.so.0 (0x00007f5c79d88000)
libdl.so.2 => /lib/libdl.so.2 (0x00007f5c79b84000)
libnsl.so.1 => /lib/libnsl.so.1 (0x00007f5c79969000)
libutil.so.1 => /lib/libutil.so.1 (0x00007f5c79766000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007f5c79549000)
libscotch.so => /opt/OpenFOAM/OpenFOAM-1.7.x/lib/linux64GccDPOpt/libscotch.so (0x00007f5c792e7000)
libscotcherrexit.so => /opt/OpenFOAM/OpenFOAM-1.7.x/lib/linux64GccDPOpt/libscotcherrexit.so (0x00007f5c790e5000)
libmetis.so => /opt/OpenFOAM/OpenFOAM-1.7.x/lib/linux64GccDPOpt/libmetis.so (0x00007f5c78e91000)
libGKlib.so => /opt/OpenFOAM/OpenFOAM-1.7.x/lib/linux64GccDPOpt/libGKlib.so (0x00007f5c78c76000)
libmetis-parmetis.so => /opt/OpenFOAM/OpenFOAM-1.7.x/lib/linux64GccDPOpt/openmpi-1.4.1/libmetis-parmetis.so (0x00007f5c78a2b000)
libparmetis.so => /opt/OpenFOAM/OpenFOAM-1.7.x/lib/linux64GccDPOpt/openmpi-1.4.1/libparmetis.so (0x00007f5c787eb000)

This is from the (not working) 1.7.x version.

The working swak4Foam was (I think) 2010-09-13, First Release.
The not working one is the actual one downloaded just yesterday.

Arne

[ovie]

Hi everyone,

I tried to compile groovyBC on a cluster with Bison version 1.875c. So I followed the bypass instructions on the wiki page, but when I run wmake libso this is the response I get:

wmakeLnInclude: linking include files to ./lnInclude
find: invalid predicate `-L'
Making dependency list for source file PatchValueExpressionParser.yy
Making dependency list for source file PatchValueExpressionLexer.ll
Making dependency list for source file groovyBCPointPatchFields.C
could not open file MixedPointPatchField.H for source file groovyBCPointPatchFields.C
could not open file PointPatchFieldMapper.H for source file groovyBCPointPatchFields.C
Making dependency list for source file PatchResult.C
SOURCE=PatchResult.C ; g++ -m64 -Dlinux64 -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3 -DNoRepository -ftemplate-depth-40 -IMake/linux64GccDPOpt -I/share/home/01389/edoro/OpenFOAM/OpenFOAM-1.7.x/src/finiteVolume/lnInclude -IlnInclude -I. -I/share/home/01389/edoro/OpenFOAM/OpenFOAM-1.7.x/src/OpenFOAM/lnInclude -I/share/home/01389/edoro/OpenFOAM/OpenFOAM-1.7.x/src/OSspecific/POSIX/lnInclude -fPIC -c $SOURCE -o Make/linux64GccDPOpt/PatchResult.o
PatchResult.C: In member function 'void Foam::PatchResult::uglyDelete()':
PatchResult.C:95: warning: deleting 'void*' is undefined
SOURCE=PatchValueExpressionParser.yy ; rm -f Make/linux64GccDPOpt/PatchValueExpressionParser.C Make/linux64GccDPOpt/PatchValueExpressionParser.tab.hh; bison -ra -v -d $SOURCE ; mv *.tab.cc Make/linux64GccDPOpt/PatchValueExpressionParser.C ; mv *.tab.hh Make/linux64GccDPOpt/PatchValueExpressionParser.tab.hh ; mv *.hh Make/linux64GccDPOpt ; g++ -m64 -Dlinux64 -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3 -DNoRepository -ftemplate-depth-40 -IMake/linux64GccDPOpt -I/share/home/01389/edoro/OpenFOAM/OpenFOAM-1.7.x/src/finiteVolume/lnInclude -IlnInclude -I. -I/share/home/01389/edoro/OpenFOAM/OpenFOAM-1.7.x/src/OpenFOAM/lnInclude -I/share/home/01389/edoro/OpenFOAM/OpenFOAM-1.7.x/src/OSspecific/POSIX/lnInclude -fPIC -c Make/linux64GccDPOpt/PatchValueExpressionParser.C -o Make/linux64GccDPOpt/PatchValueExpressionParser.o
PatchValueExpressionParser.yy:29.1-15: invalid directive: `%initial-action'
PatchValueExpressionParser.yy:30.1-33.1: syntax error, unexpected "{...}"
mv: cannot stat `*.tab.cc': No such file or directory
mv: cannot stat `*.tab.hh': No such file or directory
mv: cannot stat `*.hh': No such file or directory
g++: Make/linux64GccDPOpt/PatchValueExpressionParser.C: No such file or directory
g++: no input files
make: *** [Make/linux64GccDPOpt/PatchValueExpressionParser.o] Error 1


Please could someone kindly suggest how to fix this?

Thanks
Ovie

[gschaider]

Originally Posted by ovie

Hi everyone,

I tried to compile groovyBC on a cluster with Bison version 1.875c.

1.875? Wow! Thats old. What kind of OS is this? RHEL2?

Originally Posted by ovie

So I followed the bypass instructions on the wiki page, but when I run wmake libso this is the response I get:

wmakeLnInclude: linking include files to ./lnInclude
find: invalid predicate `-L'

That is a problem that is not groovy-specific

Originally Posted by ovie

SOURCE=PatchValueExpressionParser.yy ; rm -f Make/linux64GccDPOpt/PatchValueExpressionParser.C Make/linux64GccDPOpt/PatchValueExpressionParser.tab.hh; bison -ra -v -d $SOURCE ; mv *.tab.cc Make/linux64GccDPOpt/PatchValueExpressionParser.C ; mv *.tab.hh Make/linux64GccDPOpt/PatchValueExpressionParser.tab.hh ; mv *.hh Make/linux64GccDPOpt ; g++ -m64 -Dlinux64 -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3 -

Please could someone kindly suggest how to fix this?

According to this output the *.yy-file is still compiled (with the ancient bison-version). You were referring to the instructions at http://openfoamwiki.net/index.php/Co...sions_of_bison, weren't you? Are you sure that you did step 3 there (remove the yy and ll-files from the Make/files and replace them with the generated equivalent)? Because this output then shouldn't be there

[ovie]

Thanks for your response.

Just to be sure, I copied a new compiled groovyBC version from my workstation to the cluster and double checked the bypass instructions on the wiki as you indicated in your response. These are the contents of my Make/files:
PatchResult.C
PatchValueExpressionParser.C
PatchValueExpressionLexer.C
PatchValueExpressionDriver.C
groovyBCFvPatchFields.C
groovyBCPointPatchFields.C

LIB = $(FOAM_USER_LIBBIN)/libgroovyBC

When I ran wmake libso again I get the same response as above i.e.:

wmakeLnInclude: linking include files to ./lnInclude
find: invalid predicate `-L'
Making dependency list for source file PatchValueExpressionLexer.ll
Making dependency list for source file groovyBCPointPatchFields.C
could not open file MixedPointPatchField.H for source file groovyBCPointPatchFields.C
could not open file PointPatchFieldMapper.H for source file groovyBCPointPatchFields.C
Making dependency list for source file groovyBCFvPatchFields.C
Making dependency list for source file PatchValueExpressionDriver.C
Making dependency list for source file PatchValueExpressionParser.yy
Making dependency list for source file PatchResult.C
SOURCE=PatchResult.C ; g++ -m64 -Dlinux64 -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3 -DNoRepository -ftemplate-depth-40 -IMake/linux64GccDPOpt -I/share/home/01389/edoro/OpenFOAM/OpenFOAM-1.7.x/src/finiteVolume/lnInclude -IlnInclude -I. -I/share/home/01389/edoro/OpenFOAM/OpenFOAM-1.7.x/src/OpenFOAM/lnInclude -I/share/home/01389/edoro/OpenFOAM/OpenFOAM-1.7.x/src/OSspecific/POSIX/lnInclude -fPIC -c $SOURCE -o Make/linux64GccDPOpt/PatchResult.o
PatchResult.C: In member function 'void Foam::PatchResult::uglyDelete()':
PatchResult.C:95: warning: deleting 'void*' is undefined
SOURCE=PatchValueExpressionParser.yy ; rm -f Make/linux64GccDPOpt/PatchValueExpressionParser.C Make/linux64GccDPOpt/PatchValueExpressionParser.tab.hh; bison -ra -v -d $SOURCE ; mv *.tab.cc Make/linux64GccDPOpt/PatchValueExpressionParser.C ; mv *.tab.hh Make/linux64GccDPOpt/PatchValueExpressionParser.tab.hh ; mv *.hh Make/linux64GccDPOpt ; g++ -m64 -Dlinux64 -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3 -DNoRepository -ftemplate-depth-40 -IMake/linux64GccDPOpt -I/share/home/01389/edoro/OpenFOAM/OpenFOAM-1.7.x/src/finiteVolume/lnInclude -IlnInclude -I. -I/share/home/01389/edoro/OpenFOAM/OpenFOAM-1.7.x/src/OpenFOAM/lnInclude -I/share/home/01389/edoro/OpenFOAM/OpenFOAM-1.7.x/src/OSspecific/POSIX/lnInclude -fPIC -c Make/linux64GccDPOpt/PatchValueExpressionParser.C -o Make/linux64GccDPOpt/PatchValueExpressionParser.o
PatchValueExpressionParser.yy:29.1-15: invalid directive: `%initial-action'
PatchValueExpressionParser.yy:30.1-33.1: syntax error, unexpected "{...}"
mv: cannot stat `*.tab.cc': No such file or directory
mv: cannot stat `*.tab.hh': No such file or directory
mv: cannot stat `*.hh': No such file or directory
g++: Make/linux64GccDPOpt/PatchValueExpressionParser.C: No such file or directory
g++: no input files
make: *** [Make/linux64GccDPOpt/PatchValueExpressionParser.o] Error 1

When run wmake libso a second time after this first error message above, I now get this message:


make: *** No rule to make target `Make/linux64GccDPOpt/PatchValueExpressionParser.tab.hh', needed by `groovyBCPointPatchFields.dep'. Stop.


I still have no idea what to make of these error messages. Could you please help.

Thanks.

[ovie]

The problem had entirely to do with the version of Bison.

I managed to install a more recent version in my ~/ on the cluster and modified my $PATH accordingly. So the newer version is seen first before the older cluster supplied version.

I recompiled without the bypass and everything seems ok. Hopefully testing a computation would confirm all is well.

Thanks a lot for the response.

[philippose]

Hello Bernhard,

A Good Morning to you :-)! (ok.. its almost lunch time :-)!)

I have been back trying some tricks using the fabled groovyBC.... or should we say,
"grooving with groovyBC and swak4Foam" :-)!

And I have come across an issue which we have already discussed before. Basically,
it has to do with the combination:

groovyBC + OpenFOAM-1.6-ext + Parallel Simulations

When I try to calculate values on an another patch using "<variable>{patch'<patch Name>}" when
running in parallel, I get the following warning:

[See Attachment.....]

Is this warning anything I should be worried about? The warning claims that the average value is
being taken, but how is this average calculated?

In my case, the patch on which I was calculating the value was only present on 1 of 3 processors
of the parallel simulation, and groovyBC always took the right value (though it said that it was
taking an average).

What happens when parts of a patch are found on more than one processor?

I was for some reason under the impression that this issue was fixed in 1.6-ext, and had something
to do with pTraits?

Have a great day ahead!

Philippose

(P.S.... I can't stop feeling a sense of awe each time when I find "yet another" use for groovyBC and
swak4Foam :-)! Thanks a lot!)

[gschaider]

Originally Posted by philippose

Hello Bernhard,

A Good Morning to you :-)! (ok.. its almost lunch time :-)!)

I have been back trying some tricks using the fabled groovyBC.... or should we say,
"grooving with groovyBC and swak4Foam" :-)!

And I have come across an issue which we have already discussed before. Basically,
it has to do with the combination:

groovyBC + OpenFOAM-1.6-ext + Parallel Simulations

When I try to calculate values on an another patch using "<variable>{patch'<patch Name>}" when
running in parallel, I get the following warning:

[See Attachment.....]

Is this warning anything I should be worried about? The warning claims that the average value is
being taken, but how is this average calculated?

In my case, the patch on which I was calculating the value was only present on 1 of 3 processors
of the parallel simulation, and groovyBC always took the right value (though it said that it was
taking an average).

What happens when parts of a patch are found on more than one processor?

I was for some reason under the impression that this issue was fixed in 1.6-ext, and had something
to do with pTraits?

Have a great day ahead!

Philippose

(P.S.... I can't stop feeling a sense of awe each time when I find "yet another" use for groovyBC and
swak4Foam :-)! Thanks a lot!)

Hi Philippose!

Thanks for your kind words about swak.

Your analysis is right:

a) the warning can be ignored (see below)
b) it has to do with pTraits and I remember that is was fixed some time ago

Basically the problem are gMin and gMax. They return 0 if there is no face on that processor which "wins" against the values from the other processors (if they're on the wrong side)

gAverage on the other hand does everything alright - this is the value that is actually used

The original posting about this is found at http://www.cfd-online.com/Forums/ope...llel-runs.html

So it should be fixed in 1.6-ext. If it isn't please be so nice and write a report on the openfoam-extend-Mantis so that it comes to Hrv's attention

Bernhard

[philippose]

Hello again Bernhard,

As always, thank you very much for the quick response, and for confirming that I do not need to worrying about the warning :-)!

The Simulation I was running while I posted on the thread today went through to the end without any problems, and also ended up with good results, so I can "re-"confirm that the warning is more informational than anything else.

I shall try to see if the issue you pointed me to has been fixed or not....

I wish you a great evening ahead :-)!

Philippose

[s_braendli]

Hello everybody

I am working on the groovyWaveTank case and would like to introduce the global variables from swak4foam.

This is how my entry in the controlDict looks like:

defineSurfaceZ {
  type addGlobalVariable ;
  outputControl timeStep; // required by OpenFOAM
  outputInterval 1 ; // required by OpenFOAM
  gloalName surfZ;
  globalScope myWave ;
  valueType scalar ;
  value 0.0;
};

And my funkySetFieldsDict:

globalScopes ( "myWave" );

expressions
 (
     alpha1a
    {
        field alpha1;
        expression "0.";
        keepPatches;
        }
    alpha1b
    {
        field alpha1;
        expression "1.";
        condition "pos().z <= surfZ";
        keepPatches;
        }
 );

And the error I get:

Part: alpha1a
 Modifying field alpha1 of type volScalarField

 Putting "0." into field alpha1 at t = "0" if condition "true" is true

 Setting 8000 of 8000 cells
 Writing to "alpha1"


Part: alpha1b
 Modifying field alpha1 of type volScalarField

 Putting "1." into field alpha1 at t = "0" if condition "pos().z <= surfZ" is true

swak4Foam: Allocating new repository for sampledGlobalVariables


--> FOAM FATAL ERROR: 
 Parser Error at "1.12-16" :"field surfZ not existing or of wrong type"
"pos().z <= surfZ"
"            ^^^^^"

    From function parsingValue
    in file lnInclude/CommonValueExpressionDriverI.H at line 724.

FOAM exiting

Obviously the variable surfZ is not known by funkySetFields. (I also tried surfZ@myWave, which seems to be an old syntax)

I would be happy about any hints.

Best regards
Silvan

[gschaider]

Originally Posted by s_braendli

Hello everybody

I am working on the groovyWaveTank case and would like to introduce the global variables from swak4foam.

This is how my entry in the controlDict looks like:

defineSurfaceZ {
  type addGlobalVariable ;
  outputControl timeStep; // required by OpenFOAM
  outputInterval 1 ; // required by OpenFOAM
  gloalName surfZ;
  globalScope myWave ;
  valueType scalar ;
  value 0.0;
};

And my funkySetFieldsDict:

globalScopes ( "myWave" );

expressions
 (
     alpha1a
    {
        field alpha1;
        expression "0.";
        keepPatches;
        }
    alpha1b
    {
        field alpha1;
        expression "1.";
        condition "pos().z <= surfZ";
        keepPatches;
        }
 );

And the error I get:

Part: alpha1a
 Modifying field alpha1 of type volScalarField

 Putting "0." into field alpha1 at t = "0" if condition "true" is true

 Setting 8000 of 8000 cells
 Writing to "alpha1"


Part: alpha1b
 Modifying field alpha1 of type volScalarField

 Putting "1." into field alpha1 at t = "0" if condition "pos().z <= surfZ" is true

swak4Foam: Allocating new repository for sampledGlobalVariables


--> FOAM FATAL ERROR: 
 Parser Error at "1.12-16" :"field surfZ not existing or of wrong type"
"pos().z <= surfZ"
"            ^^^^^"

    From function parsingValue
    in file lnInclude/CommonValueExpressionDriverI.H at line 724.

FOAM exiting

Obviously the variable surfZ is not known by funkySetFields. (I also tried surfZ@myWave, which seems to be an old syntax)

I would be happy about any hints.

Best regards
Silvan

You've got to put the globalScopes-entry INTO the subdict of the boundary condition (the way it is done in the fillingTheDam-example). When initializing the parser ignores information in the parent dictionary (although convenient sometimes this would only lead to behaviour that would confuse the user)

[s_braendli]

Thanks for the fast reply. Unfortunately I get the next error:

Part: alpha1b
 Modifying field alpha1 of type volScalarField

 Putting "1." into field alpha1 at t = "0" if condition "pos().z <= surfZ" is true

swak4Foam: Allocating new repository for sampledGlobalVariables
--> FOAM Warning : 
    From function GlobalVariablesRepository::get
    in file GlobalVariablesRepository.C at line 93
    There is no scope wave1 in the list of global scopes 
0
(
)
 when looking for surfZ

[...]

--> FOAM FATAL ERROR: 
 Parser Error at "1.12-16" :"field surfZ not existing or of wrong type"
"pos().z <= surfZ"
"            ^^^^^"

    From function parsingValue
    in file lnInclude/CommonValueExpressionDriverI.H at line 724.

FOAM exiting

It looks like my definition of the variable is not yet OK:

functions
{
defineSurfaceZ {
  type addGlobalVariable ;
  outputControl timeStep;
  outputInterval 1;
  
  globalScope wave1;
  globalVariables {
    surfZ {
      valueType scalar;
      value 0.0;
      }
  }
};


};

libs 
(
"libOpenFOAM.so"
"libgroovyBC.so"
"libsimpleSwakFunctionObjects.so"
"libswakFunctionObjects.so"
);

Or, a basic question, is it possible to use the global variables with funkySetFields at all? (Are the function objects loaded?)

[gschaider]

Originally Posted by s_braendli

Thanks for the fast reply.

Don't get used to it

Originally Posted by s_braendli

Unfortunately I get the next error:

Part: alpha1b
 Modifying field alpha1 of type volScalarField

 Putting "1." into field alpha1 at t = "0" if condition "pos().z <= surfZ" is true

swak4Foam: Allocating new repository for sampledGlobalVariables
--> FOAM Warning : 
    From function GlobalVariablesRepository::get
    in file GlobalVariablesRepository.C at line 93
    There is no scope wave1 in the list of global scopes 
0
(
)
 when looking for surfZ

[...]

--> FOAM FATAL ERROR: 
 Parser Error at "1.12-16" :"field surfZ not existing or of wrong type"
"pos().z <= surfZ"
"            ^^^^^"

    From function parsingValue
    in file lnInclude/CommonValueExpressionDriverI.H at line 724.

FOAM exiting

It looks like my definition of the variable is not yet OK:

functions
{
defineSurfaceZ {
  type addGlobalVariable ;
  outputControl timeStep;
  outputInterval 1;
  
  globalScope wave1;
  globalVariables {
    surfZ {
      valueType scalar;
      value 0.0;
      }
  }
};


};

libs 
(
"libOpenFOAM.so"
"libgroovyBC.so"
"libsimpleSwakFunctionObjects.so"
"libswakFunctionObjects.so"
);

Or, a basic question, is it possible to use the global variables with funkySetFields at all? (Are the function objects loaded?)

No. They're not (loaded) .... by default. But you can switch them on with -allowFunctionObjects

[s_braendli]

Good hint :-)

Another point: To me it looks like the newest version of swak4Foam is compatible with 2.1.0, but not with 2.0.0. When I compile with 2.0.0 I get the following:

Bison is version 2.5
No 'swakConfiguration'. Python etc won't work
OpenFOAM-version: Major 2 Minor 0 Patch 0
[...]
SOURCE=groovyBCCommons.C ;  g++ -m64 -Dlinux64 -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3  -DNoRepository -ftemplate-depth-100 -IMake/linux64GccDPOpt           -I/opt/OpenFOAM/OpenFOAM-2.0.0/src/finiteVolume/lnInclude -I../swak4FoamParsers/lnInclude/ -IlnInclude -I. -I/opt/OpenFOAM/OpenFOAM-2.0.0/src/OpenFOAM/lnInclude -I/opt/OpenFOAM/OpenFOAM-2.0.0/src/OSspecific/POSIX/lnInclude   -fPIC -c $SOURCE -o Make/linux64GccDPOpt/groovyBCCommons.o
SOURCE=groovyBCFvPatchFields.C ;  g++ -m64 -Dlinux64 -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3  -DNoRepository -ftemplate-depth-100 -IMake/linux64GccDPOpt           -I/opt/OpenFOAM/OpenFOAM-2.0.0/src/finiteVolume/lnInclude -I../swak4FoamParsers/lnInclude/ -IlnInclude -I. -I/opt/OpenFOAM/OpenFOAM-2.0.0/src/OpenFOAM/lnInclude -I/opt/OpenFOAM/OpenFOAM-2.0.0/src/OSspecific/POSIX/lnInclude   -fPIC -c $SOURCE -o Make/linux64GccDPOpt/groovyBCFvPatchFields.o
SOURCE=groovyBCDirectionFvPatchFields.C ;  g++ -m64 -Dlinux64 -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3  -DNoRepository -ftemplate-depth-100 -IMake/linux64GccDPOpt           -I/opt/OpenFOAM/OpenFOAM-2.0.0/src/finiteVolume/lnInclude -I../swak4FoamParsers/lnInclude/ -IlnInclude -I. -I/opt/OpenFOAM/OpenFOAM-2.0.0/src/OpenFOAM/lnInclude -I/opt/OpenFOAM/OpenFOAM-2.0.0/src/OSspecific/POSIX/lnInclude   -fPIC -c $SOURCE -o Make/linux64GccDPOpt/groovyBCDirectionFvPatchFields.o
SOURCE=groovyBCFixedValueFvPatchFields.C ;  g++ -m64 -Dlinux64 -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3  -DNoRepository -ftemplate-depth-100 -IMake/linux64GccDPOpt           -I/opt/OpenFOAM/OpenFOAM-2.0.0/src/finiteVolume/lnInclude -I../swak4FoamParsers/lnInclude/ -IlnInclude -I. -I/opt/OpenFOAM/OpenFOAM-2.0.0/src/OpenFOAM/lnInclude -I/opt/OpenFOAM/OpenFOAM-2.0.0/src/OSspecific/POSIX/lnInclude   -fPIC -c $SOURCE -o Make/linux64GccDPOpt/groovyBCFixedValueFvPatchFields.o
SOURCE=groovyBCJumpFvPatchFields.C ;  g++ -m64 -Dlinux64 -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3  -DNoRepository -ftemplate-depth-100 -IMake/linux64GccDPOpt           -I/opt/OpenFOAM/OpenFOAM-2.0.0/src/finiteVolume/lnInclude -I../swak4FoamParsers/lnInclude/ -IlnInclude -I. -I/opt/OpenFOAM/OpenFOAM-2.0.0/src/OpenFOAM/lnInclude -I/opt/OpenFOAM/OpenFOAM-2.0.0/src/OSspecific/POSIX/lnInclude   -fPIC -c $SOURCE -o Make/linux64GccDPOpt/groovyBCJumpFvPatchFields.o
In file included from groovyBCJumpFvPatchFields.H:37:0,
                 from groovyBCJumpFvPatchFields.C:36:
groovyBCJumpFvPatchField.H:46:35: fatal error: fixedJumpFvPatchField.H: No such file or directory
compilation terminated.
make: *** [Make/linux64GccDPOpt/groovyBCJumpFvPatchFields.o] Error 1

As there is no file fixedJumpFvPatchField.H in my 2.0.0 version, this behaviour isn't astonishing... However with 2.1.0 everything is fine and I enjoy your great tool.

[gschaider]

Originally Posted by s_braendli

Good hint :-)

Another point: To me it looks like the newest version of swak4Foam is compatible with 2.1.0, but not with 2.0.0. When I compile with 2.0.0 I get the following:

Bison is version 2.5
No 'swakConfiguration'. Python etc won't work
OpenFOAM-version: Major 2 Minor 0 Patch 0
[...]
SOURCE=groovyBCCommons.C ;  g++ -m64 -Dlinux64 -DWM_DP -Wall -

<SNIP>

groovyBCJumpFvPatchField.H:46:35: fatal error: fixedJumpFvPatchField.H: No such file or directory
compilation terminated.
make: *** [Make/linux64GccDPOpt/groovyBCJumpFvPatchFields.o] Error 1

As there is no file fixedJumpFvPatchField.H in my 2.0.0 version, this behaviour isn't astonishing... However with 2.1.0 everything is fine and I enjoy your great tool.

The file is in my 2.0.x-installation. So it seems that it sneaked in there sometime after the 2.0.0-release. Sorry, but you'll understand that there is only a limited number of versions I can support and usually I go for the .x-variety. My best advice is to comment it out or use the release that I did immediately after the .0-version

[Amir]

Dear Bernhard,

I have a question in setting a special BC in dynamic mesh and I'm not sure whether the groovyBC can handle that or not:
suppose T is a tensor and I wanna set "div(T).n= a surface field" over the boundary. n is the unit normal vector of boundary faces.
Would you please explain if it's possible?

Bests,

[gschaider]

Originally Posted by Amir

Dear Bernhard,

I have a question in setting a special BC in dynamic mesh and I'm not sure whether the groovyBC can handle that or not:
suppose T is a tensor and I wanna set "div(T).n= a surface field" over the boundary. n is the unit normal vector of boundary faces.
Would you please explain if it's possible?

Bests,

groovyBC per se not. In the 2.0x-branch (just found out that it was never merged into the 1.x-branch) there is a groovyBCDirectionMixed that might be able to do what you want to do. It is based on directionMixed (have a look at the UserGuide what that does)

[Amir]

Originally Posted by gschaider

groovyBC per se not. In the 2.0x-branch (just found out that it was never merged into the 1.x-branch) there is a groovyBCDirectionMixed that might be able to do what you want to do. It is based on directionMixed (have a look at the UserGuide what that does)

Thanks Bernhard

Bests,

[RitaFC]

Hi

I wish I could also enjoy swak4Foam. I need some help.
I have experience in CFD and I start to use open Foam a few months ago. I has ubuntu 10.10 and openFoam 1.7 in one computer and evrything OK.
I passed the last days trying to use groovybc. I instaled in a different computer vmware, ubuntu 11.10, openFoam2.0.1, bison2.5 flex2.5.35 m4.1.4.10 Apparentely it was everything OK but not with swak4Foam.

I read a lot of questions/answers but I still have problems. I did the same however with "wmake all" and ".Allwmake", I have some messages with "not found" and "could not open file" and finally
make: Target `application' not remade because of errors.

I wonder if you can help me checking if the version I used are ok and in which directory the comands to install swak4Foam:
1- openFoam directory
svn checkout https://openfoam-extend.svn.sourcefo...ies/swak4Foam/
or
hg clone http://openfoam-extend.hg.sourceforg...tend/swak4Foam
2- home directory wmake all or (.Allwmake doesn't work)
3- make install

[gschaider]

Originally Posted by RitaFC

Hi

I wish I could also enjoy swak4Foam. I need some help.
I have experience in CFD and I start to use open Foam a few months ago. I has ubuntu 10.10 and openFoam 1.7 in one computer and evrything OK.
I passed the last days trying to use groovybc. I instaled in a different computer vmware, ubuntu 11.10, openFoam2.0.1, bison2.5 flex2.5.35 m4.1.4.10 Apparentely it was everything OK but not with swak4Foam.

I read a lot of questions/answers but I still have problems. I did the same however with "wmake all" and ".Allwmake", I have some messages with "not found" and "could not open file" and finally
make: Target `application' not remade because of errors.

I wonder if you can help me checking if the version I used are ok and in which directory the comands to install swak4Foam:
1- openFoam directory
svn checkout https://openfoam-extend.svn.sourcefo...ies/swak4Foam/
or
hg clone http://openfoam-extend.hg.sourceforg...tend/swak4Foam
2- home directory wmake all or (.Allwmake doesn't work)
3- make install

Could you be more specific about step 2 (why ./Allwmake does not work). Step 3 ("make install") is NOT recommended

[RitaFC]

Originally Posted by gschaider

Could you be more specific about step 2 (why ./Allwmake does not work). Step 3 ("make install") is NOT recommended

I thank you for your reply.
Perhaps Bison is not correctely installed.
1 - I download swak4Foam withot problems. In which directhory it should be placed ?
2 - Moving to the swak4Foam directory - Doing "./Allwmake" - Appears:
No 'swakConfiguration'. Python etc won't work
Checking swak4Foam- version and generating file
./Allwmake: 9: ... not found
./Allwmake: 17: ... not found
./Allwmake: 19: bison: not found
Bison is version
...
Can you give me a opinion what to do ?
Kind regards,
Rita