[openfoammaofnepo]

Dear Eelco,

Your thread is very useful. I am also trying to use paraview in batch. In my case, the "in batch" means repeating the same actions for numerous time steps. I can use Track to get the script for one time step, but I do not how to add the time looping so that I can run the script to get the results what I want for all the time instants.

Could you please say something about how did you do that? Thank you very much for your help.

OFFO

[Phil_]

Hi Eelcow,

I tried using your nifty tool with ParaView 4.1.0 but it tells me "Could not determine any reader".

Am I doing something wrong or is it not compatible with this ParaView version?

    pvbatch pvbatchprocess.py --casedir case1 --statefile state1.pvsm

Philip

[Phil_]

Okay I just figured it out:

It didn't work, because I created the state file (.pvsm) with ParaFoam and not ParaView.
I just changed the following line in the pvbatchprocess.py to search for ".OpenFOAM" instead of ".foam"

       #m=re.search('(/.*/)(.*).foam',line,re.M)
        m=re.search('(/.*/)(.*).OpenFOAM',line,re.M)

Thanks for this nice tool!

Philip

[eelcovv]

Hi Phil,

Good to hear that you got it working. It is a bit a hack this script and mainly for my personal use, so these small things need modification indeed if you want to use it yourself

I have made some improvements to the script which I would like to share.

The change is mainly related to making plots of sample planes you made with the sampling plane routine during an openfoam run.
Previously I always wrote planes in vtk format, but in fact these are really in efficient in terms on storage: each individual vtk file contains the location of each point in the plane (x,y,z) and the value your store, for instance T. But the x,y,z remains the same for all the files, so you duplicate a lot of information. The x,y,z is duplicated and only the T changes per time step, so only 25% of the information in the file is used.

Much more efficient is to write you sample planes in ensight format (the format description in you sample planes dict should be set to ensight in stead of vtk). In this way the mesh file (x,y,z) and the data file (T) are written in seperate files, which allows you to replace all the mesh file with a symbolic link to the first mesh file and only keep the the T file. This step already reduces 75% of your stored data. If you also zip the T file, you can reduce the stored data with about 90%! Really significant. After a run I sometimes have generated more than 40Gb of sample plane data, which I can reduces to less then 2Gb

In the pvbatchcollection you will find an update pvbatchproces script which can read the gzipped ensight files. The procedure is the same as I have written above. In principle you can use the pvbatchprocess.py calling with
pvbatch, but I generally use the pvbatchprocess.pl script to generate a list of call of all the cases and state file which you can defin in the pvcases.dat file (an example is included).

In order to create the symbolic links of the ensight file and compress them you can use the new script call clearEnsightPlanes.py

The most straightforward call is to do

clearEnsightPlanes.py <directoryWithTheTimedirectoriesContainTheEnsightP lanes>

This should replace all the mesh files with a symbolic link to the first time direcotory and after that zip all the data files.

The latest version of pvbatchprocess.py contains also some bug fixes. Especially it includes a fix in case you have two legends. It is actually a bug in paraview: if you save a state file with two scalar bars and replot it, the location of the legend is messed up'; they are plotted on top of each other. In my script I now fix the state file and restore the correct location of the scalar bars.

Well, it is quite a hack and I don't have time to write user manuals on the script, but it should work quite straightforward I hope. Otherwise just browse the code to see what it does. I am not working with OpenFoam currently, so I am not at this forum anymore, so forgive the silence from my side. Good luck with scripts anyway, I found them very useful myself!

Eelco

[Phil_]

Hi Eelco,

thank you for the updated version

I didn't try the new features yet, but it's still working for taking snapshots.

I made a few changes in order to get it to work on my system:

1. In pvbatchprocess.pl the first line had to be changed from

#!/bin/env perl

to

#!/usr/bin/env perl

2. The path to pvbatch.py had to be exported so the script can locate it (it is using "which" to locate pvbatch.py).

3. In addition I removed the "1" after "CASE" and "STATE" in pvbatchprocess.pl, because I found it more convenient to number the cases and states in the pvcases.dat instead of naming them all "CASE 1" and "STATE 1"

#if(/^#\s*CASE 1(.*$)/)
 if(/^#\s*CASE(.*$)/)

Example: In order to make snapshots from time 1410, 1415, 1520, 1425 with a white background and a resolution of 1400x800 the syntax is:

./pvbatchpreprocess.pl --timerange 1410:1425:5 pvcases.dat --background FFFFFF --viewsize 1400,800

[eelcovv]

Hi Phil,

good to here some people are actually using it
You should indeed alter the env location according to you system, it was developped for my own use, so I did not create a configuration script for it

About the CASE 1 and STATE 0: The number is not used for naming your images, the name is extracted from idear the case name of the next field 'name'. The 1 or 0 zero only used to be able to quickly deactivate a case or a state: it is only processed on you have a 1, otherwise it is 0. In your version it will always process all the cases and states defined in you pvcases.dat file.

Anyway, good luck with it! I recommend to look at the ensight data plane options together with the clearEnsightPlanes script, I found this really useful. In fact, the clearEnsight script can also be called using a function_object system call during your run, so that the amount of generated data can be kept as low as possible during your run. Especially important if you have not to much disk space available

Eelco

[Phil_]

Hi Eelco,

so that's what the 0's and 1's are for Now it makes sense

Thank's for the hint!

Philip

[eelcovv]

By the way, you are using pvbatchpreprocess.pl. I am not sure if you realise it, but this tool is only needed if you want to run multiple pvbatch jobs at the same time, on either you one multicore computer, or either on a cluster. It basically split your given -timerange into -nint parts, and for each time section it will make a call to pvbatchprocess.pl. Then pvbatchprocess.py is launched either on you local computer or on cluster (depending on the cluster option). If you use -offscreen it will use the cpu rendering, but for that you need to have compiled paraview with the mesa libraries.

In case you are not interested in splitting your time domain (because you do not have many timesteps or don't have a multicore computer), you can just use pvbatchprocess.pl at once. This will only make one call for each CASE/STATE combination to pvbatchprocess.py. You can even choose to do this one after the other (if you can only run one paraview job at the time because of memory limitations) or all at the same time.

So the pvbatchpreprocess can be really handy if you want to process many files (on our cluster I have run more than 80 pvbatch jobs at the same time, creating about 900 frames in only 10 min or so), but more often for small tests or less time frames it is more convinient to use the pvbatchprocess.pl at once.

Anyway, I was not sure if that was clear. Should write a manual one day I guess;-)

[roenby]

Dear Eelco van Vliet

Just stumpled upon your script and got it to work after a little trial and error. I have been wanting to get something like your script for ages. Last year excessive manual paraview figure generation cost me severe problems and pain in my back and hand.

So from the bottom of my heart: Thank you for this very useful script.

All the best,
Johan Roenby

Ps: Would you consider putting it into a github repo to avoid all the zip uploads to cfd-online and maybe to allow others to improve on it?