post-processing on an arbitrary plane

Questions and remarks about code_saturne usage
Forum rules
Please read the forum usage recommendations before posting.
Post Reply
sirlb
Posts: 34
Joined: Mon Mar 17, 2014 11:54 am

post-processing on an arbitrary plane

Post by sirlb »

Hello,

I am looking for a way to define arbitrary 2D mesh (a plane) used for local post-processing during computation (using a writer that would output every n time step).

Is there a way to make such a post-process operation ?

The idea is to import a mesh or to define a plane given bounds and discretization step, make interpolation of chosen variables on the plane points, output the results in ensight format using a writer.

Is there any guideline to do this ?
Yvan Fournier
Posts: 4208
Joined: Mon Feb 20, 2012 3:25 pm

Re: post-processing on an arbitrary plane

Post by Yvan Fournier »

Hello,

How "arbitrary" is your 2D mesh ?

If your mesh is built in such a manner that interior faces are aligned with that plane, than you can simply define a postprocessing mesh built of interior faces. As there is no automatic interpolation of variables for interior faces, you will need to use the cs_user_postprocess_var.f90 user file to interpolate and output variables (the file already contains examples you can start with).

If your mesh is not aligned with the plane, or you want a specific regular output grid spacing which is not the same as the computational mesh, things are more complex.

You could define a mesh of points in cs_user_postprocess_mesh(), but would need to manually create it using functions from the fvm_nodal_... functions (in src/fvm), and again use cs_coupling and / or fvm_locator functions to handle this, which is quite involved (I plan to re-write probes and profiles handling in a few months, so having a 2d extension of a profile would be easy, but it won't be available before a few months...).

You always have the option of using a similar operation as above, but choosing the cells (and not faces) containing the plane (using the "box[...]" selection criterion). This reduces the output volume, and you can then apply a clip operator "post-mortem" with EnSight, ParaView, or VisIt.

A last solution is to use co-processing with ParaView/Catalyst, but is more experimental, and requires version 3.2 at minimum.

Best regards,

Yvan
sirlb
Posts: 34
Joined: Mon Mar 17, 2014 11:54 am

Re: post-processing on an arbitrary plane

Post by sirlb »

Thank you for your reply.
If your mesh is not aligned with the plane, or you want a specific regular output grid spacing which is not the same as the computational mesh
Yes that is what i was looking for. But reading your reply, i guess this is too much complex for me and I will instead use the solution you mentioned after :
You always have the option of using a similar operation as above, but choosing the cells (and not faces) containing the plane (using the "box[...]" selection criterion)
For the moment, I guess this will fit my needs to reduce post-processing tasks i/o.

For the co-processing, I read the interesting article : http://visu2013.imag.fr/talks/scivis_slot1.pdf
But I guess installation of Catalyst and compilation of cs with support for co-processing are handy tasks and I don't really have time to dig into it right now.

Best Regards,
sirlb
Posts: 34
Joined: Mon Mar 17, 2014 11:54 am

Re: post-processing on an arbitrary plane

Post by sirlb »

Hello,
I finally gave a try to Catalyst on a simple case.
I compiled catalyst and recompile cs 3.2.1 with catalyst support.
After a few tricks it finally compile well.

When trying to use i had the following error :

Code: Select all

Error: Could not import vtkCommonComputationalGeometryPython
Error: Could not import vtkCommonMiscPython
Error: Could not import vtkCommonSystemPython
Error: Could not import vtkRenderingCorePython
Error: Cannot import vtkPVServerManagerDefaultPython
Error: Cannot import vtkPVServerManagerRenderingPython
Error: Cannot import vtkPVServerManagerApplicationPython
Traceback (most recent call last):
  File "<string>", line 2, in <module>
  File "runtimepp.py", line 3, in <module>
    except: from paraview.simple import *
  File "/opt/code_saturne/ThirdParty/catalyst/lib/site-packages/paraview/simple.py", line 42, in <module>
    import lookuptable
  File "/opt/code_saturne/ThirdParty/catalyst/lib/site-packages/paraview/lookuptable.py", line 23, in <module>
    from math import sqrt
ImportError: /usr/lib64/python2.7/lib-dynload/math.so: undefined symbol: PyFloat_Type
stack trace is :

Code: Select all

Computing geometric quantities (0.344 s)
Signal SIGSEGV (accès à une zone mémoire interdite) intercepté !

Pile d'appels :
   1: 0x7fd8d37f6cb0 <+0x35cb0>                       (libc.so.6)
   2: 0x7fd8c4d0d5f5 <_ZN20vtkDataArrayTemplateIfE8SetTupleExPKf+0xe5> (libvtkCommonCore-pv4.1.so.1)
   3: 0x7fd8ca16902f <_ZN9vtkPoints15InsertNextPointEddd+0x5b> (fvm_catalyst.so)
   4: 0x7fd8ca16744e <+0x344e>                        (fvm_catalyst.so)
   5: 0x7fd8ca16889a <fvm_to_catalyst_export_nodal+0x9d> (fvm_catalyst.so)
   6: 0x7fd8d5f22af0 <fvm_writer_export_nodal+0xc8>   (libsaturne.so.0)
   7: 0x7fd8d6068b6b <+0x1b1b6b>                      (libsaturne.so.0)
   8: 0x7fd8d606e3e9 <cs_post_init_meshes+0x36d>      (libsaturne.so.0)
   9: 0x7fd8d5f18160 <cs_run+0x218>                   (libsaturne.so.0)
  10: 0x7fd8d5f1853c <main+0x15d>                     (libsaturne.so.0)
  11: 0x7fd8d37e2d65 <__libc_start_main+0xf5>         (libc.so.6)
  12: 0x402a79     <>                               (cs_solver)
My system is Fedora 20 64bits.

Do you have any idea what is the problem ?
Yvan Fournier
Posts: 4208
Joined: Mon Feb 20, 2012 3:25 pm

Re: post-processing on an arbitrary plane

Post by Yvan Fournier »

Hello,

I have also encountered the "import" errors on recent ParaView builds (not on builds with older ParaView versions).

To work around these errors, you need to add some LD_LIBRARY_PATH values (and possibly a PYTHONPATH value). I'm in the process of regenerating our builds (due to server path changes), so I can't check immediately, but adding:

export PYTHONPATH=<paraview_install_prefix>/lib/paraview-4.1/site-packages:$PYTHONPATH
export LD_LIBRARY_PATH=<paraview_install_prefix>/lib/paraview-4.1:$LD_LIBRARY_PATH

to you runcase should remove part of your issues. If it does not, try subdirectories of those paths

Regards,

Yvan
Post Reply