CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM Paraview & paraFoam (http://www.cfd-online.com/Forums/openfoam-paraview/)
-   -   pyFoam and paraview (http://www.cfd-online.com/Forums/openfoam-paraview/70311-pyfoam-paraview.html)

eelcovv November 20, 2009 02:49

pyFoam and paraview
 
Hi,

I just started exploring the use of pyFoam and I think it is a great set of utilities to make your openFoam live a lot easier.

I have a special interest in the paraview utilities, as I want to be able to create off-screen rendered images of state files.

Unfortunately, these scripts do not work. When I just type

pyFoamPVSnapshot.py --help


I get

Traceback (most recent call last):
File "/usr/local/bin/pyFoamPVSnapshot.py", line 3, in <module>
from PyFoam.Applications.PVSnapshot import PVSnapshot
File "/usr/local/lib/python2.6/dist-packages/PyFoam/Applications/PVSnapshot.py", line 13, in <module>
from PyFoam.Paraview.ServermanagerWrapper import ServermanagerWrapper as SM
File "/usr/local/lib/python2.6/dist-packages/PyFoam/Paraview/__init__.py", line 15, in <module>
from paraview import servermanager
File "/opt/OpenFOAM/ThirdParty-1.6/paraview-3.6.1/platforms/linux64Gcc/Utilities/VTKPythonWrapping/paraview/servermanager.py", line 43, in <module>
import paraview, re, os, new, sys, vtk
File "/opt/OpenFOAM/ThirdParty-1.6/paraview-3.6.1/platforms/linux64Gcc/Utilities/VTKPythonWrapping/paraview/vtk/__init__.py", line 4, in <module>
from libvtkCommonPython import *
ImportError: libvtkCommonPythonD.so.pv3.6: cannot open shared object file: No such file or directory


I have compiled paraview with python using
PYTHON_LIBRARY="/usr/lib64/libpython2.6.so.1.0"
and this went fine.
Also, I have added the export variable PYTHONPATH to the

etc/apps/paraview3/bashrc

Further, ParaFoam runs well.

Also I did the import test as suggested on the pyFoam wiki
import PyFoam
import PyFoam.FoamInformation
print PyFoam.FoamInformation.foamTutorials()and this give me the correct link to the tutorials

In paraFoam, however, I am not able to execute the most simple script
If I open the python shell and want to run the following script

Code:

from PyFoam.Paraview import readerObject,caseDirectory
from PyFoam.Paraview.SimpleSources import Glyph,Arrow

from PyFoam.RunDictionary.ParsedParameterFile import ParsedParameterFile
from os import path

ro=readerObject()

str=paraFoamReader().FileName.GetData()

I get the following message

p, li { white-space: pre-wrap; } Python 2.6.4 (r264:75706, Nov 2 2009, 15:01:28)
[GCC 4.4.1] on linux2
>>> from paraview.simple import *
>>>
Traceback (most recent call last):
File "<string>", line 9, in <module>
NameError: name 'paraFoamReader' is not defined

Well, I this point I am clueless what to do.

Could anybody say what could be wrong? Do I have the correct version of python? Do I need to set some more library paths?

Hopefully somebody has a clue, as I really would like to use the python capabilities of paraFoam, especially the pyFoam snapshot utility. Any hint appreciated!

Regards,

Eelco

eelcovv November 20, 2009 04:54

Oeps, I just read the last line of the update history of PyFoam

Currently does not work with Paraview 3.6 (which comes with OF 1.6)

And that is exactly what I am using.

I guess I have to be patient and wait for the new version.

Thanks anyway,

Cheers

Eelco

gschaider November 23, 2009 14:08

Quote:

Originally Posted by eelcovv (Post 237011)
Oeps, I just read the last line of the update history of PyFoam

Currently does not work with Paraview 3.6 (which comes with OF 1.6)

And that is exactly what I am using.

I guess I have to be patient and wait for the new version.

I'll do my best, but I'm not sure whether this problem will be solved this year due to external reasons (there are strange things going on in the Paraview-python code - calls to functions with the wrong number of parameters in places that I never touched) and me not having that much time, so don't hold your breath.

For the time being I would recommend snapshoting with an old 1.5-version (using the command "pyFoamPVSnapshot.py --foam=1.5 <other parameters>"). That should work. Although I guess that the state-files should be produced by a 3.3/3.4-paraview (but I never tried 3.6-state-files with 3.4, so you might get lucky)

Bernhard

eelcovv November 24, 2009 06:19

Ok,
thanks for the reply,
I will try to install the openfoam1.5 as well and let you know if this works with the 1.6 statefiles.
Regards,

Eelco

drrbradford September 29, 2011 09:00

Any advance on using OF 2.0.x with Paraview 3.10?

gschaider September 30, 2011 05:17

Quote:

Originally Posted by drrbradford (Post 326074)
Any advance on using OF 2.0.x with Paraview 3.10?

Quick try showed that it currently doesn't work (for neither of the readers). Not very high on my agenda currently. A Bug-Report at the OF-extend-Mantis might push it up a bit

eelcovv October 3, 2011 08:00

pvbatchprocess utility to make snapshots from statefiles and batchprocess cases
 
1 Attachment(s)
Hi

I have written a python script which can be run with pvbath (the paraview batch runner) which does what you want: creating off-line snapshots from statefiles. Paraview should be compiled with off-screen rendering and python enabled. The latest version 3.10 + bug fix has been used. See below.

I am here attaching a tar archive which contains an example how I set up my cases. The idea of having the possibilty to create snapshots offscreen is that you can apply your statefile to a series of cases you have run in OF.

I have made an example based on the famous icoFoam cavity. I have called the main directory cavityseries.

In principle you can unpack the tar.gz file (tar xzvf cavityseries.tar.gz) and run the 'go.sh' script. It processes all the steps.

The script which create a snapshot from a state file is pvbatchprocess.py.This script can be run directly from the command line as

pvbatch --use-offscreen-rendering pvbatchprocess.py --statefile 'statefilename'

If you type pvbatch pvbatchprocess.py --help you get a list of options which can be passed to the script. In case of the icoFoam case it is necessary for instance to use a timefactor in the name of the image files., so use the option --timefactor 1000

Statefile can be used applied to the whole data files in the numbered directory. Since that is in OpenFOAM format, I create a file in the case directory called pv.foam, and open this to read the time directories. The script will create this pv.foam file before reading the case, but I think you should base you statefile on a file pv.foam as well. To start paraview I use script call 'pv' with the lines

touch pv.foam
paraview
rm -v pv.foam

In this way, if you start paraview with 'pv' the file pv.foam is created in your directory automatically, which you can open to read you openfoam data files.

The statefile can also be based on the vtk files procuded by for instance the sample library during a run. I use this quite often. You have to make you statefile for one time step loaded from a single vtk file, and then the scripts read all the time steps from you vtk directory.

In order to batchprocess a serie of cases with the same statefile I use a perl script which is called pvbatchprocess.pl, which has the purpose to loop over a serie of cases, and loop over a series of statefile, and process all the images. It just sets up the calls to the python script pvbatchprocess.py. If you add the -test option to pvbatchprocess.pl you see only the commands as they are created, but they are not run yet.

The pvbatchprocess.pl script requires a small data file which has a list of cases and statefile is should process.
A case entry look like
#----------------------------------------------
# CASE 1 : cavity with movie wall velocity of U=0.5 m/s
case : cavity_U0.5_init1
name : cav_U0.5
label1: U_=_0.5_m/s@(0.68,0.04)s10x000000
label2: Start_up_U_middle@(0.68,0.005)s10xAA0000
#----------------------------------------------

It should start with the key word
# CASES 1
If 0 is given, the case is not processed
Then you see : separated lines with info. Mandetory is the case : casename keyword, which contains the directory name of the case to be processed. The image produced get as a base the casename, unless name:string is defined, then the alternative naming is used. Then you can add a list of lables to add description labels to you image (as many as you want). The label is a string which looks like labelstring_with_some_space@(x,y)sSSxFFFFFF
So you start with you string where you use _ for spaces, these a later replaced by spaces. (x,y) is the position of the string (x and y a numbers between 0 and 1). s10 is the size of the string, and xFFFFFF is the color, where the 6 digits are the RGB code in hexaformat (so white is FFFFFF, red would be FF0000, and any other colorcode can be used).
Each entry must end with a line
#-
at the beginning.

The list of state name are given by each

#----------------------------------------------
# STATE 1 : Pressure field on volume with streamlins
state : statefiles/pressurevolume.pvsm
inputdirectory : .
label5 : Pressure_field@(0.7,0.95)s18x000000
timefactor : 1000
timeformat : Time:_%5.0f_ms
timeposition : 0.68,0.09s10x0000AA
#----------------------------------------------
Again, of STATE 0 is given, the state is not processed. Other wise the field are read:
state: statefilename
inputdirectoy : .
In case that the OF openfields are read, this is just the base ., and if the vtk file are used, give the directory name where the vtk files can be found. In my case PlanesVTK. Again a list of labels per statefile can be given. And the time factor format, and position can be defined to put a annoted time somewhere in the image.

There is one big but: the latest version of paraview 3.10 is required. Especially if the script is processed on VTK file, you even need to latest GIT version, because the official latest download of 3.10 contains a bug causing the vtk not being updated. I reported this bug and a bug fixed was released. I compiled paraview with this patch and now it worked. But I think the git version of paraview should already have this patch. For the openfoam whole data format the script also works without the patch. For more info on this issue, see http://www.mail-archive.com/paraview.../msg12999.html


Well, a lot of information. For me the proceedure works very fine. Just unpack the tar.gz and run go.sh

First three cases are run for the cavity with 3 different top velocities. This is done with cavUvar.py script which uses bernards pvFoam library, so this should be installed.
Then pvbatchprocess.pl is run on the input file pvcases.dat. I set the background to white with -background FFFFFF
Then I use a script I wrote a long time ago to turn a series of image into a mpgmovie, which is called tifftompg.pl. It is included to the tar ball. This tifftompg.pl is actually a front end to 'mencoder' utility, so this should be installed. But it does some handy things. It check to image format, sets the list of image in numerical order. etc. It works for me.
After the script is done, you should have 6 movies based on three cases with two different state files.

Well, hopefully this is useful. Please feed back any improvements to me, I am sure this can be done a lot better and still it there are probably some bugs. But it does basically what I want from it, so it works for me.
Good luck!

Regards,

Eelco

eelcovv January 17, 2012 07:29

update pvbatch processing scripts
 
1 Attachment(s)
Apparently not many users would like to batch process their openfoam data to make series of images. Nevertheless, here an update of the scripts. Some bug fixes. A small modification of the pvcases.dat file format (removed the double column between the key field and value field in order to allow to use double columns in labels). And the script has been tested on paraview 3.12, and it seems to work with a small modification in the original script (servermanager.Connect() apparently is not allowed anymore).
Just run the go.sh script to launch first a batchscript over the velocities for the cavity (pyFoam needs to be installed!) and subsequently make all the images of all the cases using the pvbathprocess.pl script. As a last step, the movies are created from the images using tifftompg.pl (included).
Good luck!
Regards
Eelco

gschaider January 17, 2012 10:58

Quote:

Originally Posted by eelcovv (Post 339711)
Apparently not many users would like to batch process their openfoam data to make series of images. Nevertheless, here an update of the scripts. Some bug fixes. A small modification of the pvcases.dat file format (removed the double column between the key field and value field in order to allow to use double columns in labels). And the script has been tested on paraview 3.12, and it seems to work with a small modification in the original script (servermanager.Connect() apparently is not allowed anymore).
Just run the go.sh script to launch first a batchscript over the velocities for the cavity (pyFoam needs to be installed!) and subsequently make all the images of all the cases using the pvbathprocess.pl script. As a last step, the movies are created from the images using tifftompg.pl (included).
Good luck!
Regards
Eelco

Hi Eelco!

I think there is a need for such a thing. The problem (at least in the past) was that if it works on one machine it doesn't necessarily work on another. So my experience with pyFoamPVSnapshot.py was that it worked for me, also for some other people but other people got obscure errors (most of them due to different Paraview-versions, or even worse due to differences in the dynamic-library-loading (which the plugin-system builds on))

So I'm very interested and will have a look at your stuff. Mostly to see if there are any ideas that I can steal for pyFoamPVSnapshot.py

BTW: could you tell me the reasons why you decided against using that as you're using PyFoam also? (I'm sure there's a good reason. Knowing it could help me to improve it)

Bernhard

PS: I guess you get asked that all the time and its quite a common surname I guess, but I'll ask it anyway: you're not related to the great late Captain Beefheart?

eelcovv January 18, 2012 05:23

1 Attachment(s)
Hi Bernhard,

Yes, I am a big fan of almost all the software you have developed. Except that the pyFoamSnapShot utility did not work with paraview 3.6 (according to the first post of this treat), and I didn't like to keep using those outdated paraview versions. So I was never able to use pyFoamSnapshot, although I never checked it again. Does it work on paraview 3.12?

In my opinion the weak point of paraview is the fact that a statefile saved for one case can not easily be applied to another case. In the latest version that allows you to modify the path by hand once you load a statefile. But this can only be done by the GUI, so does not allow batch processing. Another problems is the vtk planes generate with the functionobjectlibs (libsampling) which are stored in seperate directories. One solution is to move all these files in seperate directories into a single new directory, which then allows you to open all the files at once in paraview. But I don't like this solution, as you loose the information on the time at which the vtk files where generated, and also you have to modify the directory struture each time you have run a case. Another draw back is that if you create a statefile this way for let say 20 planes, it does not read the new planes if these are create later in time. (For those who to like this solution anyway: have a look at the script attached. It is quite usefull for collecting all planes and move them to a single directory.) Finally a problem with paraview (at least: the older versions) was that the statefile are not accurate: the label position were not kept but after reloading a state all labels were put in the right bottom corner. And more small errors like that.

Since I am lazy and therefore want to do as much of batch processing as possible, I started with exploring writing python scripting all my paraview visualisation. Basically, during building you image you keep tracking the python commands (Tools->start Trace), put them in a script, and run this off-scrreen with pvbatch. In this way, loading the same scene on several cases is much more accurate, and also the positioning of labels is more accuratute. The only problem is that it is quite time consuming to build image by using the python command. It is quite error prone, so getting the script correct takes some.

However, from the python script is is possible to load a state file and then loop over the time steps. The only remaining problem was: the state file generated for one case has hard paths to all the vtk files and openfoam cases, and there is no paraview command to modify this. So therefore I started pyfoambatchprocess.py. The trick is that I make a hard copy of the statefile generated for one case into the /tmp directory, and then use regular expression to replace all the paths and filenames for the new case directory. I do the same for the filename of the vtk file. Once the new statefile with the new pathname is generated, I use the python commands to add labels and a time to the scene. Then you can loop over all the time steps and generate all the images. There is some more tricking to multiply the time step with a factor, so that you can have integer time value in the filenaming (handy if the time steps are order 1e-5 or so). So this is all the python script does.

The perl script pvbatchprocess.pl is mainly to be able to set up a whole sequence of call to pvbatchprocess.py: one call for each case and each state file. Each state and each case file can add its own labels, so you can make a distincion between all cases (for instance: a label stating the current inlet velocity for that case). All the states and cases are defined in a small dat file which a entry for each of them (see description above)

The scripts were developed for my own usage mainly, so I never intented to write it as generic as possible. Therefore I am not sure how good it works for others. Having said that: the scripts are in our system directories and my collegues are able to use them without problem. But they are running on the same system of course. However, for loading the time step a bug fix was released, so it works only for the git version of paraview 3.10.1, and, in the update I uploaded, with paraview 3.12.

As far as I see, the only point which make the script less generic is the fact that it assumes that the full path toward the current case starts with /home and ends with pv.foam (see line 285). This means that the openfoam case must be loaded by opening a file called pv.foam in the case directory.

Well, the script is quite a hack, but I use it for a while and it works for me and definitely safes me loads of time. However, I am sure it can be written much more elegant, so if you would like to take out some tricks and can incorporate it into pyFoam that would be fantastic of course. As I said: I am a big fan of your software and using it all the time, it makes my openfoam life much easier:-)

About my last name: you are the first to ask and I actually had never heard of Captain Beefheard. I don't think we are family, although his name for sure is Dutch. I do play guitar, so who knows:)

eelcovv March 28, 2012 04:16

pvbatchprocess update
 
1 Attachment(s)
To anybody interested in off-screen batchb processing of openfoam and vtk files with paraview (version 3.12 is recommended): here a new version of my pvbatchprocess scripts. I removed some bug and improved to processing of gzipped vtk files (which allow you to zip all your vtk planes which save about 70% disc space and still allow you to batchprocess your images)

The pythonscript pvbatchprocess.py should be called to actually process a time range of a single openfoam case for one single state file. The perl script pvbatchprocess.pl can be used to set up a series of calls to pvbatchprocess.py to different cases and statefiles as defined in the pvcases.dat file. And finally, I have added one more script to make one call pvbatchprocess.pl for a long time range, which is then subdevided into N calls of N subsquent sub time ranges which are submitted to a queue (of a qsub system in this case, but modify to you own needs if required). This allows you to reserve a node with N cores and use all N cores in parallel on one time sequence. Especially handy if you pay per node hour and want to use all cores on one script:-)

Well, a more detailed description I already gave in the earlier posts. Not much responds so far, so not many people gave it a try. Put I can assure you it is saving me a lot of time:-)

Regards
Eelco

eelcovv March 28, 2012 07:02

latest version pvbatchprocess utils
 
2 Attachment(s)
As usual, found another bug at the last moment. Minor, but still.
Anyway, the scripts should work now. Also more generic. So put all scripts pvbatch* somewhere in your path (/usr/local/bin for instance). Unpack the cavityseries.tar.gz. Run 'go.sh'. This should run three cases using the pyFoam utils. Then three statefiles on the three cases are processed. Only tested with paraview 3.12

Regards
Eelco

eelcovv March 29, 2012 05:16

bug fix pvbatchprocess
 
2 Attachment(s)
Got a comment on a bug of the script when the directory name of the case happens to be a pure number. In that case my regexp take this number as the time value. Well, fixed it, and made a few improvements. Now also time dirtories containing an exponential can be handled, like 1.0e-6.

Unpack pvbatch.tar.gz anywhere in your path, such as /usr/local/bin
unpack cavityseries.tar.gz and run go.sh.

Regards
Eelco

hananfoam September 12, 2012 12:01

paraview 3.14
 
Hi,

Did you test your script with paraview 3.14?
I am running into problems, as go.sh getds stuck after starting to make the first image. this are the few last lines of screen output:

/home/hanan/OpenFOAM/hanan-2.1.1/run/cavityseries/cavity_U1.0_init1/PlanesVTK///0.005//U_pxy.vtk.gz: 71.6%
adding reader: U_pxy
finding source: U_pxy.vtk
adding src of U_pxy
Adding the labels
reading label: U_=_1.0_m/s@(0.68,0.04)s10x000000
reading label: Start_up_U_high@(0.68,0.005)s10xAA0000
reading label: Streamlines@(0.05,0.9)s10x000000
Writing images:
+++++++++++++++++++++ tme 0.005 +++++++++++++++++++++++++++++++++++++
updating: /home/hanan/OpenFOAM/hanan-2.1.1/run/cavityseries/cavity_U1.0_init1/PlanesVTK//0.005/U_pxy.vtk

Since this is the first image being created, this is obviously crucial :)

Thanks,
Hanan.

mmkr825 September 12, 2012 13:02

About installation of swak4Foam
 
Hi everyone,
I am fresher for openFoam. I came to know the uses of swak4Foam utility. But i am not able to install swak4Foam. I followed each and every step correctly but, got the following error message.

Error Message:-

malli_reddy@ubuntu:~/OpenFOAM/malli_reddy-2.1.1$ svn checkout https://openfoam-extend.svn.sourcefo...ies/swak4Foam/

svn: OPTIONS of 'https://openfoam-extend.svn.sourcefo...ries/swak4Foam': Could not resolve hostname `openfoam-extend.svn.sourceforge.net': No address associated with hostname (https://openfoam-extend.svn.sourceforge.net)

Please help me to overcome this problem. Now iam using OF 2.1.1 version.

Thanks
Regards
Mallikarjuna

gschaider September 17, 2012 19:21

Quote:

Originally Posted by mmkr825 (Post 381459)
Hi everyone,
I am fresher for openFoam. I came to know the uses of swak4Foam utility. But i am not able to install swak4Foam. I followed each and every step correctly but, got the following error message.

Error Message:-

malli_reddy@ubuntu:~/OpenFOAM/malli_reddy-2.1.1$ svn checkout https://openfoam-extend.svn.sourcefo...ies/swak4Foam/

svn: OPTIONS of 'https://openfoam-extend.svn.sourcefo...ries/swak4Foam': Could not resolve hostname `openfoam-extend.svn.sourceforge.net': No address associated with hostname (https://openfoam-extend.svn.sourceforge.net)

Please help me to overcome this problem. Now iam using OF 2.1.1 version.

Thanks
Regards
Mallikarjuna

The command

host openfoam-extend.svn.sourceforge.net

gives me

openfoam-extend.svn.sourceforge.net has address 216.34.181.177
openfoam-extend.svn.sourceforge.net has address 216.34.181.65

So the host is definitely there. Could you check your internet-setup?

eelcovv October 15, 2013 09:08

Latest version pvbatchprocess
 
1 Attachment(s)
In case anybody interested. The latest version of pvbatchprocess.
Contains some new features and bug fixed.

Most simple use can be found in the case above:

pvbatch pvbatchprocess.py <casedir> --statefile <statefile>

This reads the time range and generates for the case in casedir the images as defined in the statefile (the pvsm file generated with paraview)

A way to set up a whole sequence of case defined in a serie of casedir with a series of statefile, the pvbatchprocess.pl scripts together with the pvcases.dat inputfile can be used.
In the pvcases.dat file you can specify the details (see the example pvcases.dat file).

Then, run

pvbatchprocess.pl pvcases.dat

That's it.

Finally, the pvbatchpreprocess.pl script can be used in order to defined the timerange in intervals. Each interval is submitted independently, such that you can run a whole time ragne faster.

pvbatchpreprocess.pl -timerange 0:10 -ninterval 10 pvcases.dat -background FFFFFF -cluster

This command generates the images of the cases and statefiles defined in pvcases.dat for the time range from 0 to 10 s, where the time range is devided in intervals of 1 s. The -cluster option will submit the pvbatch script to a cluster. This only works if a script for submitting pvbatch cases to a cluster is available. Without -cluster, it will be running locally on you computer. The-background FFFFFF set the background to white (FFFFFF is hexacolor for white)

Eelco

kilroy October 16, 2013 11:53

Eelco,

Thank you very much for this great utility. But unfortunately, I am having some issues using it.

I have a headless (no screen or video card) machine on which I have Ubuntu Server 12.04.3 LTS installed in it. I built ParaView (v3.12.0) from source with off-screen rendering and python enabled. Before ParaView I built Mesa (v9.1.6) with osmesa enabled and I also have installed glu libraries (v9.0.0). I have OpenFoam (v2.1.1) with PyFoam (v0.6.1).

I extracted the pvbatch files that you have provided yesterday into "/usr/local/lib" folder and I tried to run the cavitiy series case that you have provided. But during the process, the code gets stuck in a certain step. Please see the terminal output below.

Could you please help me to get the code working? Thanks for the help in advance.



Code:

cavity_U0.5_init1/PlanesVTK/0.19/U_pxy.vtk:      69.6% -- replaced with cavity_U0.5_init1/PlanesVTK/0.19/U_pxy.vtk.gz
cavity_U0.5_init1/PlanesVTK/0.19/p_pxy.vtk:      69.9% -- replaced with cavity_U0.5_init1/PlanesVTK/0.19/p_pxy.vtk.gz
cavity_U0.5_init1/PlanesVTK/0.14/U_pxy.vtk:      69.6% -- replaced with cavity_U0.5_init1/PlanesVTK/0.14/U_pxy.vtk.gz
cavity_U0.5_init1/PlanesVTK/0.14/p_pxy.vtk:      69.9% -- replaced with cavity_U0.5_init1/PlanesVTK/0.14/p_pxy.vtk.gz
cavity_U0.5_init1/PlanesVTK/0.16/U_pxy.vtk:      69.5% -- replaced with cavity_U0.5_init1/PlanesVTK/0.16/U_pxy.vtk.gz
cavity_U0.5_init1/PlanesVTK/0.16/p_pxy.vtk:      70.0% -- replaced with cavity_U0.5_init1/PlanesVTK/0.16/p_pxy.vtk.gz
cavity_U0.5_init1/PlanesVTK/0.145/U_pxy.vtk:    69.6% -- replaced with cavity_U0.5_init1/PlanesVTK/0.145/U_pxy.vtk.gz
cavity_U0.5_init1/PlanesVTK/0.145/p_pxy.vtk:    70.0% -- replaced with cavity_U0.5_init1/PlanesVTK/0.145/p_pxy.vtk.gz
cavity_U0.5_init1/PlanesVTK/0.185/U_pxy.vtk:    69.6% -- replaced with cavity_U0.5_init1/PlanesVTK/0.185/U_pxy.vtk.gz
cavity_U0.5_init1/PlanesVTK/0.185/p_pxy.vtk:    69.9% -- replaced with cavity_U0.5_init1/PlanesVTK/0.185/p_pxy.vtk.gz
cavity_U0.5_init1/PlanesVTK/0.17/U_pxy.vtk:      69.6% -- replaced with cavity_U0.5_init1/PlanesVTK/0.17/U_pxy.vtk.gz
cavity_U0.5_init1/PlanesVTK/0.17/p_pxy.vtk:      69.8% -- replaced with cavity_U0.5_init1/PlanesVTK/0.17/p_pxy.vtk.gz
cavity_U0.5_init1/PlanesVTK/0.015/U_pxy.vtk:    69.7% -- replaced with cavity_U0.5_init1/PlanesVTK/0.015/U_pxy.vtk.gz
cavity_U0.5_init1/PlanesVTK/0.015/p_pxy.vtk:    69.8% -- replaced with cavity_U0.5_init1/PlanesVTK/0.015/p_pxy.vtk.gz
cavity_U0.5_init1/PlanesVTK/0.115/U_pxy.vtk:    69.6% -- replaced with cavity_U0.5_init1/PlanesVTK/0.115/U_pxy.vtk.gz
cavity_U0.5_init1/PlanesVTK/0.115/p_pxy.vtk:    69.9% -- replaced with cavity_U0.5_init1/PlanesVTK/0.115/p_pxy.vtk.gz
cavity_U0.5_init1/PlanesVTK/0.18/U_pxy.vtk:      69.6% -- replaced with cavity_U0.5_init1/PlanesVTK/0.18/U_pxy.vtk.gz
cavity_U0.5_init1/PlanesVTK/0.18/p_pxy.vtk:      69.8% -- replaced with cavity_U0.5_init1/PlanesVTK/0.18/p_pxy.vtk.gz
cavity_U0.5_init1/PlanesVTK/0.125/U_pxy.vtk:    69.5% -- replaced with cavity_U0.5_init1/PlanesVTK/0.125/U_pxy.vtk.gz
cavity_U0.5_init1/PlanesVTK/0.125/p_pxy.vtk:    69.9% -- replaced with cavity_U0.5_init1/PlanesVTK/0.125/p_pxy.vtk.gz
cavity_U0.5_init1/PlanesVTK/0.02/U_pxy.vtk:      69.7% -- replaced with cavity_U0.5_init1/PlanesVTK/0.02/U_pxy.vtk.gz
cavity_U0.5_init1/PlanesVTK/0.02/p_pxy.vtk:      69.9% -- replaced with cavity_U0.5_init1/PlanesVTK/0.02/p_pxy.vtk.gz
cavity_U0.5_init1/PlanesVTK/0.11/U_pxy.vtk:      69.7% -- replaced with cavity_U0.5_init1/PlanesVTK/0.11/U_pxy.vtk.gz
cavity_U0.5_init1/PlanesVTK/0.11/p_pxy.vtk:      69.9% -- replaced with cavity_U0.5_init1/PlanesVTK/0.11/p_pxy.vtk.gz
cavity_U0.5_init1/PlanesVTK/0.06/U_pxy.vtk:      69.6% -- replaced with cavity_U0.5_init1/PlanesVTK/0.06/U_pxy.vtk.gz
cavity_U0.5_init1/PlanesVTK/0.06/p_pxy.vtk:      69.9% -- replaced with cavity_U0.5_init1/PlanesVTK/0.06/p_pxy.vtk.gz
cavity_U0.5_init1/PlanesVTK/0.055/U_pxy.vtk:    69.6% -- replaced with cavity_U0.5_init1/PlanesVTK/0.055/U_pxy.vtk.gz
cavity_U0.5_init1/PlanesVTK/0.055/p_pxy.vtk:    69.9% -- replaced with cavity_U0.5_init1/PlanesVTK/0.055/p_pxy.vtk.gz
cavity_U0.5_init1/PlanesVTK/0.195/U_pxy.vtk:    69.7% -- replaced with cavity_U0.5_init1/PlanesVTK/0.195/U_pxy.vtk.gz
cavity_U0.5_init1/PlanesVTK/0.195/p_pxy.vtk:    69.8% -- replaced with cavity_U0.5_init1/PlanesVTK/0.195/p_pxy.vtk.gz
cavity_U0.5_init1/PlanesVTK/0.04/U_pxy.vtk:      69.6% -- replaced with cavity_U0.5_init1/PlanesVTK/0.04/U_pxy.vtk.gz
cavity_U0.5_init1/PlanesVTK/0.04/p_pxy.vtk:      70.0% -- replaced with cavity_U0.5_init1/PlanesVTK/0.04/p_pxy.vtk.gz
cavity_U0.5_init1/PlanesVTK/0.01/U_pxy.vtk:      69.9% -- replaced with cavity_U0.5_init1/PlanesVTK/0.01/U_pxy.vtk.gz
cavity_U0.5_init1/PlanesVTK/0.01/p_pxy.vtk:      70.0% -- replaced with cavity_U0.5_init1/PlanesVTK/0.01/p_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.045/U_pxy.vtk:    69.5% -- replaced with cavity_U1.0_init1/PlanesVTK/0.045/U_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.045/p_pxy.vtk:    69.9% -- replaced with cavity_U1.0_init1/PlanesVTK/0.045/p_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.085/U_pxy.vtk:    69.3% -- replaced with cavity_U1.0_init1/PlanesVTK/0.085/U_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.085/p_pxy.vtk:    69.8% -- replaced with cavity_U1.0_init1/PlanesVTK/0.085/p_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.03/U_pxy.vtk:      69.5% -- replaced with cavity_U1.0_init1/PlanesVTK/0.03/U_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.03/p_pxy.vtk:      69.7% -- replaced with cavity_U1.0_init1/PlanesVTK/0.03/p_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.155/U_pxy.vtk:    69.5% -- replaced with cavity_U1.0_init1/PlanesVTK/0.155/U_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.155/p_pxy.vtk:    69.8% -- replaced with cavity_U1.0_init1/PlanesVTK/0.155/p_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.07/U_pxy.vtk:      69.4% -- replaced with cavity_U1.0_init1/PlanesVTK/0.07/U_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.07/p_pxy.vtk:      69.8% -- replaced with cavity_U1.0_init1/PlanesVTK/0.07/p_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.12/U_pxy.vtk:      69.5% -- replaced with cavity_U1.0_init1/PlanesVTK/0.12/U_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.12/p_pxy.vtk:      69.7% -- replaced with cavity_U1.0_init1/PlanesVTK/0.12/p_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.005/U_pxy.vtk:    71.6% -- replaced with cavity_U1.0_init1/PlanesVTK/0.005/U_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.005/p_pxy.vtk:    69.8% -- replaced with cavity_U1.0_init1/PlanesVTK/0.005/p_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.09/U_pxy.vtk:      69.5% -- replaced with cavity_U1.0_init1/PlanesVTK/0.09/U_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.09/p_pxy.vtk:      69.7% -- replaced with cavity_U1.0_init1/PlanesVTK/0.09/p_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.135/U_pxy.vtk:    69.5% -- replaced with cavity_U1.0_init1/PlanesVTK/0.135/U_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.135/p_pxy.vtk:    69.8% -- replaced with cavity_U1.0_init1/PlanesVTK/0.135/p_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.095/U_pxy.vtk:    69.5% -- replaced with cavity_U1.0_init1/PlanesVTK/0.095/U_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.095/p_pxy.vtk:    69.7% -- replaced with cavity_U1.0_init1/PlanesVTK/0.095/p_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.025/U_pxy.vtk:    69.4% -- replaced with cavity_U1.0_init1/PlanesVTK/0.025/U_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.025/p_pxy.vtk:    69.8% -- replaced with cavity_U1.0_init1/PlanesVTK/0.025/p_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.05/U_pxy.vtk:      69.6% -- replaced with cavity_U1.0_init1/PlanesVTK/0.05/U_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.05/p_pxy.vtk:      69.8% -- replaced with cavity_U1.0_init1/PlanesVTK/0.05/p_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.175/U_pxy.vtk:    69.5% -- replaced with cavity_U1.0_init1/PlanesVTK/0.175/U_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.175/p_pxy.vtk:    69.8% -- replaced with cavity_U1.0_init1/PlanesVTK/0.175/p_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.065/U_pxy.vtk:    69.5% -- replaced with cavity_U1.0_init1/PlanesVTK/0.065/U_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.065/p_pxy.vtk:    69.8% -- replaced with cavity_U1.0_init1/PlanesVTK/0.065/p_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.165/U_pxy.vtk:    69.5% -- replaced with cavity_U1.0_init1/PlanesVTK/0.165/U_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.165/p_pxy.vtk:    69.7% -- replaced with cavity_U1.0_init1/PlanesVTK/0.165/p_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.15/U_pxy.vtk:      69.5% -- replaced with cavity_U1.0_init1/PlanesVTK/0.15/U_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.15/p_pxy.vtk:      69.8% -- replaced with cavity_U1.0_init1/PlanesVTK/0.15/p_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.13/U_pxy.vtk:      69.4% -- replaced with cavity_U1.0_init1/PlanesVTK/0.13/U_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.13/p_pxy.vtk:      69.8% -- replaced with cavity_U1.0_init1/PlanesVTK/0.13/p_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.035/U_pxy.vtk:    69.4% -- replaced with cavity_U1.0_init1/PlanesVTK/0.035/U_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.035/p_pxy.vtk:    69.8% -- replaced with cavity_U1.0_init1/PlanesVTK/0.035/p_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.1/U_pxy.vtk:      69.5% -- replaced with cavity_U1.0_init1/PlanesVTK/0.1/U_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.1/p_pxy.vtk:      69.8% -- replaced with cavity_U1.0_init1/PlanesVTK/0.1/p_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.08/U_pxy.vtk:      69.5% -- replaced with cavity_U1.0_init1/PlanesVTK/0.08/U_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.08/p_pxy.vtk:      69.7% -- replaced with cavity_U1.0_init1/PlanesVTK/0.08/p_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.2/U_pxy.vtk:      69.5% -- replaced with cavity_U1.0_init1/PlanesVTK/0.2/U_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.2/p_pxy.vtk:      69.8% -- replaced with cavity_U1.0_init1/PlanesVTK/0.2/p_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.105/U_pxy.vtk:    69.5% -- replaced with cavity_U1.0_init1/PlanesVTK/0.105/U_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.105/p_pxy.vtk:    69.8% -- replaced with cavity_U1.0_init1/PlanesVTK/0.105/p_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.075/U_pxy.vtk:    69.6% -- replaced with cavity_U1.0_init1/PlanesVTK/0.075/U_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.075/p_pxy.vtk:    69.9% -- replaced with cavity_U1.0_init1/PlanesVTK/0.075/p_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.19/U_pxy.vtk:      69.5% -- replaced with cavity_U1.0_init1/PlanesVTK/0.19/U_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.19/p_pxy.vtk:      69.8% -- replaced with cavity_U1.0_init1/PlanesVTK/0.19/p_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.14/U_pxy.vtk:      69.5% -- replaced with cavity_U1.0_init1/PlanesVTK/0.14/U_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.14/p_pxy.vtk:      69.7% -- replaced with cavity_U1.0_init1/PlanesVTK/0.14/p_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.16/U_pxy.vtk:      69.5% -- replaced with cavity_U1.0_init1/PlanesVTK/0.16/U_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.16/p_pxy.vtk:      69.8% -- replaced with cavity_U1.0_init1/PlanesVTK/0.16/p_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.145/U_pxy.vtk:    69.5% -- replaced with cavity_U1.0_init1/PlanesVTK/0.145/U_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.145/p_pxy.vtk:    69.8% -- replaced with cavity_U1.0_init1/PlanesVTK/0.145/p_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.185/U_pxy.vtk:    69.4% -- replaced with cavity_U1.0_init1/PlanesVTK/0.185/U_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.185/p_pxy.vtk:    69.8% -- replaced with cavity_U1.0_init1/PlanesVTK/0.185/p_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.17/U_pxy.vtk:      69.4% -- replaced with cavity_U1.0_init1/PlanesVTK/0.17/U_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.17/p_pxy.vtk:      69.8% -- replaced with cavity_U1.0_init1/PlanesVTK/0.17/p_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.015/U_pxy.vtk:    69.6% -- replaced with cavity_U1.0_init1/PlanesVTK/0.015/U_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.015/p_pxy.vtk:    69.8% -- replaced with cavity_U1.0_init1/PlanesVTK/0.015/p_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.115/U_pxy.vtk:    69.6% -- replaced with cavity_U1.0_init1/PlanesVTK/0.115/U_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.115/p_pxy.vtk:    69.8% -- replaced with cavity_U1.0_init1/PlanesVTK/0.115/p_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.18/U_pxy.vtk:      69.5% -- replaced with cavity_U1.0_init1/PlanesVTK/0.18/U_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.18/p_pxy.vtk:      69.8% -- replaced with cavity_U1.0_init1/PlanesVTK/0.18/p_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.125/U_pxy.vtk:    69.4% -- replaced with cavity_U1.0_init1/PlanesVTK/0.125/U_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.125/p_pxy.vtk:    69.8% -- replaced with cavity_U1.0_init1/PlanesVTK/0.125/p_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.02/U_pxy.vtk:      69.5% -- replaced with cavity_U1.0_init1/PlanesVTK/0.02/U_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.02/p_pxy.vtk:      69.8% -- replaced with cavity_U1.0_init1/PlanesVTK/0.02/p_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.11/U_pxy.vtk:      69.4% -- replaced with cavity_U1.0_init1/PlanesVTK/0.11/U_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.11/p_pxy.vtk:      69.8% -- replaced with cavity_U1.0_init1/PlanesVTK/0.11/p_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.06/U_pxy.vtk:      69.5% -- replaced with cavity_U1.0_init1/PlanesVTK/0.06/U_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.06/p_pxy.vtk:      69.8% -- replaced with cavity_U1.0_init1/PlanesVTK/0.06/p_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.055/U_pxy.vtk:    69.5% -- replaced with cavity_U1.0_init1/PlanesVTK/0.055/U_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.055/p_pxy.vtk:    69.9% -- replaced with cavity_U1.0_init1/PlanesVTK/0.055/p_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.195/U_pxy.vtk:    69.5% -- replaced with cavity_U1.0_init1/PlanesVTK/0.195/U_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.195/p_pxy.vtk:    69.9% -- replaced with cavity_U1.0_init1/PlanesVTK/0.195/p_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.04/U_pxy.vtk:      69.4% -- replaced with cavity_U1.0_init1/PlanesVTK/0.04/U_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.04/p_pxy.vtk:      69.8% -- replaced with cavity_U1.0_init1/PlanesVTK/0.04/p_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.01/U_pxy.vtk:      69.6% -- replaced with cavity_U1.0_init1/PlanesVTK/0.01/U_pxy.vtk.gz
cavity_U1.0_init1/PlanesVTK/0.01/p_pxy.vtk:      69.9% -- replaced with cavity_U1.0_init1/PlanesVTK/0.01/p_pxy.vtk.gz
Reading case file pvcases.dat
++++++ Add case        cavity with movie wall velocity of U=1 m/s
-----------------------------------------
++++++ Add case          cavity with movie wall velocity of U=0.5 m/s
-----------------------------------------
++++++ Add case          cavity with movie wall velocity of U=0.2 m/s
-----------------------------------------
++++++ Add case          cavity with movie wall velocity of U=0.2 m/s
-----------------------------------------
++++++ Add state        Velocity with streamlines
-----------------------------------------
++++++ Add state        Velocity with vectors
-----------------------------------------
++++++ Add state        Pressure field on volume with streamlins
-----------------------------------------
Closing case file
Found 4 case(s) with 3 state(s)
Found pvbatchprocess /usr/local/bin/pvbatchprocess.py
++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++ CASES:  cavity_U1.0_init1
++++++++++++++++++++++++++++++++++++++++++++++++++++++
touch cavity_U1.0_init1/pv.foam
create cavity_U1.0_init1/pv.foam---- STATE: statefiles/Ustreamlines.pvsm -----------------
pvbatch  /usr/local/bin/pvbatchprocess.py  --casedir cavity_U1.0_init1 --outputdir Images --inputdir "PlanesVTK" --verbose --label "U_=_1.0_m/s@(0.68,0.04)s10x000000" --label "Start_up_U_high@(0.68,0.005)s10xAA0000" --label "Streamlines@(0.05,0.9)s10x000000" --statefile statefiles/Ustreamlines.pvsm --imagebase cav_U1.0_Ustreamlines --background 'FFFFFF' --timeformat "Time:_%5.0f_ms" --timeposition "0.68,0.09s10x0000AA" --timefactor "1000" --skipexist
starting pvbatchprocess.py
Case directory        : cavity_U1.0_init1
Input directory      : PlanesVTK
Output directory      : Images
Image basename        : cav_U1.0_Ustreamlines
Statefile            : statefiles/Ustreamlines.pvsm
Start time            : -99999.000000
End time              : 99999.000000
Time format          : Time:_%5.0f_ms
Time file format      :
Time factor          : 1000.000000
Time file factor      : 1.000000
Time position        : 0.68,0.09s10x0000AA
Clean up tmp files    : 1
Skip existing images  : 1
LatestTime            : 0
Creating output directory /home/meta/projects/cavityseries/cavity_U1.0_init1/Images
RENDERING ON # 1 cores:
reading time steps from /home/meta/projects/cavityseries/cavity_U1.0_init1/PlanesVTK/
add 0.005
add 0.01
add 0.015
add 0.02
add 0.025
add 0.03
add 0.035
add 0.04
add 0.045
add 0.05
add 0.055
add 0.06
add 0.065
add 0.07
add 0.075
add 0.08
add 0.085
add 0.09
add 0.095
add 0.1
add 0.105
add 0.11
add 0.115
add 0.12
add 0.125
add 0.13
add 0.135
add 0.14
add 0.145
add 0.15
add 0.155
add 0.16
add 0.165
add 0.17
add 0.175
add 0.18
add 0.185
add 0.19
add 0.195
add 0.2
time steps: 0.005, 0.01, 0.015, 0.02, 0.025, 0.03, 0.035, 0.04, 0.045, 0.05, 0.055, 0.06, 0.065, 0.07, 0.075, 0.08, 0.085, 0.09, 0.095, 0.1, 0.105, 0.11, 0.115, 0.12, 0.125, 0.13, 0.135, 0.14, 0.145, 0.15, 0.155, 0.16, 0.165, 0.17, 0.175, 0.18, 0.185, 0.19, 0.195, 0.2
loading statefile: statefiles/Ustreamlines.pvsm
no pv.foam file found in statefile.
vtkfilebasepath : /home/eelco/OpenFOAM/eelco-2.1.0/run/tutorials/incompressible/icoFoam/cavityseries/cavity_U0.2_init1/PlanesVTK/
vtkfilebasetime : 0.005
vtksubdir : PlanesVTK
vtkfilebasepath : /home/eelco/OpenFOAM/eelco-2.1.0/run/tutorials/incompressible/icoFoam/cavityseries/cavity_U0.2_init1/PlanesVTK/
vtkfilebasetime : 0.005
vtksubdir : PlanesVTK
taking as statefile basepath: /home/eelco/OpenFOAM/eelco-2.1.0/run/tutorials/incompressible/icoFoam/cavityseries/cavity_U0.2_init1/
writing to temporary statefile: /tmp/pvtemp_t1381875351.857575.pvsm
/home/meta/projects/cavityseries/cavity_U1.0_init1/PlanesVTK//0.005/U_pxy.vtk.gz:        71.6%
loading clead state file /tmp/pvtemp_t1381875351.857575.pvsm
adding reader: U_pxy
finding source: U_pxy.vtk
adding src of U_pxy
Adding the labels
reading label:  U_=_1.0_m/s@(0.68,0.04)s10x000000
reading label:  Start_up_U_high@(0.68,0.005)s10xAA0000
reading label:  Streamlines@(0.05,0.9)s10x000000
Writing images:
+++++++++++++++++++++ tme  0.005  +++++++++++++++++++++++++++++++++++++
updating: /home/meta/projects/cavityseries/cavity_U1.0_init1/PlanesVTK//0.005/U_pxy.vtk


kilroy October 17, 2013 17:26

I got it working. After upgrading to ParaView v4.0.1, the problem is solved. The code doesn't get stuck anymore.

eelcovv October 20, 2013 07:06

Hi Killroy,


Glad to hear that!

Eelco


All times are GMT -4. The time now is 05:47.