[Paraview] ParaViewWeb & TomCat

[Sebastien Jourdain]

Hi Chris,

I respond directly in your mail

> As a first cut, I think it would be fine to have the engines write out their data.  Andy can correct me if I'm wrong, but I think we could use the co-processing to write just the subset of geometry and field data that we want to display in the notebook. If I understand correctly, with that approach we could  then just focus on starting PWServer, reading in the data files, and setting up the communication between tornado and tomcat.

With that cut, you can definitely use ParaViewWeb as is and let a
JavaScript code start the PWServer for you. The only thing that you
have to provide is the path to that data file... And yes, you can do
from the co-processing dump the stripped version of the data to the
disk.

> For future reference, when we want to move beyond dumping the data, here is how each engine is connected to paraview: A module called vtkViewers has been imported by each python engine and executed the following code:
>
> from paraview import servermanager
> global globalController, newGlobalController
> paraview.options.batch = True
> paraview.options.symmetric = True
> pm = servermanager.vtkProcessModule.GetProcessModule()
> globalController = pm.GetGlobalController()
> ...
>
> In addition to this bit, each engine has attached it's mesh and field data arrays to the proper VTK containers and set up a parallel visualization pipeline.  It can potentially also read in a co-processing script to set up additional visualization.  I was hoping that this setup would eventually allow us to start a PWServer and attach it to the pvserver which is directly connected to the VTK objects in memory on each engines.

This is kind of possible by starting pvserver in collaborative mode
and have the PWSever connecting to that running pvserver in the same
time as your python engine.

>> - On the ParaViewWeb side (tomcat web app) you will have to patch the
>> code so it won't prevent you to connect to a process that was not
>> started by itself. (I can help you with that, it should be pretty
>> simple)
>
> Thanks, that would be very helpful.

This will only be needed if you need to start PWServer from python,
but if you dump the data somewhere you won't need it at all.

> I'll look into that. I'm going to visit the IPython notebook developers next week and can get some help on working with tornado. I think it will help if I can get the standard ParaViewWeb setup working.

Sure just let me know if you are running into issues...

>> PS: For your later mail did you get the source form here
>> (http://paraview.org/ParaViewWeb.git) which is not github ?
>
> Yes, sorry, I got it from paraview.org.

ok, good I was scared that you pick an old version on the web before
we get our git repo setup...

> Somewhere on the list somebody mentioned upgrading to activemq 3.4 so I did too. I should only need activemq cpp libs, paraview, and PW server to successfully build and make tests, right?

Yes

Normally with the latest version in the repository you should use the
current (latest) stable version of activemq-cpp without any issue.
Maybe the documentation is slightly off regarding that part.
Then the make test is not really needed in fact, you should just make
sure that when you start PWServer it is not segfaulting... Other than
that you should setup the WORKING_DIR and the TOMCAT_HOME to allow the
deploy of the application. Once it's done, just do "make; make
deploy", then make sure activemq is started and start tomcat.

Look at the tomcat log once you connect to any sample ParaViewWeb
application to make sure you don;t get any exception. On top of that
if it is not working, double check the logs that are in the
WORKING_DIR/logs. And come back to the paraviewweb mailing list...

When you stop tomcat, make sure it properly did before restarting it.
(ps aux | grep java | grep tomcat)

Seb