[Paraview] ParaViewWeb

[Sebastien Jourdain]

Hi Ben,

So ParaViewWeb is not using the iPython network channel.
In fact, the interpreter of iPython is used via another thread for
ParaViewWeb to start its own web server. And the iFrame just connect to
that other web server port.

But you could come up with a different setup, where you ask iPython to
remotely start a ParaViewWeb process (not in the same interpreter and not
in parallel) and rely on an Apache on the front to mix the 2 web contents
into the same domain using https.

Then you use an iframe to connect to the freshly ParaviewWeb process,
started by you.

I know it is confusing but there is so much ways to setup your environment
to have something working that we can not document them all. It is really
depending on what you tried to achieve.
For instance, in the explained used case, we target live in-situ
visualization of data computed by the MPI iPython engines where we want to
share the data in-memory between iPython and ParaViewWeb.

I'm not sure that I managed to help you out, but hopefully I helped you
understand it a little bit more. ;-)

Seb


On Mon, Feb 10, 2014 at 11:31 AM, Ben Bales <bbbales2 at gmail.com> wrote:

> Oh! So I didn't realize that example was sharing data between IPython and
> Paraview.
>
> I wasn't able to get it to work (some vtk import errors), but when I saw
> the <iframe> I just got excited and stole that little bit of code out :D,
> so maybe I did things wrong.
>
> I just had a closer look, and is that example running traffic through the
> IPython web connections?
>
> Let me draw some diagrams (convert this to a monospaced font if it isn't
> :D)
>
> I -> IPython
> P -> Paraview
> S -> Secure layer
> U -> User
>
> When I have the two servers running separately, and just include an iframe
> from one to another, I am doing:
>
> I--------->U
> P--------->U
>
> What I was asking about doing in the last e-mail was:
>
> I----->S---->U
> P--/
>
> (Where IPython and Paraview both go through the same secure layer). You
> say this is something I can set up with Apache, right? When I look at a
> system like this, I get scared of rewriting stuff. How does U know to ask S
> to route data to P? Is that what this documentation describes:
> http://www.paraview.org/ParaView3/Doc/Nightly/www/js-doc/index.html#!/guide/apache_setup
> ?
>
> Now I've had a closer look at the script here (
> http://www.paraview.org/ParaView3/Doc/Nightly/www/js-doc/index.html#!/guide/ipython),
> and I'm wondering, does the Paraview server there use the IPython
> communication channels?
>
> P---->I---->U
>
> In which case I could just:
>
> P---->I---->S---->U
>
> Sorry if I'm being a dunce here! This web technology can get complex :D!
>
> Thanks,
> Ben
>
>
> On Mon, Feb 10, 2014 at 8:12 AM, Sebastien Jourdain <
> sebastien.jourdain at kitware.com> wrote:
>
>> Hi Ben,
>>
>> there is several ways to integrate ParaViewWeb into iPython and the
>> documentation highlight a distributed/in-situ one. (Which is by far the
>> less obvious one ;-)
>> In fact, if you are not expecting ParaViewWeb to use directly the
>> in-memory objects of your iPython MPI engines, you might just deploy a
>> ParaViewWeb on the side which will naturally allow you to also have it
>> embedded inside your iPython integration.
>>
>> For that you will need an apache on the front to do the relay in
>> https/wss. This should solve the security error.
>>
>> Regarding the overhead of the server side rendering, we did not wrote any
>> specific analysis or documentation.
>> Do you still have render calls when you switch to WebGL on the client
>> side? Do you have them when you interact with the scene? If so, you can
>> adjust the JS of the WebVisualizer and disable the camera synchronization
>> of the WebGL renderer, which will prevent the client to send camera update
>> to the server. But if you do so, if your data change, your view will revert
>> back to the original server side camera position.
>>
>> Hope that helped you in some ways,
>>
>> Seb
>>
>>
>> On Sat, Feb 8, 2014 at 4:10 PM, Ben Bales <bbbales2 at gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I have two questions concerning ParaViewWeb.
>>>
>>> 1. I want to embed the ParaViewWeb visualizer in iPython. This page (
>>> http://www.paraview.org/ParaView3/Doc/Nightly/www/js-doc/index.html#!/guide/ipython) suggests
>>> the standard way of doing that is embedding an iframe that references a
>>> ParaViewWeb Visualizer instance.
>>>
>>> My iPython instances are handled over an https connection, so embedding
>>> an http iframe from a separate server will throw security errors in my
>>> browser.
>>>
>>> Is there any easy solution to get around this? I'd like to keep
>>> authentication on my servers, but I'd also really like to use the embedded
>>> Visualizer (cause it's super super cool :D)
>>>
>>> 2. Is there any documentation on the overhead of the server-side
>>> rendering for ParaViewWeb? I noticed by default Paraview still spawns an X
>>> renderer for every rendering that is happening on the client.
>>>
>>> Ideally I'd just like Paraview to not try to render stuff server-side,
>>> and the client just handle the drawing with WebGL, but I probably am
>>> missing some critical point about the paraview architecture.
>>>
>>> Thanks,
>>> Ben
>>>
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Please keep messages on-topic and check the ParaView Wiki at:
>>> http://paraview.org/Wiki/ParaView
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.paraview.org/mailman/listinfo/paraview
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.paraview.org/pipermail/paraview/attachments/20140210/a50129f3/attachment-0001.html>