[gschaider]

Originally Posted by rob3rt 0ng

Hi Bernhard,

I've set the PyFOam in the right PYTHONPATH

Now, when I tried pyFoamDisplayBlockMesh.py constant/polyMesh/blockMeshDict

It gives me

Error in /home/roberto/OpenFOAM/PyFoam-0.5.6/bin/pyFoamDisplayBlockMesh.py : PyFoam FATAL ERROR on line 26 of file /home/roberto/OpenFOAM/PyFoam-0.5.6/PyFoam/Applications/DisplayBlockMesh.py: Error while importing modules: No module named libvtkCommonPython

I couldn't find the libvtkCommonPython anywhere in my computer...

The pyFaomVersion.py gives me

PYTHONPATH: //home/roberto/OpenFOAM/PyFoam-0.5.6/lib/python-2.7/site-packages:
OpenFOAM (1, 7, 'x') of the installed versions ['2.0.x', '1.7.x']
pyFoam-Version: 0.5.6
Configuration search path: [('file', '/etc/pyFoam/pyfoamrc'), ('directory', '/etc/pyFoam/pyfoamrc.d'), ('file', '/home/roberto/.pyFoam/pyfoamrc'), ('directory', '/home/roberto/.pyFoam/pyfoamrc.d')]
Configuration files (used): []

Installed libraries:
Gnuplot              :  No     Not a problem. Version from ThirdParty is used
ply                  :  No     Not a problem. Version from ThirdParty is used
Numeric              :  No     Not a problem if numpy is present
numpy                :  Yes
matplotlib           :  Yes
psyco                :  No     Not a problem. Acceleration not possible
hotshot              :  Yes
profile              :  No     Not a problem. Can't profile using this library
cProfile             :  Yes
PyQt4                :  No     Only some experimental GUI-stuff relies on this
PyQt4.Qwt5           :  No     Only an alternate plotting back-end
vtk                  :  No     Not a problem. Only used for some utilities
Tkinter              :  Yes
mercurial            :  No     Not a problem. Used for experimental case handling

Thanks for your help.

Have a nice day

Regards,
Robert

libvtkCommonPython is in the vtk-library that is missing on your computer (look for a package with vtk and python in the name in your package manager). Also if you want the new interface of DisplayBlockMesh you've got to install PyQT4

Bernhard

[rob3rt 0ng]

Thanks Bernhard. I should've thought about it before posting

[alfa_8C]

Hello Bernhard,

I need to change the boundary type for a specific boundary name in a p file from "calculated" to "fixedValue". The p file is a result file and contains nonuniform field at the boundary. As the file will to be used as initial condition for an other calculation, the BC values must remain as they are.

I tried to realize that by using

pyFoamChangeBoundaryType.py

but I am getting errors. Is this command not suitable for my application?

For better understanding:

Field p before:

99999.8
99999.7
)
;
}
outlet
{
type calculated;
value nonuniform List<scalar>
1100
(
100000
100000


Field p after:

99999.8
99999.7
)
;
}
outlet
{
type fixedValue;
value nonuniform List<scalar>
1100
(
100000
100000

Thank you in advance,
Toni

[gschaider]

Originally Posted by alfa_8C

Hello Bernhard,

I need to change the boundary type for a specific boundary name in a p file from "calculated" to "fixedValue". The p file is a result file and contains nonuniform field at the boundary. As the file will to be used as initial condition for an other calculation, the BC values must remain as they are.

I tried to realize that by using

pyFoamChangeBoundaryType.py

but I am getting errors. Is this command not suitable for my application?

Should work (but not too fast for big cases). Of course the error message would be of tremendous value to find out what the problem is.

[alfa_8C]

required command order:

pyFoamChangeBoundaryType <caseDirectory> <boundaryName> <new type>

my 1st command beeing in the caseDirectory:

pyFoamChangeBoundary ./ outlet fixedValue

result: boundaryType in constant/polyMesh/boundary has been changed from "patch" to "fixedValue" --> not really what I want!!

my 2nd command beeing in the caseDirectory:

pyFoamChangeBoundary ./0/p outlet fixedValue

result:
raceback (most recent call last):
File "/shared/openfoam/PyFoam-0.5.5/bin/pyFoamChangeBoundaryType.py", line 5, in <module>
ChangeBoundaryType()
File "/shared/openfoam/PyFoam-0.5.5/lib64/python2.6/site-packages/PyFoam/Applications/ChangeBoundaryType.py", line 25, in __init__
interspersed=True)
File "/shared/openfoam/PyFoam-0.5.5/lib64/python2.6/site-packages/PyFoam/Applications/PyFoamApplication.py", line 155, in __init__
result=self.run()
File "/shared/openfoam/PyFoam-0.5.5/lib64/python2.6/site-packages/PyFoam/Applications/ChangeBoundaryType.py", line 44, in run
boundary=ParsedParameterFile(path.join(".",fName," constant","polyMesh","boundary"),debug=False,bound aryDict=True)
File "/shared/openfoam/PyFoam-0.5.5/lib64/python2.6/site-packages/PyFoam/RunDictionary/ParsedParameterFile.py", line 66, in __init__
self.readFile()
File "/shared/openfoam/PyFoam-0.5.5/lib64/python2.6/site-packages/PyFoam/RunDictionary/FileBasis.py", line 80, in readFile
self.openFile()
File "/shared/openfoam/PyFoam-0.5.5/lib64/python2.6/site-packages/PyFoam/RunDictionary/FileBasis.py", line 69, in openFile
self.fh=gzip.open(self.name+".gz",mode)
File "/usr/lib64/python2.6/gzip.py", line 33, in open
return GzipFile(filename, mode, compresslevel)
File "/usr/lib64/python2.6/gzip.py", line 79, in __init__
fileobj = self.myfileobj = __builtin__.open(filename, mode or 'rb')

[gschaider]

Originally Posted by alfa_8C

required command order:

pyFoamChangeBoundaryType <caseDirectory> <boundaryName> <new type>

my 1st command beeing in the caseDirectory:

pyFoamChangeBoundary ./ outlet fixedValue

result: boundaryType in constant/polyMesh/boundary has been changed from "patch" to "fixedValue" --> not really what I want!!

my 2nd command beeing in the caseDirectory:

pyFoamChangeBoundary ./0/p outlet fixedValue

That is not what pyFoamChangeBoundary is intended for. Have a look at the online-help of it:

% pyFoamChangeBoundaryType.py --help
Usage
=====
  pyFoamChangeBoundaryType.py <caseDirectory> <boundaryName> <new type>

 Changes the type of a boundary in the boundary-file

Options
=======
....

It is only intended to change the constant/polyMesh/boundary-file

Better suited for your purposes is pyFoamCreateBoundaryPatches:

%pyFoamCreateBoundaryPatches.py -h
Usage
=====
  pyFoamCreateBoundaryPatches.py [options] <fieldfile>

 Takes a field-file. Looks up the polyMesh/boundary-file of the case and adds
the corresponding patches to the boundary field setting it to zeroGradient for
all patches and walls

Options
=======
....

Without options it doesn't do what you want to do, but using the filter, the overwrite and the default-option it will do the trick

[alfa_8C]

I tried that already, but if I use option -overwrite, all the values of the BC are deleted, and this is exactly what I don't want. If I don't use option -overwrite, nothing happens. Again, that values are a solution of a calculation, which schould be used as BC in an other case. This is why I need simply to change the type from calculated to fixedValue. Is that somehow possible?

[gschaider]

Originally Posted by alfa_8C

I tried that already, but if I use option -overwrite, all the values of the BC are deleted, and this is exactly what I don't want. If I don't use option -overwrite, nothing happens. Again, that values are a solution of a calculation, which schould be used as BC in an other case. This is why I need simply to change the type from calculated to fixedValue. Is that somehow possible?

Ah. OK. pyFoamCreateBoundaryPatches.py was "designed" to set up initial cases. I just wanted to write you that you'll have to write your own script based on this snipplet

from PyFoam.RunDictionary.ParsedParameterFile import ParsedParameterFile
p=ParsedParameterFile("0/p")
p["boundaryField"]["outlet"]["type"]="fixedValue"
p.write()

when it occured to me that there IS already a utility that does this

pyFoamWriteDictionary.py -h
Usage
=====
  pyFoamWriteDictionary.py [options] <dictfile> <key> <val>

 Write a value to a Foam-Dictionary. The description of the value is word. If
the value is non-atomic (a list or a dictionary) it has to be in in Python-
notation. Parts of the expression can be accessed by using the Python-notation
for accessing sub-expressions.  Example of usage:
> pyFoamWriteDictionary.py --test pitzDaily/0/U "boundaryField['inlet']['type']" zeroGradient <

The syntax is a bit weird because here two worlds collide

[alfa_8C]

Bernhard - Thank you very much - it works properly

...this is once again exceptional and cool

[gschaider]

Originally Posted by alfa_8C

Bernhard - Thank you very much - it works properly

...this is once again exceptional and cool

Great. Could I ask you to give the PyFoam-Wiki-Page a critical look "I would have found the utility without help if the description here would have been clearer or if there would have been a usage-example there" and modify it accordingly. Thanks

[gschaider]

Hi all!

PyFoam has quite a long history and is supporting quite old python-versions. All this support makes it harder to incorporate new lanuage features of Python. Also there are utilities and classes in PyFoam that are no longer needed. To find out which parts of pyFoam I can let go (and which one I should keep) I ask everyone who uses PyFoam to please take the 6.57 minutes that it takes to fill out this survey:
https://sourceforge.net/apps/limesur...=86766&lang=en

Bernhard

[Jeffzda]

Hi there,

I wasn't sure if this was the right place to post for a new problem with PyFoam or if I should start a totally new thread but I wanted to maximise my chances of being heard.

I'm running OpenFOAM 2.1.0 with the latest Pyfoam 0.5.6. I have made a change to the blockMeshDict file using ParsedBlockMeshDict. I have written a python script, part of which changes the boundaries to 'wall' from 'patch'. I have no problem loading the file and changing the data in the ParsedBlockMeshDict class instance. I even have no trouble saving the file again. The problem arises with a very particular part of the saved blockMeshDict file and when I try to run blockMesh with a blockMeshDict file that has been through this process I get the following error:

--> FOAM FATAL ERROR:
hanging pointer, cannot dereference

From function PtrList:perator[] const
in file /home/opencfd/OpenFOAM/OpenFOAM-2.1.0/src/OpenFOAM/lnInclude/PtrListI.H at line 134.

FOAM aborting

After checking the blockMeshDict file, I found that its format is a little less human-readable, though that's not the problem. The problem was fixed when I removed the following number ("55" - in bold) that wasn't there in the original file:

...
    (0 3.5 0.1)
    (-0.32 3.5 0.1)
    (-3.5 3.5 0.1)
  );     

blocks
  55
  (
    hex

    (
      0
      1
      6
 
... etc

There are only 11 blocks in this dictionary, but the number 55 has been added. Anyway, because this was wrong I figured it was causing the problem, and sure enough it was. I wonder, it seems to have counted 5 for every line that I had in my 'blocks' dictionary, which originally looked like this:

blocks          
(
    hex (0 1 6 7 22 23 28 29) (318 336 1) simpleGrading (1 1 1)
    hex (1 2 5 6 23 24 27 28) (32 336 1) simpleGrading (1 1 1)      
    hex (2 3 4 5 24 25 26 27) (350 336 1) simpleGrading (1 1 1)   
    hex (5 4 15 14 27 26 37 36) (350 11 1) simpleGrading (1 1 1)     
    hex (7 6 9 8 29 28 31 30) (318 28 1) simpleGrading (1 1 1)     
    hex (13 14 11 12 35 36 33 34) (16 7 1) simpleGrading (1 1 1)     
    hex (14 15 16 11 36 37 38 33) (350 7 1) simpleGrading (1 1 1)     
    hex (11 16 17 10 33 38 39 32) (350 11 1) simpleGrading (1 1 1)     
    hex (10 17 18 19 32 39 40 41) (350 336 1) simpleGrading (1 1 1)     
    hex (9 10 19 20 31 32 41 42) (32 336 1) simpleGrading (1 1 1)     
    hex (8 9 20 21 30 31 42 43) (318 336 1) simpleGrading (1 1 1)     
);

It's not hard to see why this is happening, seeing as there are five entries on each line, separated by a space. The blockMesh application, however, treats each full line as an entry, so when it's told that there are 55 and it only encounters 11, it doesn't like it. The way that the entries are being counted in the parsed version of the files seems to be incompatible with the blockMesh application. I wonder if maybe removing this number altogether would be the easiest thing to do, seeing as the presence of this number not necessary for blockMesh to work its magic.

Thanks for your time and I'm eager to hear is there's a workaround for this that doesn't involve me having to hack the blockMeshDict with a text editor to delete that number!

Jeff

[gschaider]

Originally Posted by Jeffzda

Hi there,

I wasn't sure if this was the right place to post for a new problem with PyFoam or if I should start a totally new thread but I wanted to maximise my chances of being heard.

I'm running OpenFOAM 2.1.0 with the latest Pyfoam 0.5.6. I have made a change to the blockMeshDict file using ParsedBlockMeshDict. I have written a python script, part of which changes the boundaries to 'wall' from 'patch'. I have no problem loading the file and changing the data in the ParsedBlockMeshDict class instance. I even have no trouble saving the file again. The problem arises with a very particular part of the saved blockMeshDict file and when I try to run blockMesh with a blockMeshDict file that has been through this process I get the following error:

--> FOAM FATAL ERROR:
hanging pointer, cannot dereference

From function PtrList:perator[] const
in file /home/opencfd/OpenFOAM/OpenFOAM-2.1.0/src/OpenFOAM/lnInclude/PtrListI.H at line 134.

FOAM aborting

After checking the blockMeshDict file, I found that its format is a little less human-readable, though that's not the problem. The problem was fixed when I removed the following number ("55" - in bold) that wasn't there in the original file:

...
    (0 3.5 0.1)
    (-0.32 3.5 0.1)
    (-3.5 3.5 0.1)
  );     

blocks
  55
  (
    hex

    (
      0
      1
      6
 
... etc

There are only 11 blocks in this dictionary, but the number 55 has been added. Anyway, because this was wrong I figured it was causing the problem, and sure enough it was. I wonder, it seems to have counted 5 for every line that I had in my 'blocks' dictionary, which originally looked like this:

blocks          
(
    hex (0 1 6 7 22 23 28 29) (318 336 1) simpleGrading (1 1 1)
    hex (1 2 5 6 23 24 27 28) (32 336 1) simpleGrading (1 1 1)      
    hex (2 3 4 5 24 25 26 27) (350 336 1) simpleGrading (1 1 1)   
    hex (5 4 15 14 27 26 37 36) (350 11 1) simpleGrading (1 1 1)     
    hex (7 6 9 8 29 28 31 30) (318 28 1) simpleGrading (1 1 1)     
    hex (13 14 11 12 35 36 33 34) (16 7 1) simpleGrading (1 1 1)     
    hex (14 15 16 11 36 37 38 33) (350 7 1) simpleGrading (1 1 1)     
    hex (11 16 17 10 33 38 39 32) (350 11 1) simpleGrading (1 1 1)     
    hex (10 17 18 19 32 39 40 41) (350 336 1) simpleGrading (1 1 1)     
    hex (9 10 19 20 31 32 41 42) (32 336 1) simpleGrading (1 1 1)     
    hex (8 9 20 21 30 31 42 43) (318 336 1) simpleGrading (1 1 1)     
);

It's not hard to see why this is happening, seeing as there are five entries on each line, separated by a space. The blockMesh application, however, treats each full line as an entry, so when it's told that there are 55 and it only encounters 11, it doesn't like it. The way that the entries are being counted in the parsed version of the files seems to be incompatible with the blockMesh application. I wonder if maybe removing this number altogether would be the easiest thing to do, seeing as the presence of this number not necessary for blockMesh to work its magic.

Thanks for your time and I'm eager to hear is there's a workaround for this that doesn't involve me having to hack the blockMeshDict with a text editor to delete that number!

Jeff

The problem seems to be that internally blocks is a list of 55 elements (each block 5 - see if you can spot them) and PyFoam adds a number to lists above a certain length (problem is that in this case it is not the right length)

Please post a bug-report at openfoam-extend-Mantis (URL should be on the PyFoam-Wiki-page) and I'll try to do a general fix

Until then go to PyFoam/Basics/FoamFileGenerator.py and look for the lines

            if theLen>20:
                s+=(" "*indent)+str(theLen)+"\n"

Either delete them or change 20 to a higher value.

Even if this works PLEASE do the bug-report. Unless you want to edit this out with every new release.

This is one of the instances where the syntax of the OF-files can only be correctly parsed if knowing the C++-code

[Toorop]

Hi,

I couldn't get pyFoamPlotWatcher work with regular expressions if there is multiple data in a single line I would like to plot. The default ones are okay.
controlDict

functions
{
    volumeIntegrateU
    {
        type volumeIntegrate;
        functionObjectLibs ( "libsimpleFunctionObjects.so" );
        fields ( U );
        factor 1.0;
        verbose true;
    }
}

customRegexp

IntegralU
{
  expr "Integral of U = ((%f) (%f) (%f))  [0 4 -1 0 0 0 0]";
  name IntegralU;
  theTitle "Integral of U";
  titles
   (
     Ux
     Uy
     Uz
   );
  type regular;
}

pyFoamPlotWatcher.py log.openFoamSolver --with-all

The "Reading regular expressions from ..." message appears but the plot is nowhere.

sample from the log file

Time = 1000

smoothSolver:  Solving for Ux, Initial residual = 0.000301615, Final residual = 1.25104e-05, No Iterations 3
smoothSolver:  Solving for Uy, Initial residual = 0.000290449, Final residual = 1.14419e-05, No Iterations 3
smoothSolver:  Solving for Uz, Initial residual = 0.000287985, Final residual = 1.17759e-05, No Iterations 3
GAMG:  Solving for p, Initial residual = 0.00366477, Final residual = 8.22291e-06, No Iterations 5
time step continuity errors : sum local = 3.18785e-06, global = -4.97432e-18, cumulative = -5.3224e-15
smoothSolver:  Solving for epsilon, Initial residual = 0.000120286, Final residual = 3.36425e-06, No Iterations 3
smoothSolver:  Solving for k, Initial residual = 0.000212247, Final residual = 7.76297e-06, No Iterations 3
ExecutionTime = 8610.9 s  ClockTime = 8755 s

 Integral of U = (0.00638885 -0.000674966 0.00267372)  [0 4 -1 0 0 0 0]
Time = 1001

smoothSolver:  Solving for Ux, Initial residual = 0.000301345, Final residual = 1.25003e-05, No Iterations 3
smoothSolver:  Solving for Uy, Initial residual = 0.000290066, Final residual = 1.14271e-05, No Iterations 3
smoothSolver:  Solving for Uz, Initial residual = 0.000287703, Final residual = 1.17645e-05, No Iterations 3
GAMG:  Solving for p, Initial residual = 0.0036754, Final residual = 8.02017e-06, No Iterations 5
time step continuity errors : sum local = 3.10923e-06, global = -3.73064e-18, cumulative = -5.32614e-15
smoothSolver:  Solving for epsilon, Initial residual = 0.000120209, Final residual = 3.36217e-06, No Iterations 3
smoothSolver:  Solving for k, Initial residual = 0.000212124, Final residual = 7.75821e-06, No Iterations 3
ExecutionTime = 8620.83 s  ClockTime = 8765 s

 Integral of U = (0.00639356 -0.000714771 0.00266406)  [0 4 -1 0 0 0 0]

Thanks!

[gschaider]

Originally Posted by Toorop

Hi,

I couldn't get pyFoamPlotWatcher work with regular expressions if there is multiple data in a single line I would like to plot. The default ones are okay.

customRegexp

IntegralU
{
  expr "Integral of U = ((%f) (%f) (%f))  [0 4 -1 0 0 0 0]";
  name IntegralU;
  theTitle "Integral of U";
  titles
   (
     Ux
     Uy
     Uz
   );
  type regular;
}

pyFoamPlotWatcher.py log.openFoamSolver --with-all

The "Reading regular expressions from ..." message appears but the plot is nowhere.

sample from the log file

 Integral of U = (0.00638885 -0.000674966 0.00267372)  [0 4 -1 0 0 0 0]

Thanks!

The problem is that '(' and ')' are special characters for regular expression (BTW: so is '[' and ']'). To match them you'll have to escape them with a '\'. Try:

"Integral of U = \((%f) (%f) (%f)\)  \[0 4 -1 0 0 0 0\]"

A quick google for "regular expression cheatsheet revealed http://opencompany.org/download/regex-cheatsheet.pdf or http://leib.be/sascha/files/RegexCheatSheet.pdf (that is better I think, but german) or http://www.cheatography.com/davechil...r-expressions/ (more colorful)

Also there is a number of online tools (like http://regexpal.com/) that help with the first steps with regular expressions (note that %f% is a PyFoam-specific shorthand for the more complex regexp that matches a floating-point number)

May I ask the following: should some of these links be helpful for you could you add the useful ones to the PyFoam-Wiki-page? ("Information on regular expressions" or so - in the customRegep-section). It's hard for me to tell what is the minimum amount of information required for a novice (and we don't want to go overboard (there are books about regular expressions) because the typical PyFoam user will only want to know the bare minimum)

[Toorop]

I'm always amazed by the detailed answers you provide, thanks!

Although I have some experience in sed with regex, I would say it's very limited. I usually skim through 10+ tutorials on the issue and try to hammer my syntax to give me the desired result. Sometimes I don't even now why a particular solution is giving me the correct result ...

Unfortunately, it didn't come to mind that my problem with customRegexp is related to regular expression common metacharacters.

I think an example is more useful than some links - an is even more true when the syntax is like from another planet. Anyway, that's my experience with Linux text manipulation tools. So if you approve, I can add something like this:

If a line contains a special character, one must indicate that for the parser just like in case of a regular expression.

Solver output with multiple parentheses and square brackets:
Integral of U = (-0.05 0.02 0.05) [0 4 -1 0 0 0 0]

The matching expression:
expr "Integral of U = \((%f) (%f) (%f)\) \[0 4 -1 0 0 0 0\]";

If in trouble, some nice summaries about regular expressions can be found here or here.

I think the only thing left is to correct the above expression because it isn't working! Don't know what's the problem.
The last page cartoon on the German cheat-sheet is priceless!

[gschaider]

Originally Posted by Toorop

I'm always amazed by the detailed answers you provide, thanks!

Although I have some experience in sed with regex, I would say it's very limited. I usually skim through 10+ tutorials on the issue and try to hammer my syntax to give me the desired result. Sometimes I don't even now why a particular solution is giving me the correct result ...

Unfortunately, it didn't come to mind that my problem with customRegexp is related to regular expression common metacharacters.

I think an example is more useful than some links - an is even more true when the syntax is like from another planet. Anyway, that's my experience with Linux text manipulation tools. So if you approve, I can add something like this:

Yeah. Great. Probably such stories "from the trenches" will motivate people more

Originally Posted by Toorop

I think the only thing left is to correct the above expression because it isn't working! Don't know what's the problem.
The last page cartoon on the German cheat-sheet is priceless!

One of these days I'll replace regexps with http://en.wikipedia.org/wiki/Brainfuck and people will stop complaining

About the expression: The %f should have read %f% (people are under the misconception that just because I wrote this stuff -PyFoam, not regexp- I would know how to use it correctly)

[Toorop]

Thanks for your time, I should have spotted that %f% typo!

[gschaider]

Originally Posted by Toorop

Thanks for your time, I should have spotted that %f% typo!

Well. If I insert typos like that it is ALWAYS on purpose to see how observant people are. But don't tell anyone

[Amir]

Dear Bernhard,

I have a trouble with both pyFoamPlotWatcher and Runner; Although I set the proper frequency of data plotting with "frequency option" but it gradually extends during iteration. What's the solution?

Bests,