CFD Online Discussion Forums

CFD Online Discussion Forums (
-   OpenFOAM Community Contributions (
-   -   [swak4Foam] GroovyBC the dynamic cousin of funkySetFields that lives on the suburb of the mesh (

gschaider February 19, 2009 18:10

GroovyBC the dynamic cousin of funkySetFields that lives on the suburb of the mesh

Those who find funkySetFields useful might find this interesting:

Basically it is a mixed-boundary condition where value, gradient and valueFraction can be specified using expressions.


PS: Starting from now I will answer all questions concerning setParabolicInlet.C with "Use groovyBC". That was the main reason for writing that boundary condition: setParabolicInlet on steroids

egp February 20, 2009 05:36

Bernhard, You're the man!

You're the man! Funky + pyFoam + Groovy is the trifecta of OpenFOAM! I officially nominate you for the 2009 OpenFOAM MVP award, which will be presented at the 2009 Workshop in Montreal by the AOFAS (Academy of OpenFOAM Arts and Sciences) ;-) Any ideas for a prize worthy of this award??

On a serious note: good job, and thanks for contributions!


alexandrepereira February 25, 2009 10:35

Hi Bernhard I have tried
Hi Bernhard

I have tried groovyBC, nice tool... :-D

BTW I have checked your posting in SVN, and I have a question :

Supposing I want to calculate the total ammount of NO2 in a dieselEngineFoam simulation in each time slice of my simulation, how could i use the volumeFieldFunctionObject that you posted in the SVN repository...? I mean, that is what that library is for, tight...?!

Best regards


gschaider February 26, 2009 10:31

Hi Alex! Did you have a loo
Hi Alex!

Did you have a look at the README there? It refers you to (which is for my standards a quite exhaustive documentation)

Yes. Something like

NO2Total {
type volumeIntegrate;
verbose true;
fields (

should do that. BUT as you are propably aware NO2 is the Mass-fraction and integrating that is only meaningful if the density is constant (IMHO). So what you'd need is something like

fields (

and that is currently not possible (it would mean marrying the funkySetFields-function parser with a function object - not that difficult, basically one would have to tell the parser "get the files from the database not the disk", but it still needs some time)


alexandrepereira February 26, 2009 11:00

Hi Bernhard Thx for the hin
Hi Bernhard

Thx for the hint... :-)



alexandrepereira February 26, 2009 11:47

Hi Again Bernhard, As long
Hi Again Bernhard,

As long as my ( tiny ) C++ knowledge does not allow for more, I will resort to a "crude" but effective solution :

For each time, write the volScalarField rho*[NO2] and after the simulation use the volumeIntegrate functionObject to query the FOAM database and understand if Mr Yakov Borisovich Zeldovich will allow me to design a low emission high compression ratio HCCI engine... !!

I think tha dieselEngineFoam is the right app to do this... since I will use a blend of DME and isoOctane, with high fraction of exhaust recycle gas and a very lean burn stoichiometry, I can assume tha most of my fuel droplets will be evaporated at time of ignition, leading to Homogeneous charge premixed flame combustion...

( This is what i think... )

Tyx anyway



gschaider February 26, 2009 13:28

Hi Alex! I was thinking to
Hi Alex!

I was thinking to complicated (funkyFieldsFunctionObject). Of course, if you're willing to to modify your solver then you don't even have to write to disk. Just create (outside the timeloop!) a field named "NO2mass" (not the variable name. The name in the IOobject-part is important). Update it at every timestep. If you add it to the fields list the function object will find it (praise to the objectRegistry and to its implementor)


alexandrepereira February 27, 2009 10:12

Hi Bernhard I changed the s
Hi Bernhard

I changed the solver, and now i can access volumeIntegrated quantities.. nice piece of code your simpleFunctionObjects... :-)

Now for one more question , simpleFunctionObjects compiles trivially in Linux gcc, I ported it ( at least tried to ) to win32 using the cross compiler mingw32, so that ppl at mechanical engineering department in my university can use it in win simulations with OpenFOAM; You see. at my department ppl are very ..."conservative" meaning that they have the "Microsoft mindset" so... convincing them to shift to Linux is not an easy task...

Anyway, I tried to build the dll under mingw32 compiler, and it reports that HUGE, which is refered to in panicDump.C is not defined within that scope...

Since i do not know enough of the class hierarchy in OpenFOAM, which #include should i add to panicDump.H in order to the linker to find "HUGE"...? were is it defined... ?

mingw32 linker is not as "smart" as g++, i guess.. :-(

Thx for yr help :-)


marico March 2, 2009 05:50

Hi Bernhard! Question to Yo
Hi Bernhard!

Question to Your groovyBC: Can I create boundary conditions for dynamicFvMesh solver (e. g. displacementLaplacian) with this tool? Propably not, because a pointScalarField has to be defined?!...
Is there a way to do this?
How long do I have to wait until groovyBC is able to? ;)

Thanks a lot

gschaider March 2, 2009 07:24

@Alexandre: The problem is no
The problem is not the compiler. It is that from math.h the line
# define HUGE 3.40282347e+38F
seems to be missing for the mingw-headers. As a quick fix just insert this line into panicDump.H

Way ahead of you. Last week I checked the groovyBCPointPatch-class into the svn. I just didn't announce it. There is also a small demo for that there (an addaption of the icoDyMFoam/movingCone). Just do a "svn update", recompile and you should be set


alexandrepereira March 2, 2009 08:27

Hi Bernhard Thanks a lot :-
Hi Bernhard

Thanks a lot :-)

I will try this



marico March 3, 2009 03:29

Hi Bernhard, thanks a lot,
Hi Bernhard,

thanks a lot, too. (Das müsste meiner Diplomarbeit ziemlich gut helfen... ;)


lin March 3, 2009 11:05

Hi Bernhard Thanks for your c
Hi Bernhard
Thanks for your contribution.

I have a feature request and wonder whether it's possible.

It seems that both funkySetFields and GroovyBC are only for analytical expressions.I wonder whether these utilities could read in data from a file instead of expression.Then the user could use any programming language to generate more complicated fields for the initial and boundary conditions and then use these utilities to start running.

gschaider March 3, 2009 12:23

Hi Hua! For boundary condit
Hi Hua!

For boundary conditions the timeVaryingMappedFixedValue-condition might be just what you need (haven't used it myself; have a look at the board for that). For initial-conditions I don't see the point:
a) if you get the data from another program/solver foo then you'll have to write a data-convert for that format: fooToFoam (have a look maybe the converter is already there)
b) if you write a custom-built program, then you might as well write it in OpenFOAM-C++ because that situation boils down to case a)

So: no. There are currently no plans for that, unless the need for that arises in one of the projects I get paid for.


lin March 3, 2009 15:01

Hi Bernhard Thanks for you
Hi Bernhard

Thanks for your reply and useful infomation.

marico March 5, 2009 07:24

Hi Bernhard, just tried com
Hi Bernhard,

just tried compiling groovyBC, seems that there are (at least) two files missing:

could not open file for source file groovyBCPointPatchFields.C
could not open file pointPatchFieldMapper.H for source file groovyBCPointPatchFields.C

Maybe you can help?


gschaider March 5, 2009 08:27

Hi Marco! PatchValueExpress
Hi Marco! is generated from the yy-File and will live in the Make-directory.

According to groovyBCPointPatchFields.dep the other file should reside here: $(WM_PROJECT_DIR)/src/OpenFOAM/lnInclude/pointPatchFieldMapper.H

Which version are you using? I compiled and tested that BC with a vanilla-1.5. I quickly checked and it seems to me that this file is not present in the dev-version. Maybe it's called differently or resides somewhere else. Don't know (there seems to be a number of other stuff missing from the dev that is needed for the point-BC)

I think for the time being you'll have to remove groovyBCPointPatchFields.C from Make/files and live without the point variant.
Or you try to cheat: copy the files that compiler is missing from a vailla/git-version to the directory of the library and compile (the compiler should find them now). Repeat until the compiler runs out of complaints. But even if it compiles I can't guarantee that it will work.


marico March 5, 2009 08:57

Hi Bernhard, thanks for loo
Hi Bernhard,

thanks for looking after it. I installed 1.5-dev (I read it would be better for dynamic mesh cases than the 1.5 binary because of bugs... ;)
So I placed the x.H and x.C files needed in my InInclude directory and it seems that compilation went well except of warnings:

PatchResult.C:88: warning: deleting 'void*' is undefined
... warning: use of old-style cast
groovyBCPointPatchField.C: In function 'const Foam::fvPatch& Foam::getFvPatch(const Foam::pointPatch&)':
groovyBCPointPatchField.C:55: warning: control reaches end of non-void function

I'll try probably tomorrow if it works


marico March 6, 2009 04:21

Hi again, I just tried out
Hi again,

I just tried out groovyBC and got the following error at the beginning of calculation:

could not load /home/../linuxGccDPOpt/ undefined symbol: _ZN4Foam20mixedPointPatchFieldINS_6TensorIdEEE8typ eNameE

Best Regards,

gschaider March 6, 2009 04:30

OK. This means that more cheat
OK. This means that more cheating is necessary. Get mixedPointPatchFields.C (the s is important) and add it to Make/files. Don't know when this will stop. Sorry

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