[gschaider]

Hi!

Those who find funkySetFields useful might find this interesting: http://openfoamwiki.net/index.php/Contrib_groovyBC

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

Bernhard

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]

Bernhard,

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!

Eric

[alexandrepereira]

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

Alex

[gschaider]

Hi Alex!

Did you have a look at the README there? It refers you to http://openfoamwiki.net/index.php/Co...unctionObjects (which is for my standards a quite exhaustive documentation)

Yes. Something like

NO2Total {
type volumeIntegrate;
functionObjectLibs
(
"libsimpleFunctionObjects.so"
);
verbose true;
fields (
NO2
);
}

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 (
NO2*rho
);

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)

Bernhard

[alexandrepereira]

Hi Bernhard

Thx for the hint... :-)

BRGDS

Alex

[alexandrepereira]

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

BRGDS

Alex

[gschaider]

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)

Bernhard

[alexandrepereira]

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 :-)

Alex

[marico]

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
Marco

[gschaider]

@Alexandre:
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

@marco:
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]

Hi Bernhard

Thanks a lot :-)

I will try this

BRGDS

Alexandre

[marico]

Hi Bernhard,

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

Marco

[lin]

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]

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.

Bernhard

[lin]

Hi Bernhard

Thanks for your reply and useful infomation.

[marico]

Hi Bernhard,

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

could not open file PatchValueExpressionParser.tab.hh for source file groovyBCPointPatchFields.C
could not open file pointPatchFieldMapper.H for source file groovyBCPointPatchFields.C

Maybe you can help?

Thanks
Marco

[gschaider]

Hi Marco!

PatchValueExpressionParser.tab.hh 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.

Bernhard

[marico]

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
...
lex.ve.c:363: 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

Marco

[marico]

Hi again,

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

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

Best Regards,
Marco

[gschaider]

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