next up previous contents
Next: Running Gerris Up: The Gerris FAQ Previous: Representation of solid boundaries   Contents

Post-processing and Visualisation

Is there a way to view the results and solid(s) at the same time (with the solid in the correct location? (Geomview question)

Yes, you need to select the Inspect $ \rightarrow$ mathend000#Appearance $ \rightarrow$ mathend000#Normalise $ \rightarrow$ mathend000#None option in the Geomview menu. The default is to ``normalise'' (i.e. rescale) each object individually (Normalise $ \rightarrow$ mathend000#Individual option) so that it fits at the centre of the viewed area.

Is there any way to output U, V, W, P, etc...at point (X, Y, Z) in the flow field?

Yes, use

GfsOutputLocation { step = 1 } data -0.209371 -0.0166124 -0.449834
where the last three numbers are the x, y, z mathend000# coordinates of the location where you want the values of the variables or
GfsOutputLocation { step = 1 } data positions
where positions is a file containing newline-separated coordinates.

The file data will contain the data as described in the first line of the file, a ``comment'' line starting with #.

Where is the description of the format of the data section of saved simulation files?

If you intend to read the simulation files (to convert them or do other operations/calculations etc...) I would highly recommend that you do so through the functions provided by the Gerris library (gfs_simulation_read() and so on). This way you will not reinvent the wheel and you will be able to use all the functionalities provided by the library (traversal of the octree structure, computation of gradients, interpolations etc...). This would also ensure that your code is independent of the format changes in the simulation file.

Just to give you an example on how this can bite you:

the GfsOutputSimulation object can be used like this (in simulation files)

  GfsOutputSimulation { step = 0.1 } sim-%3.1f { variables = P,C }
in this case, the simulations files (sim-0.1, sim-0.2 etc...) will only contain the P and C variables.

Your code which reads the simulation files would need to know about this. The gfs_simulation_read() function deals with that for you and other functions give you easy access to this kind of information (what variables where contained in the simulation file etc...)

How do I compute/display the vorticity field with OpenDX?

The DivCurl tool in OpenDX works for general grids. You can use it to compute the vorticity (vector) from the U field returned by GfsImport, however this will work only for 3D fields.

The GfsOutputSimulation and GfsOutputLocation files only place up to eight decimals. Is there any way to increase the number of decimal places?

Good question. No there isn't, short of editing and recompiling the source code. That would be a nice option to have in the simulation file.

I would like a time-averaged velocity profile, Would I have to specify a number of monitoring points at different heights, or is there a method to time average over a line through the solution domain?

There is no method to do line averaging at the moment, however there is a method which averages (or more exactly stores the sum) of a given variable in time over the whole domain. You can do it like that:

 
  EventSum { start = 1 istep = 1 } U SUx
  EventSum { start = 1 istep = 1 } V SUy
  EventSum { start = 1 istep = 1 } W SUz
  EventSum { start = 1 istep = 1 } U*U SU2x
  EventSum { start = 1 istep = 1 } V*V SU2y
  EventSum { start = 1 istep = 1 } W*W SU2z
  OutputSimulation { start = end } simulation-sum { 
    variables = SUx,SUy,SUz,SU2x,SU2y,SU2z
  }
which would add U to SUx at every timestep (istep = 1) starting from time 1 (start = 1) etc...and U*U to SU2x at every timestep etc...The resulting sums are then written at the end of the simulation in the file simulation-sum. This file can then be post-processed (using gfs2oogl for example) to obtain averages, standard deviations etc...(along any curves you want of course).

Using animate, the sequence of images generated by OutputPPM looks weird, what's happening?

This is probably an artefact of the way the animate command displays a series of PPM images. What happens is that OutputPPM generates PPM images which are just big enough to contain all the data in your simulation e.g. if you use 7 levels of refinement and one box, OutputPPM will generate images with 128 x 128 mathend000# pixels. If you use an adaptive resolution with a maximum level of 6, the size of the resulting image generated by OutputPPM can be anything in 1 x 1 mathend000#, 2 x 2 mathend000#, 4 x 4 mathend000#, 8 x 8 mathend000#, 16 x 16 mathend000#, 32 x 32 mathend000#, 64 x 64 mathend000# depending on the maximum number of levels necessary to verify your adaptation criterion. As a result, animate can see a series of PPM images with a variable size, if you look carefully you will see that the weird patterns you see are smaller-size images of your simulation, displayed in the top-left corner of the initial image. What animate should really do is blank out the previous larger image before displaying the smaller image, to make the difference in size clear.

The solution is simple, you can set the size of the images generated by OutputPPM using:

OutputPPM { step = 0.05 } tracer.ppm { v = T maxlevel = 6 }
which will result in PPM images of size 64 x 64 mathend000#, independently of the maximum level of refinement in the simulation.

Why create a new visualisation tool like GfsView? Can't you use existing tools like Mayavi/VTK, OpenDX etc...?

Most visualisation packages assume that the data is defined on either structured Cartesian meshes (this includes curvilinear coordinates) or fully unstructured meshes (tetrahedra etc...).

The octrees used by Gerris need first to be converted into unstructured tetrahedra and then imported into OpenDX etc...This is quite slow and memory-hungry and loses most of the advantages of the octree: in particular the multilevel representation of the solution is very useful from a visualisation point of view.

I am not aware of any good visualisation tool which understands octrees. It would be a good idea to post messages on OpenDX, Mayavi, VTK etc...mailing lists asking about support for octrees. I did that and got little feed back, but more messages would show the developers of these projects that there is a desire for such a feature.

GfsView makes the most of the octree structure to accelerate visualisation, computation of isosurfaces etc...



Subsections
next up previous contents
Next: Running Gerris Up: The Gerris FAQ Previous: Representation of solid boundaries   Contents