Hi Pat,<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Maybe you could back up a bit and explain what you're trying to accomplish? Maybe we can suggest another approach that will work while avoiding the incompatibilities vtk version requirements of dolfin and paraview.<br>
</blockquote><div><br>Of course! Apologies that I didn't explain this in more detail before (I didn't consider it relavant for the bug in question).<br><br>Here is some background on my question. In our group we are using the FEniCS [1] package as the basis for our finite element-based simulation framework. We have quite a bit of Python code on top of it and it works very well, but visualisation support in FEniCS is quite limited. Thus I usually use Paraview for visualisations because it does a great job, and apart from being flexible and fast it produces really nice-looking images. :)<br>
<br>However, I do most of my work in IPython notebooks, or alternatively run a python script which perform lots of simulations with different parameters (for each of which I'd like to be able to quicky produce a rough visual overview over the results). In either use case it is awkward (or even impossible) to do manual visualisations by opening the Paraview GUI for each simulation performed, saving the image and putting it in the appropriate directory (where the IPython notebook can find and display it and/or where it is under version control). Apart from taking much longer than an automated solution, it also makes version controlling my results harder and automatic reproducibility nearly impossible.<br>
<br>Thus I wrote an auxiliary function which uses Paraview's Python scripting interface and provides a flexible way of plotting the outcome of a simulation from within a Python script or an IPython notebook. This works nicely, except when Paraview crashes due to the mentioned vtk conflict. :-S<br>
<br>So that's the background situation. I personally wouldn't mind using the workaround you mentioned (namely, importing the paraview module before everything else). I actually tried this, and it appeared to work for a little while. However, the problem is that our package is used by a number of people, and it is common for simulation scripts to import a few frequently used python modules. These include the dolfin module (which is part of the FEniCS distribution), but dolfin internally imports the vtk module, so this will trigger the segfault if dolfin is imported before our own package.<br>
<br>Thus if a user writes a script which starts like this:<br><br> ==><br> import dolfin<br> import our_software<br><br> # run some simulations<br> <==<br><br>then (s)he will get a segfault for no apparent reason. But the same script will work fine if the order of the imports is reversed. Since we cannot (and do not want to) control the order in which our users import python modules, this currently makes it impossible to use Paraview for visualisations from within our software. Which is a real shame because it seems to be by far the best solution for the job.<br>
<br>I hope this makes it clearer what the problem is. Any suggestions how to deal with it would be much appreciated. You also mentioned pvpython. I have not worked with it yet, but it seems to be a custom Python interpreter which somehow incorporates the Paraview plotting functionality? I suppose that using it as the main way of running our visualisation code isn't an option because we do not want to enforce Paraview as a dependency on our users (moreover, since the visualisation part is actually just a tiny piece of convenience functionality, it would be rather unintuitive to run our simulation scripts by having to call pvpython instead of the regular python or ipython interpreter). However, if it was possible to somehow hook pvpython into our code only during plotting, this might be a solution. Any suggestions how to do this?<br>
<br>Actually, it just occurred to me that I may be able to work around the crash by calling the code that depends on Paraview via the subprocess module [2] (or something similar). This could potentially avoid the conflict between the different vtk modules (and thus the segfault), even if users import dolfin at the beginning of their scripts. I'll investigate whether this works shortly. Even if it does, any suggestions for a more elegant solution would still be welcome. Also, I can't imagine that we're the only ones running into an 'implicit' conflict between paraview and some other software that uses vtk. So a more general/portable solution would certainly be preferrable.<br>
<br>Apologies for this long email and thanks again for your patience and help!<br><br>Best regards,<br>Max<br><br>[1] <a href="http://fenicsproject.org/">http://fenicsproject.org/</a><br>[2] <a href="http://docs.python.org/2/library/subprocess.html">http://docs.python.org/2/library/subprocess.html</a><br>
</div></div><br>