[Paraview] Python interpreter not being created for coprocessing?

[Vanmoer, Mark W]

Right, single process. I'm working with one code that's all CPU and another that's mixed CPU/GPU. Coprocessing works well for both. There's also MPI versions of the codes that I'm trying to instrument.

The computational mesh is completely regular so I've been using vtkImageData. The MPI versions split the mesh over the ranks. When I run an MPI version with  -np > 1, then I get the following for each process:
ERROR: In /home/mvanmoer/builds/ParaView/ParaView-3.14.1-Source/ParaViewCore/VTKExtensions/vtkKdTreeGenerator.cxx, line 168
vtkKdTreeGenerator (0x5ac6430): RegionIDs cannot be 0.

It doesn't crash, but it gives an incorrect image. I'll look through your updated tutorials, I'd been looking through the SC10 slides.

Mark

From: Andy Bauer [mailto:andy.bauer at kitware.com]
Sent: Tuesday, September 25, 2012 2:15 PM
To: Vanmoer, Mark W
Cc: paraview at paraview.org
Subject: Re: [Paraview] Python interpreter not being created for coprocessing?


On Tue, Sep 25, 2012 at 12:21 PM, Vanmoer, Mark W <mvanmoer at illinois.edu<mailto:mvanmoer at illinois.edu>> wrote:
I pulled it directly from stage/13460_CP_FortranAdaptor.

Great, then it was me after all that fixed it!


I'm now at the point where it runs great on a single node with GPUs, I'm trying to extend it to multiple nodes, which I think involves setting up vtkMultiBlockDataSets? I was going to look through the NPICAdaptor for hints on that.

By single node I'm assuming that you mean a single process, correct? What's the type of grid that you're planning on using? The PhastaAdaptor is an example of dealing with an unstructured grid. I also just updated the coprocessing tutorials page (now at http://paraview.org/Wiki/Coprocessing_Tutorials) to include the tutorial I'll be doing at SC12. It should have some useful information for doing this. You could just do a polydata input, just set the center of the sphere source in your example based on the process rank (e.g. Sphere->SetCenter(10*rank, 0, 0); ) so that it's easy to tell the difference between each processes input part/domain partition.

Andy


Mark


From: Andy Bauer [mailto:andy.bauer at kitware.com<mailto:andy.bauer at kitware.com>]
Sent: Tuesday, September 25, 2012 10:13 AM

To: Vanmoer, Mark W
Cc: paraview at paraview.org<mailto:paraview at paraview.org>
Subject: Re: [Paraview] Python interpreter not being created for coprocessing?

Did you get my changes from ParaView's stage branch? My changes didn't make it into ParaView master yet so I'm not sure what changed that caused things to work now. Well, if it's working I'm glad -- I'm not sure I can personally take credit for it though :)

Let me know how it goes with the GPU stuff.

Andy
On Mon, Sep 24, 2012 at 5:48 PM, Vanmoer, Mark W <mvanmoer at illinois.edu<mailto:mvanmoer at illinois.edu>> wrote:
Hi Andy,

I've tested this and it works with both gcc/mpich2 and pgi/openmpi.

Thanks again!
Mark

From: Vanmoer, Mark W
Sent: Wednesday, September 19, 2012 1:30 PM
To: Andy Bauer
Cc: paraview at paraview.org<mailto:paraview at paraview.org>
Subject: RE: [Paraview] Python interpreter not being created for coprocessing?

Hi Andy, that sounds like some deep debugging, thanks for your effort. I'll test this and let you know. It's on my to do list to learn CMake, I've had the book on my desk for a month now.

Also, I made another Fortran example that's closer in spirit to the wiki example, which uses the DataGenerator class as the C++ does, if you're interested.

Thanks,
Mark
________________________________
From: Andy Bauer
Sent: 9/19/2012 1:12 PM
To: Vanmoer, Mark W
Cc: paraview at paraview.org<mailto:paraview at paraview.org>
Subject: Re: [Paraview] Python interpreter not being created for coprocessing?
Hi Mark,

I finally got around to fixing this. It's in the stage branch (remotes/stage/13460_CP_FortranAdaptor) and hopefully will go into the master branch on the next gatekeeper review. There were 2 issues fixed in this:
1) for using newer GCC compilers and other compilers that hide symbols in the library (http://gcc.gnu.org/wiki/Visibility) the FortranAdaptor API methods weren't available to other libraries and executables trying to link to them.
2) Since 3.14.1 I changed around the way ParaView gets initialized through the coprocessing library (now through vtkCPProcessor::Initialize() as it should be instead of vtkCPPythonScriptPipeline::Initialize()). I forgot to make the change in the FortranAdaptorAPI.cxx which caused the python interpretor to not be initialized properly, as you noticed.

Thanks for the help in finding this problem. Sorry for the slow response on it. I created a CMakeLists.txt file to help build as I've been using CMake too long and can't remember how to work with Makefiles anymore! I'm attaching it in case you'd like to use it. I didn't test it with an install of ParaView as I really only work directly with ParaView builds.

Let me know if this solves your problems. I seem to remember there being more as far as using CUDA and PGI but hopefully this gets you close.

By the way, I'll probably use what you sent me to create a Fortran test or example to help with making sure it doesn't get broken in the future.

Andy
On Wed, Sep 12, 2012 at 4:42 PM, Vanmoer, Mark W <mvanmoer at illinois.edu<mailto:mvanmoer at illinois.edu>> wrote:
Tarball attached, it's not exactly the wiki example because I didn't want to bother with passing a DataGenerator object back and forth from C++ to Fortran, so I just make a sphere. The pipeline script is a shrink filter generated by pvclient.

I checked CMake and it looks like it's finding the same version of python.
Mark

From: Andy Bauer [mailto:andy.bauer at kitware.com<mailto:andy.bauer at kitware.com>]
Sent: Wednesday, September 12, 2012 1:02 PM

To: Vanmoer, Mark W
Cc: paraview at paraview.org<mailto:paraview at paraview.org>
Subject: Re: [Paraview] Python interpreter not being created for coprocessing?

Can you send me your Fortran version of the wiki example?