[philippose]

Hello Bernhard,

A Good Evening to you :-)!

Its been a while since my last post, but as always, that does not imply that I am not busy sniffing around OpenFOAM :-)!

I just wanted to inform you, that for the first time today, I actually used the "pythonIntegration" functionObject in swak4Foam for a real case.......

And..... lets say..... I literally fell off my seat with excitement that I could barely contain :-)! I basically mixed up pythonIntegration and PyFoam (like in one of your tutorials featuring Ignaz :-)!), and it worked beautifully.

Suddenly, it feels like a whole new world of capabilities just opened up.... and I am slowly filling up with ideas of how this feature could be utilised :-)!

My sincere appreciation and gratitude to you (and your team?) for the amazing work :-)!

Is there any way I could help out with the documentation of the pythonIntegration (and other features of swak4Foam / groovyBC) feature? Do you have anything specific in mind?

Wishing you a great evening ahead!

Philippose

[gschaider]

Originally Posted by philippose

Hello Bernhard,

A Good Evening to you :-)!

Its been a while since my last post, but as always, that does not imply that I am not busy sniffing around OpenFOAM :-)!

I just wanted to inform you, that for the first time today, I actually used the "pythonIntegration" functionObject in swak4Foam for a real case.......

And..... lets say..... I literally fell off my seat with excitement that I could barely contain :-)! I basically mixed up pythonIntegration and PyFoam (like in one of your tutorials featuring Ignaz :-)!), and it worked beautifully.

Suddenly, it feels like a whole new world of capabilities just opened up.... and I am slowly filling up with ideas of how this feature could be utilised :-)!

My sincere appreciation and gratitude to you (and your team?) for the amazing work :-)!

Is there any way I could help out with the documentation of the pythonIntegration (and other features of swak4Foam / groovyBC) feature? Do you have anything specific in mind?

Wishing you a great evening ahead!

Philippose

Hello Philippose!

Thank you for your kind words and your enthusiasm for the pythonIntegration.

About the documentation: this is on my TODO list. Especially a complete list of the implemented functions and operators in the grammar. My plan is to write it in org-mode (because that way I can store it with the repository) and then convert that to the Wiki.
Apart from that part about the grammar and the basics of the expression dictionaries (I think it is best if these things are written by only one person) I'm open for contributions to the documentation. I think the best way to start is insert a new section on the Wiki page ("Other topics") and in that start with a subsection that interests you ("Python integration" for instance). Once I have a general concept for the documentation I'll be happy to copy-paste it there

Bernhard

[philippose]

Hello again Bernhard,

A Good Evening to you! Hope you have the same brilliantly blue weather there like we have here in Cologne :-)!

I have one question regarding the pythonIntegration library.....

I was running a parallel Simulation today, and found that the "caseDir" variable which gets passed into python from the functionObject is:

** For a serial run: <case_root_dir>

** For a parallel run: <case_root_dir>/processor0 (with parallelMasterOnly set to true)

** For a parallel run: <case_root_dir>/processor<num> (without parallelMasterOnly)

This causes access to the "fvSolution" or "fvSchemes" files for example, to be different for serial and parallel cases.

Usually, when a case is decomposed using "decomposePar", the system directory is not copied into each processor directory. This causes the python script to fail when trying to access the system directory.

Currently, I need to use the "parRun" variable to check if the run is a serial or parallel run, and modify the "caseDir" appropriately.


Was this meant to be this way? Or is it an oversight / bug?

Have a nice day!

Philippose

[gschaider]

Originally Posted by philippose

I have one question regarding the pythonIntegration library.....

I was running a parallel Simulation today, and found that the "caseDir" variable which gets passed into python from the functionObject is:

** For a serial run: <case_root_dir>

** For a parallel run: <case_root_dir>/processor0 (with parallelMasterOnly set to true)

** For a parallel run: <case_root_dir>/processor<num> (without parallelMasterOnly)

This causes access to the "fvSolution" or "fvSchemes" files for example, to be different for serial and parallel cases.

Usually, when a case is decomposed using "decomposePar", the system directory is not copied into each processor directory. This causes the python script to fail when trying to access the system directory.

Currently, I need to use the "parRun" variable to check if the run is a serial or parallel run, and modify the "caseDir" appropriately.


Was this meant to be this way? Or is it an oversight / bug?

Have a nice day!

Philippose

Oversight/bug: Yes and now. At the time of the implementation I decided to use the Time.path()-method (which shows exactly the behaviour you describe above) because I figured that each processor should immediately start with "his" data (so that there is no temptation to mess with other processors). I then thought about adding a "rich" interface by providing systemDir, constantDir but forgot about it. The thing is that this allows the user to shot himself in the foot big-time by modifying controlDict from ALL processors so maybe systemDir should only be exposed for parallelMasterOnly. What do you think?

[philippose]

Hi Bernhard,

A Good Evening to you :-)!

Thanks for your response..... I had noticed that the issue was stemming from the fact that you were using the "Time.path()" approach to get the "caseDir".

I think we should probably try to define the implications of the different variables.....:

1. caseDir: I think this variable should always point to the "root" folder of the simulation, because as the name suggests, this is the directory of the entire Simulation case........ Hence, I think regardless of whether the simulation run is parallel or serial, "caseDir" should always be the root directory... equivalent to "$FOAM_CASE"....... I think it is ok (even required?) for this variable to be available for all processors of a parallel run or?

2. systemDir: As far as I have seen / experienced, there exists only one "system" directory, and this exists at "$FOAM_CASE/system", or? Are there any OpenFOAM solvers which need a separate "system" folder within each processor folder? If only one system folder is required, then as you said, I think the "systemDir" variable should be available only to the "Master Processor" in a parallel run, and should always be "$FOAM_CASE/system"

3. constantDir: This one is a little tough :-)! When an OpenFOAM case is decomposed for a parallel simulation, each processor folder gets its own "constant" folder, because it contains the corresponding parts of the mesh for each processor. On the other hand, settings for turbulence and transport medium are located only in the main "$FOAM_CASE/constant" folder...... Do you think it is enough to provide access to only the "$FOAM_CASE/constant" folder via the "constantDir" variable which should be only accessible via the "Master Processor"?

Or do you think there should be some way of also accessing the "constant" folder within each processor?


Hope I didnt end up adding to the confusion :-)!

Have a great evening ahead!

Philippose

[gschaider]

Originally Posted by philippose

Hi Bernhard,

A Good Evening to you :-)!

Thanks for your response..... I had noticed that the issue was stemming from the fact that you were using the "Time.path()" approach to get the "caseDir".

I think we should probably try to define the implications of the different variables.....:

1. caseDir: I think this variable should always point to the "root" folder of the simulation, because as the name suggests, this is the directory of the entire Simulation case........ Hence, I think regardless of whether the simulation run is parallel or serial, "caseDir" should always be the root directory... equivalent to "$FOAM_CASE"....... I think it is ok (even required?) for this variable to be available for all processors of a parallel run or?

2. systemDir: As far as I have seen / experienced, there exists only one "system" directory, and this exists at "$FOAM_CASE/system", or? Are there any OpenFOAM solvers which need a separate "system" folder within each processor folder? If only one system folder is required, then as you said, I think the "systemDir" variable should be available only to the "Master Processor" in a parallel run, and should always be "$FOAM_CASE/system"

3. constantDir: This one is a little tough :-)! When an OpenFOAM case is decomposed for a parallel simulation, each processor folder gets its own "constant" folder, because it contains the corresponding parts of the mesh for each processor. On the other hand, settings for turbulence and transport medium are located only in the main "$FOAM_CASE/constant" folder...... Do you think it is enough to provide access to only the "$FOAM_CASE/constant" folder via the "constantDir" variable which should be only accessible via the "Master Processor"?

Or do you think there should be some way of also accessing the "constant" folder within each processor?


Hope I didnt end up adding to the confusion :-)!

Have a great evening ahead!

Philippose

No confusion. Your description is sensible and similar to what I had in mid. As I said in the last post: I have this horror vision: somebody writes a sciptlet that manipulates the fvSolution of the running case depending on ... whatever. He tests it in serial and it works fine. Then he starts a 17CPU-run and 17 processes try to manipulate fvSolution at the same time. If we're lucky(!) the file afterwards contains garbage and the run will fail. The worse scenario is that the info in the file will be inconsistent, but the run will go on (with an undetected error). So my intention at the time was to make code fail in parallel environments

Anyway: the problem with exposing systemDir only on the master-processor is that there is also information there that might be accessed on a read-only basis (endTime for instance). In that case the master would have to communicate the value to the others via something like http://mpi4py.scipy.org/. Also not ideal

I think I'll go for exposing the 3 directories according to your proposal on ALL processors. The code will only run in a parallel runs if there is a flag

isParallelized true;

set (a bit childish, but it pushes the responsibility to the user)

Bernhard

[philippose]

Hello Bernhard,

A Good Evening to you again :-)!

Sorry for the delay in my reply...... Have been quite busy the last few days!

I find your proposal perfectly sensible. I think its fair enough to expect the user to know what he/she is doing :-)! After all.... CFD is not only about colourful pictures :-)!

Are there any other variables which might be of use and which might make sense to be made visible to the python interface?

Hmmmm..... as of now I cannot think of any more..... I think these three folders coupled with the extensive dictionary parsing capabilities of PyFoam will allow you to do almost anything :-)!

Have a nice remaining evening ahead!

Philippose

[gschaider]

Originally Posted by philippose

Hello Bernhard,

A Good Evening to you again :-)!

Sorry for the delay in my reply...... Have been quite busy the last few days!

I find your proposal perfectly sensible. I think its fair enough to expect the user to know what he/she is doing :-)! After all.... CFD is not only about colourful pictures :-)!

Are there any other variables which might be of use and which might make sense to be made visible to the python interface?

Hmmmm..... as of now I cannot think of any more..... I think these three folders coupled with the extensive dictionary parsing capabilities of PyFoam will allow you to do almost anything :-)!

Have a nice remaining evening ahead!

Philippose

I added the variables (and some others) to the namespace and pushed the changes to the development version (mercurial on sourceforge). Works for 1.x and 2.x. Detailed description of the variables is in the README-file

Bernhard

[anon_a]

Dear Bernhard,

A couple of short questions:
- Does 4.2.3 of http://openfoamwiki.net/index.php/Co...ing_of_patches still work with swak4Foam?
- (If the valueExpression is appropriately modified) can this return values for several corresponding faces (conformal faces, no interpolation needed) instead of just one average value?

Thanks

[gschaider]

Originally Posted by anon_a

A couple of short questions:
- Does 4.2.3 of http://openfoamwiki.net/index.php/Co...ing_of_patches still work with swak4Foam?

Yep. The syntax is different. See the swak4Foam-Wiki-page

Originally Posted by anon_a

- (If the valueExpression is appropriately modified) can this return values for several corresponding faces (conformal faces, no interpolation needed) instead of just one average value?

No. One reason is that even for "conformal faces, no interpolation needed" there are special cases to be considered (are the patches just translated or rotated too ...) and I (or anyone I work for) didn't need it yet.

For certain applications (if you need the value of the same field on another patch) the groovyJumpBC might help you (that is based on the jump-BC. Only that the difference between the field on the patches is given by an expression

[anon_a]

Thank you for your answer. Actually, I should have been more specific.
I meant something for different regions, similar to a directMapped BC.
The faces are exactly at the same spot with the same orientation.

(I tried using directMapped but got this:
http://www.cfd-online.com/Forums/ope...-fluid-bc.html)

I took a look on the multiRegionHeaterFeedback tutorial but as far as I understand only one value, such as the average, can be exchanged. Did I get this right?

[anon_a]

By the way, I tried something like

type            groovyBC;
variables      "Tinterface2{Flow2_to_Flow1/Flow2}=T; Tinterface1=T; T_relax=0.5;";
valueExpression "(Tinterface1 + T_relax*(Tinterface2-Tinterface1))";
value           $internalField;

but off course it does not work.

[gschaider]

Originally Posted by anon_a

Thank you for your answer. Actually, I should have been more specific.
I meant something for different regions, similar to a directMapped BC.
The faces are exactly at the same spot with the same orientation.

(I tried using directMapped but got this:
http://www.cfd-online.com/Forums/ope...-fluid-bc.html)

I took a look on the multiRegionHeaterFeedback tutorial but as far as I understand only one value, such as the average, can be exchanged. Did I get this right?

Right

Originally Posted by anon_a

By the way, I tried something like

type            groovyBC;
variables      "Tinterface2{Flow2_to_Flow1/Flow2}=T; Tinterface1=T; T_relax=0.5;";
valueExpression "(Tinterface1 + T_relax*(Tinterface2-Tinterface1))";
value           $internalField;

but off course it does not work.

It works. But not the way you'd like it too

Building a specialized groovyBC on directMapped would be an option. Or have something like "mapped variables" using the mechanism that is already in OF. A bug report would remind me to have a look at it once I have time

[anon_a]

Originally Posted by gschaider

It works. But not the way you'd like it too

What I meant is that it produces this error

word::stripInvalid() called for word Tinterface1
    For debug level (= 2) > 1 this is considered fatal
Aborted

so it does not work at all because I am writing something in a wrong way.
Not that it matters since, as you said, it would not produce what I want anyway :-)

Originally Posted by gschaider

Building a specialized groovyBC on directMapped would be an option. Or have something like "mapped variables" using the mechanism that is already in OF. A bug report would remind me to have a look at it once I have time

I will make a "bug report"(/feature request) at some point.
There are actually several posts of people looking for something like that, such as:

http://www.cfd-online.com/Forums/ope...interface.html
http://www.cfd-online.com/Forums/ope...implefoam.html
http://www.cfd-online.com/Forums/ope...face-type.html
http://www.cfd-online.com/Forums/ope...s-regions.html

plus my self :-)

[gschaider]

Originally Posted by anon_a

What I meant is that it produces this error

word::stripInvalid() called for word Tinterface1
    For debug level (= 2) > 1 this is considered fatal
Aborted

so it does not work at all because I am writing something in a wrong way.
Not that it matters since, as you said, it would not produce what I want anyway :-)

I THINK I know what the problem is: the space before the variable name. Haven't checked with the source but probably during parsing it takes everything after the semicolon as the variable name and space is NOT valid in a word.

Anyway: if you want to make your variable lists more readable I recommend the list notation (then you can have one variable per line)

I'll have a look and fix that anyway (if I don't forget)

Originally Posted by anon_a

I will make a "bug report"(/feature request) at some point.
There are actually several posts of people looking for something like that, such as:

http://www.cfd-online.com/Forums/ope...interface.html
http://www.cfd-online.com/Forums/ope...implefoam.html
http://www.cfd-online.com/Forums/ope...face-type.html
http://www.cfd-online.com/Forums/ope...s-regions.html

plus my self :-)

Yeah. Everyone but me seems to need it

[Alish1984]

Hi

can anyone help me get GroovyBC sources? it seems the link corrupted or wiki is down!!!

[wyldckat]

Greetings Ali,

Originally Posted by Alish1984

can anyone help me get GroovyBC sources? it seems the link corrupted or wiki is down!!!

I'll answer you with another quote:

Originally Posted by gschaider

Due to an administrative hickup (my fault) the Wiki is currently not available under its real address openfoamwiki.net. As a workaround it can be reached under this address: http://openfoamwiki.ice-sf.at/index.php/Main_Page

Don't bookmark this address it is only as a temporary workaround. I'd also like to stress that the content is in no way associated with the owner of that domain. It was just the fastest way to make this content available to the public again

Operations on http://openfoamwiki.net will continue as soon as possible

Best regards,
Bruno

[anon_a]

Hello again

Assume I have pressure fields (for example) for the same mesh, occurring from different simulations: p1, p2, p3... Can I somehow average them with funkySetFields?
I know I can make an expression (p1+p2+p3)/3 but what about a predefined but arbitrary number of fields?

[anon_a]

Nevermind, I think I solved my problem with a combination of shell scripting, sed and funky.

[mkubemcd]

I could really use the help of someone more familiar with swak than I. I'm running OpenFOAM 2.1.0 on a compute server where I don't have admin privileges. My goal is to integrate a flux across an outlet surface. I've worked with simpleFunctionObjects successfully in the past, but I'm having trouble getting any output from swak in this case.

Here's my controlDict:

application     LTSInterFoam;
startFrom       startTime;
startTime       0;
stopAt          endTime;
endTime         10;
deltaT          1;
writeControl    timeStep;
writeInterval   10;
purgeWrite      0;
writeFormat     ascii;
writePrecision  6;
writeCompression compressed;
timeFormat      general;
timePrecision   6;
runTimeModifiable yes;

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

functions
(
    monitorAirOutlet
    {
        type patchExpression;
        accumulations (sum);
        patches (airout);
        expression "area()";
        verbose true;
    }
);

I pared back to the simplest test case I could think of. And here's an example of the output:

/*---------------------------------------------------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  2.1.0                                 |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
Build  : 2.1.0-bd7367f93311
Exec   : LTSInterFoam
Date   : Sep 17 2012
Time   : 09:37:02
Host   : "manufacturingHUB"
PID    : 4242
Case   : /home/manufacturinghub/mkubemcd/OpenFOAM/mkubemcd-1.7.1/run/210test
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster
allowSystemOperations : Disallowing user-supplied system call operations

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create mesh for time = 0

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
Selecting turbulence model type RASModel
Selecting RAS turbulence model kEpsilon

Reading g
Calculating field g.h


PIMPLE: Operating solver in PISO mode

time step continuity errors : sum local = 0.241305, global = -0.215316, cumulative = -0.215316
GAMGPCG:  Solving for pcorr, Initial residual = 1, Final residual = 2.5898e-06, No Iterations 11
time step continuity errors : sum local = 6.24933e-07, global = -1.66571e-08, cumulative = -0.215316
Courant Number mean: 67.7169 max: 1240.45

Starting time loop

Time = 1

Flow time scale min/max = 8.06156e-06, 1
Smoothed flow time scale min/max = 8.06156e-06, 0.113605
MULES: Solving for alpha1
MULES: Solving for alpha1
Liquid phase volume fraction = 0.191501  Min(alpha1) = 0.01  Max(alpha1) = 1
MULES: Solving for alpha1
MULES: Solving for alpha1
Liquid phase volume fraction = 0.191503  Min(alpha1) = 0.01  Max(alpha1) = 1
GAMG:  Solving for p_rgh, Initial residual = 1, Final residual = 9.57899e-07, No Iterations 67
time step continuity errors : sum local = 5.16908e-07, global = -3.09995e-08, cumulative = -0.215316
ExecutionTime = 74.3 s  ClockTime = 74 s

Time = 2

Flow time scale min/max = 1.71845e-05, 1
Smoothed flow time scale min/max = 1.71845e-05, 0.0339544
MULES: Solving for alpha1
MULES: Solving for alpha1
Liquid phase volume fraction = 0.1915  Min(alpha1) = 0.00999996  Max(alpha1) = 1
MULES: Solving for alpha1
MULES: Solving for alpha1
Liquid phase volume fraction = 0.191498  Min(alpha1) = 0.00999995  Max(alpha1) = 1
GAMG:  Solving for p_rgh, Initial residual = 0.0172504, Final residual = 8.45131e-07, No Iterations 41
time step continuity errors : sum local = 7.16379e-05, global = 4.744e-06, cumulative = -0.215311
ExecutionTime = 102.79 s  ClockTime = 102 s

As you can see, swak isn't throwing any errors, but it also isn't printing any output. I got the mixingDam example case to run in 2.1.0 and swak wrote the new gravity fields as expected, so I think everything's installed properly, but I don't know what to check without error messages. Is there something diagnostic I can do without admin privileges? Am I missing some really simple step in my controlDict?

Thanks for the help.