[gschaider]

@fabian: It works like this: Source (first argument) gets copied to destination(second argument). Unfortunately if the destination folder exists, it gets overwritten (so in your case the _poly-folder was overwritten with the initial condition of the _epsilon-folder? The _rng-folder was ignored?) But this should happen without the traceback you posted (I found no way to reproduce this)
Does pyFoamCloneCase.py work for regular cases? Try something like
pyFoamCloneCase.py $FOAM_TUTORIAL/interFoam/damBreak /tmp/testDam
(Anyway: I'll change the default behaviour of pyFoamCloneCase.py to not overwriting existing data)

@jason:
Q1: No. The graphs are not saved. One of the reasons is that for performance reasons the left (older) part of the graph becomes "cruder" (data is resampled).
Q2: I'm not sure if the --write-files option was already implemented in the version you have (check with -h)
Q3: I'm afraid: yes.

[braennstroem]

Hi Bernhard,

thanks for your help; it was probably just my mistake...

I attached two small python scripts for creating some matplotlib plots of your log data and a small script which creates looks for boundaries and creates the corresponding 'initial' data structure with having to use Foamx. Both scripts are nothing special and no great python programing style, but they work and in combination with emacs and dired even better ;-) Maybe it is possible to include them into pyFoam!?

plot_opf.py
opf_grep.py



I integrated these scripts among other pyFoam scripts into my emacs setup with these calls:

(defun opf_res()
"OpenFOAM Residuals and Monitors"
(interactive)
(call-process "python2.5" nil 0 nil "/home/gcae504/org/Skripte/plot_opf.py" (dired-current-directory) )
(message (dired-get-filename))
(message (dired-current-directory) ))

(defun opf_boundaries_change()
"Set Default Boundary Condition"
(interactive)
(call-process "python2.5" nil 0 nil "/home/gcae504/org/Skripte/opf_grep.py" (dired-current-directory) )
(message (dired-get-filename)))

The plotting needs the case directory and the boundary-set-up needs the directory of the variables. The boundary setup works for simple cases and on boundaries declared by starting letters like 'w' for walls, 'i' for velocity inlets and 'o' for pressure outlets... so it's nothing special, but maybe someone would like to use it as a start...

Fabian

[gschaider]

Hi Fabian!

I just uploaded a new release (0.4.2) to the Wiki, but I'll have a look at your stuff for the next version. For your script for setting for setting default values I noticed that the pyFoamCreateBoundaryPAtches.py (which does something similar, but not the same) was not documented on the Wiki.

Some problems that have been adressed in this thread have been incorporated in the new release
* the way mpirun is called can be configured
* pyFoamCloneCase is hopefully more careful when juggling with data (your lost case)
* Plotting now uses either Numeric or numpy (whatever is available)
* the empty plots-problem I still can't put my finger on (but the plotWatcher be a bit more responsive when starting up - it sometimes needed one more timestep to start plotting)

Various utilities have been improved (not all changes are documented on the Wiki-page, but the --help-option might reveal some new options for some) and some new utilities have been added.

Have a look at the Wiki-page http://openfoamwiki.net/index.php/Co...PyFoam#History

Bernhard

[braennstroem]

Hi Bernhard,
nice work! I saw your pyFoamCreateBoundaryPatches, but it probably did not work due to my syntax of the boundaries. I usual use something like 'w-part1' and some of your tools have problems with the '-' sign...
Probably your approach is much better and powerful then mine anyways... see you and talk to you in London!?

Fabian

[gschaider]

Hi Fabian!

Looked at the grammar of the parser: you're right. It doesn't allow minus in names although OF accepts it. I will fix this (I just don't happen to use minus in patch-names)

See you in Windsor

Bernhard

[mighelone]

Dear all!

I've a problem with the gnuplot module of pyFoam.
In fact if I try to launch pyFoamPlotRunner.py, I receive the following error:

Traceback (most recent call last):
File "/usr/bin/pyFoamPlotRunner.py", line 3, in <module>
from PyFoam.Applications.PlotRunner import PlotRunner
File "usr/lib/python2.5/site-packages/PyFoam/Applications/PlotRunner.py", line 10, in <module>
File "usr/lib/python2.5/site-packages/PyFoam/Execution/GnuplotRunner.py", line 11, in <module>
File "usr/lib/python2.5/site-packages/PyFoam/Basics/GnuplotTimelines.py", line 4, in <module>
ImportError: No module named Gnuplot

The gnuplot python module is correctly installed, in fact if I run pyFoamPlotResiduals.py with a previously simulation, done with pyFoam, it works correctly.

Michele

[gschaider]

How very embarrassing. You're using the recent 0.4.2-version, right? From that version the required Gnuplot-Package was missing. I uploaded an update (0.4.2.1) to the Wiki.

Sorry for any inconvenience caused.

BTW: Fabian. The fix that allows minus in patch-names is also included.

[mighelone]

Thanks Bernhard!

I'll update soon to version 0.4.2.1

Michele

[bychkov]

Hi Bernhard,
I think that I have the same problem as Markus Rehm. PyFoam work perfectly except plotting. Here is my output for standard cavity tutorial (I have the same output for all cases and solvers).

-----------------------------
pyFoamPlotRunner.py icoFoam . cavity
...
Time = 0.495

Courant Number mean: 0.116925 max: 0.852134
DILUPBiCG: Solving for Ux, Initial residual = 1.99665e-07, Final residual = 1.99665e-07, No Iterations 0
DILUPBiCG: Solving for Uy, Initial residual = 4.36311e-07, Final residual = 4.36311e-07, No Iterations 0
DICPCG: Solving for p, Initial residual = 1.0746e-06, Final residual = 3.53797e-07, No Iterations 1
time step continuity errors : sum local = 5.37651e-09, global = -2.9125e-19, cumulative = 8.07944e-18
DICPCG: Solving for p, Initial residual = 6.81574e-07, Final residual = 6.81574e-07, No Iterations 0
time step continuity errors : sum local = 8.06059e-09, global = 9.28097e-19, cumulative = 9.00754e-18
ExecutionTime = 0.5 s ClockTime = 0 s

Time = 0.5

Courant Number mean: 0.116925 max: 0.852134
DILUPBiCG: Solving for Ux, Initial residual = 1.89493e-07, Final residual = 1.89493e-07, No Iterations 0
DILUPBiCG: Solving for Uy, Initial residual = 4.14522e-07, Final residual = 4.14522e-07, No Iterations 0
DICPCG: Solving for p, Initial residual = 1.06665e-06, Final residual = 3.39604e-07, No Iterations 1
time step continuity errors : sum local = 5.25344e-09, global = -9.50761e-19, cumulative = 8.05678e-18
DICPCG: Solving for p, Initial residual = 5.36118e-07, Final residual = 5.36118e-07, No Iterations 0
time step continuity errors : sum local = 6.86432e-09, global = 4.62063e-19, cumulative = 8.51884e-18
ExecutionTime = 0.66 s ClockTime = 1 s

End

Warning: empty x range [0.005:0.005], adjusting to [0.00495:0.00505]
Warning: empty y range [1:1], adjusting to [0.99:1.01]
Warning: empty x range [0.005:0.005], adjusting to [0.00495:0.00505]
Warning: empty y range [4.40722e-19:4.40722e-19], adjusting to [4.36315e-19:4.45129e-19]
Warning: empty y2 range [4.40722e-19:4.40722e-19], adjusting to [4.36315e-19:4.45129e-19]
---------------------------

I use OpenSUSE 10.3 x64, python2.5 and gnuplot-4.2.
What can be wrong?

Thanks

Ivan

[jason]

Hi Bernhard,

I still have this problem too. I think my previous posts got wiped out when the hard drives failed recently.

Works ok for me on x32 but not on x64.

Regards

Jason

[gschaider]

Hi Ivan, Hi Jason!

Strange. I have CentOS5(==RHEL5) x64 with python2.4 and gnuplot4.0 (so it can't be a pure 32/64-bit issue) and I don't have that problem. Just tested it with python2.5 and gnuplot4.2 and it works too (so I don'T think that's the problem). Which version of PyFoam are you using? Have you checked whether for your configuration either Numeric or numpy is installed? (in Python ineractive mode either say
import Numeric
or
import numpy)

Bernhard

PS: I'll try and write a small test for that problem

[bychkov]

Bernhard,

I have installed Numeric, so command 'import Numeric' has no error.
Currently I am working with PyFoam 4.2.1 but I have the same problem with v.4.1.

Ivan

[jason]

Hi,

x32
OpenSUSE 10.2 x32
Python 2.5
PyFoam 0-4-1
gnuplot 4.0
gnuplot-py-1.7
import Numeric shows no errors

x64
OpenSUSE 10.2 x64
Python 2.5
PyFoam 0-4-1
gnuplot 4.0
gnuplot-py-1.7
import Numeric shows no errors

I set both up more or less exactly the same but I might have installed a few more options for the x64 installation.

Jason

[bychkov]

Hello all,

I found why PyFoam do not plot with OpenSUSE x64 (not only with OpenSUSE). The problem is gnuplot-py-1.7.
I have downloaded and installed the latest version of gnuplot-py from cvs (trunk). So, with new gnuplot-py I have no warnings about empty range and plotting is working.

Ivan

[gschaider]

Hi Ivan!

Thanks for pointing that out (am ashamed that I didn't come up with a solution yet). I hoped to have removed that kind of problem by adding Gnuplot.py as a ThirdParty-Library to the distribution. Must check whether the preinstalled or the distributed version take precedence. Will also have a look whether the CVS-version differs from the version that is included

Bernhard

[gschaider]

Hi Ivan!

Can you tell me, where you found the CVS-version of gnuplot-py that works? It seems that the project http://gnuplot-py.sourceforge.net/ switched to Subversion (wise decision) and I don't want to switch to the new version (which seems to be in the works) before it is released

Bernhard

[bychkov]

Hi Berhhard,

Sorry, I looked at main page when I wrote cvs. Really I use svn https://gnuplot-py.svn.sourceforge.n...oot/gnuplot-py.

I have no choice what version to use. Version 1.7 and earlier do not work for me. I found the description of this bug https://bugs.launchpad.net/ubuntu/+s...ot/+bug/110219
In version that currently under development this bug is fixed.

Ivan

[braennstroem]

Hi Bernhard,

a small question...
I am having problems to access the dictionaries to adjust the inlet velocity in a later time step. I avoided using dictionaries in python until now, so I tried some different options:
ceplx049~/SCR1/Solververgleich/E1_Messaufbau/FLUENT/E1_4.5Mio_Poly/0> pyFoamReadDictionary.py "omega" "boundaryField"
{'w-mittelkonsole': {'type': 'zeroGradient'}, 'w-karosserie': {'type': 'zeroGradient'}, 'w-fenster': {'type': 'zeroGradient'}, 'in-fm': {'type': 'fixedValue', 'value': <pyfoam.basics.datastructures.field>}, 'w-karosserie2': {'type': 'zeroGradient'}, 'in-hf': {'type': 'fixedValue', 'value': <pyfoam.basics.datastructures.field>}, 'w-dach': {'type': 'zeroGradient'}, 'in-hb': {'type': 'fixedValue', 'value': <pyfoam.basics.datastructures.field>}, 'w-am': {'type': 'zeroGradient'}, 'w-ruecksitze': {'type': 'zeroGradient'}, 'out-f': {'type': 'zeroGradient'}, 'out-b': {'type': 'zeroGradient'}, 'w-fussboden': {'type': 'zeroGradient'}, 'in-bm': {'type': 'fixedValue', 'value': <pyfoam.basics.datastructures.field>}, 'w-alt2': {'type': 'zeroGradient'}, 'in-ba': {'type': 'fixedValue', 'value': <pyfoam.basics.datastructures.field>}, 'w-alt': {'type': 'zeroGradient'}, 'w-vordersitze': {'type': 'zeroGradient'}, 'w-amout': {'type': 'zeroGradient'}, 'in-fa': {'type': 'fixedValue', 'value': <pyfoam.basics.datastructures.field>}, 'w-fussbereich': {'type': 'zeroGradient'}, 'w-fensterrahmen': {'type': 'zeroGradient'}}
ceplx049~/SCR1/Solververgleich/E1_Messaufbau/FLUENT/E1_4.5Mio_Poly/0> pyFoamReadDictionary.py "omega" "boundaryField["in-fm"]"
Error in /scr/ceplx049/scr1/gcae504/Software/OpenFOAM/PyFOAM-0.4.2.1/bin//pyFoamReadDicti onary.py : Key: boundaryField[in-fm] not existing in File omega
ceplx049~/SCR1/Solververgleich/E1_Messaufbau/FLUENT/E1_4.5Mio_Poly/0> pyFoamReadDictionary.py "omega" 'boundaryField["in-fm"]'
Error in /scr/ceplx049/scr1/gcae504/Software/OpenFOAM/PyFOAM-0.4.2.1/bin//pyFoamReadDicti onary.py : Key: boundaryField["in-fm"] not existing in File omega
ceplx049~/SCR1/Solververgleich/E1_Messaufbau/FLUENT/E1_4.5Mio_Poly/0> pyFoamReadDictionary.py "omega" "boundaryField['in-fm']"
Error in /scr/ceplx049/scr1/gcae504/Software/OpenFOAM/PyFOAM-0.4.2.1/bin//pyFoamReadDicti onary.py : Key: boundaryField['in-fm'] not existing in File omeg

Do you have a small hint for the reading and writing?
Thanks! Fabian

[gschaider]

Hi Fabian!

The basic form can only get dictionary entries that are on the "root level" of a dictionary. To access a subexpression you use the (surprise!) --subexpression-option:

pyFoamReadDictionary.py "omega" "boundaryField" --subexpression="['in-fm']"

Should do the trick for you. Basically it works by getting the "root entry" and then applying the subexpression to it. It's a bit clumsy, but that is because subexpressions were added to the utility as an afterthought.

To be honest: I havn't used that utility in a long time. One of the reasons is, that some quotes are needed for the shell (and stripped by it) and some are by python and it is a bit harder to get it right (I usually write a script using the ParsedParamterFile-class, that works quite pythony; but I understand that it's not an option for everyone)

Bernhard

PS: there might be a bug in the distribution that stops the utility from working with fields. It's not really a bug. It's a case of being too clever.

PPS: there might be a way to let the utility work the way you tried to use it. But I can't promise anything

@Ivan: I will have a look at the new version (whether it breaks anything) and try to include it

[braennstroem]

Hi Bernhard,
thanks for your help! May I take a look at your 'Parsing'-script? Would be nice.
Fabian