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 ?
post-processing on an arbitrary plane
Forum rules
Please read the forum usage recommendations before posting.
Please read the forum usage recommendations before posting.
-
- Posts: 4208
- Joined: Mon Feb 20, 2012 3:25 pm
Re: post-processing on an arbitrary plane
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
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
Re: post-processing on an arbitrary plane
Thank you for your reply.
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,
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 :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
For the moment, I guess this will fit my needs to reduce post-processing tasks i/o.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 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,
Re: post-processing on an arbitrary plane
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 :
stack trace is :
My system is Fedora 20 64bits.
Do you have any idea what is the problem ?
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
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)
Do you have any idea what is the problem ?
-
- Posts: 4208
- Joined: Mon Feb 20, 2012 3:25 pm
Re: post-processing on an arbitrary plane
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
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