Re: [Paraview] Memory leak with Catalyst

[Gallagher, Timothy P]

Well... not going so well.


If I run a small simulation with massif and the Release build of paraview, I 
don't see any growing memory in time. I also get my VTK files and images.


If I run the same simulation linked against a Debug build with VTK_DEBUG_LEAKS 
on, there is a segfault inside one of the libvtkRendering libraries (it says 
libvtkRenderingOp but the rest of the name is cut off). If I take the image 
rendering out of my pipeline (comment out the RegisterView call) and leave the 
VTK file writing, it runs fine and doesn't report any leaks. I tried to get the 
segfault to drop a core file, but it won't do it.


I'm thinking that there is an issue in the rendering part causing the leak. I 
have no idea what it could be though -- this is the 4.4.0 version, is anybody 
aware of any bug fixes between 4.4.0 and current versions that might be 
relevant?


Thanks for the help,


Tim





From: ParaView  on behalf of Gallagher, Timothy 
P 
Sent: Friday, May 20, 2016 4:17 PM
To: Burlen Loring; Andy Bauer
Cc: paraview@paraview.org
Subject: Re: [Paraview] Memory leak with Catalyst


Thanks for the advice Burlen -- I haven't used Massif before, so this is a good 
opportunity to give it a try.


The initialize/finalize each time approach doesn't work either. I am calling 
the Finalize() routine on the vtkCPProcessor class but then when it tries to 
initialize again, it throws:


Warning: In /data4/ParaView/VTK/Parallel/Core/vtkSocketController.cxx, line 50
vtkSocketController (0xa4342f0): Already initialized.


and then crashes. So, hopefully I can sort out the memory leak rather than 
trying to debug why a hacked fix doesn't work!


Tim



From: Burlen Loring 
Sent: Friday, May 20, 2016 3:46 PM
To: Gallagher, Timothy P; Andy Bauer
Cc: paraview@paraview.org
Subject: Re: [Paraview] Memory leak with Catalyst


VTK_DEBUG_LEAKS, although will catch some serious errors, will not catch all 
kinds of leaks. For example you can have leaks where data erroneously 
accumulates with each time step, but is deleted at program termination. 
VTK_DEBUG_LEAKS will not catch that kind of error. It's probably better to use 
massif to profile your code on a small one node run. There's an excellent tool 
called massif visualizer to aid in exploring the data generated.


$0.02

On 05/20/2016 11:56 AM, Gallagher, Timothy P wrote:

Hi Andy,


Thanks for the tips. I will get working on the VTK_DEBUG_LEAKS now and see what 
it turns up.


The initialize/finalize every time is definitely a hack and not for long-term 
use. But, sponsors want a report on Monday and we need to be able to visualize 
things for that -- the simulation is too big to write data files and 
post-process later. So I modified the code to do that for now until I can find 
a proper fix.


I'll let you know if I get stuck with the log file.


Thanks again,


Tim



From: Andy Bauer 
Sent: Friday, May 20, 2016 2:39 PM
To: Gallagher, Timothy P
Cc: paraview@paraview.org
Subject: Re: [Paraview] Memory leak with Catalyst

Hi Tim,

If you build Catalyst with VTK_DEBUG_LEAKS enabled it is pretty good at finding 
VTK objects that aren't deleted properly. You should be able to run this with a 
small amount of calls to Catalyst as well. If you try this and want help 
understanding the output (if an object like a vtkUnstructuredGrid is leaked it 
will often give a whole bunch of false leaks that the unstructured grid is just 
holding the references to), just share your output file and I can take a look 
at it to try and narrow down the culprit. That may be slightly easier to use 
than Valgrind.

Beyond this, you could maybe try the same run but without doing any Catalyst 
work to see what happens then. That may be a lot of compute cycles but I'm not 
sure how else to try and bisect where the memory leak is occurring.

Initializing and finalizing Catalyst every time you want output would probably 
work but I'd think there may be significant overhead doing it like this. Plus, 
it's not really solving the problem -- just avoiding it.

Best,
Andy


On Fri, May 20, 2016 at 12:57 PM, Gallagher, Timothy P 
> wrote:

Hi,


One of our users is running a very big simulation and writing out images of two 
slices (two different views) every 1000 iterations and writing out the data for 
the two slices (two different data writers) as VTK files every 5000 iterations. 
It is using Paraview 4.4.


After 21000 iterations, the simulation is killed because the memory on the 
compute nodes fills up. I usually know how to track down memory problems in our 
code using valgrind and related tools, but is that the right way to go to try 
and find this problem?


Are there any tips on 

Re: [Paraview] Memory leak with Catalyst

[Gallagher, Timothy P]

Thanks for the advice Burlen -- I haven't used Massif before, so this is a good 
opportunity to give it a try.


The initialize/finalize each time approach doesn't work either. I am calling 
the Finalize() routine on the vtkCPProcessor class but then when it tries to 
initialize again, it throws:


Warning: In /data4/ParaView/VTK/Parallel/Core/vtkSocketController.cxx, line 50
vtkSocketController (0xa4342f0): Already initialized.


and then crashes. So, hopefully I can sort out the memory leak rather than 
trying to debug why a hacked fix doesn't work!


Tim



From: Burlen Loring 
Sent: Friday, May 20, 2016 3:46 PM
To: Gallagher, Timothy P; Andy Bauer
Cc: paraview@paraview.org
Subject: Re: [Paraview] Memory leak with Catalyst


VTK_DEBUG_LEAKS, although will catch some serious errors, will not catch all 
kinds of leaks. For example you can have leaks where data erroneously 
accumulates with each time step, but is deleted at program termination. 
VTK_DEBUG_LEAKS will not catch that kind of error. It's probably better to use 
massif to profile your code on a small one node run. There's an excellent tool 
called massif visualizer to aid in exploring the data generated.


$0.02

On 05/20/2016 11:56 AM, Gallagher, Timothy P wrote:

Hi Andy,


Thanks for the tips. I will get working on the VTK_DEBUG_LEAKS now and see what 
it turns up.


The initialize/finalize every time is definitely a hack and not for long-term 
use. But, sponsors want a report on Monday and we need to be able to visualize 
things for that -- the simulation is too big to write data files and 
post-process later. So I modified the code to do that for now until I can find 
a proper fix.


I'll let you know if I get stuck with the log file.


Thanks again,


Tim



From: Andy Bauer 
Sent: Friday, May 20, 2016 2:39 PM
To: Gallagher, Timothy P
Cc: paraview@paraview.org
Subject: Re: [Paraview] Memory leak with Catalyst

Hi Tim,

If you build Catalyst with VTK_DEBUG_LEAKS enabled it is pretty good at finding 
VTK objects that aren't deleted properly. You should be able to run this with a 
small amount of calls to Catalyst as well. If you try this and want help 
understanding the output (if an object like a vtkUnstructuredGrid is leaked it 
will often give a whole bunch of false leaks that the unstructured grid is just 
holding the references to), just share your output file and I can take a look 
at it to try and narrow down the culprit. That may be slightly easier to use 
than Valgrind.

Beyond this, you could maybe try the same run but without doing any Catalyst 
work to see what happens then. That may be a lot of compute cycles but I'm not 
sure how else to try and bisect where the memory leak is occurring.

Initializing and finalizing Catalyst every time you want output would probably 
work but I'd think there may be significant overhead doing it like this. Plus, 
it's not really solving the problem -- just avoiding it.

Best,
Andy


On Fri, May 20, 2016 at 12:57 PM, Gallagher, Timothy P 
> wrote:

Hi,


One of our users is running a very big simulation and writing out images of two 
slices (two different views) every 1000 iterations and writing out the data for 
the two slices (two different data writers) as VTK files every 5000 iterations. 
It is using Paraview 4.4.


After 21000 iterations, the simulation is killed because the memory on the 
compute nodes fills up. I usually know how to track down memory problems in our 
code using valgrind and related tools, but is that the right way to go to try 
and find this problem?


Are there any tips on how to isolate where the problem may be? I don't know if 
it is in the adapter, or in paraview itself. Has anybody encountered problems 
with runaway memory using Catalyst in 4.4 when writing images or VTK files?


I know when we use pvpython to generate images and loop over many files, 
sometimes the memory also blows up and so we usually move the loop over the 
files outside the pvpython script and into a driver script that executes a new 
pvpython for each file. Is there a way to shut down/start up Catalyst each time 
it needs to write something? Is that advisable?


Thanks,


Tim

___
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

Search the list archives at:  
http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] Memory leak with Catalyst

[Burlen Loring]

VTK_DEBUG_LEAKS, although will catch some serious errors, will not catch 
all kinds of leaks. For example you can have leaks where data 
erroneously accumulates with each time step, but is deleted at program 
termination. VTK_DEBUG_LEAKS will not catch that kind of error. It's 
probably better to use massif to profile your code on a small one node 
run. There's an excellent tool called massif visualizer to aid in 
exploring the data generated.



$0.02


On 05/20/2016 11:56 AM, Gallagher, Timothy P wrote:


Hi Andy,


Thanks for the tips. I will get working on the VTK_DEBUG_LEAKS now and 
see what it turns up.



The initialize/finalize every time is definitely a hack and not for 
long-term use. But, sponsors want a report on Monday and we need to be 
able to visualize things for that -- the simulation is too big to 
write data files and post-process later. So I modified the code to do 
that for now until I can find a proper fix.



I'll let you know if I get stuck with the log file.


Thanks again,


Tim




*From:* Andy Bauer 
*Sent:* Friday, May 20, 2016 2:39 PM
*To:* Gallagher, Timothy P
*Cc:* paraview@paraview.org
*Subject:* Re: [Paraview] Memory leak with Catalyst
Hi Tim,

If you build Catalyst with VTK_DEBUG_LEAKS enabled it is pretty good 
at finding VTK objects that aren't deleted properly. You should be 
able to run this with a small amount of calls to Catalyst as well. If 
you try this and want help understanding the output (if an object like 
a vtkUnstructuredGrid is leaked it will often give a whole bunch of 
false leaks that the unstructured grid is just holding the references 
to), just share your output file and I can take a look at it to try 
and narrow down the culprit. That may be slightly easier to use than 
Valgrind.


Beyond this, you could maybe try the same run but without doing any 
Catalyst work to see what happens then. That may be a lot of compute 
cycles but I'm not sure how else to try and bisect where the memory 
leak is occurring.


Initializing and finalizing Catalyst every time you want output would 
probably work but I'd think there may be significant overhead doing it 
like this. Plus, it's not really solving the problem -- just avoiding it.


Best,
Andy


On Fri, May 20, 2016 at 12:57 PM, Gallagher, Timothy P 
> wrote:


Hi,


One of our users is running a very big simulation and writing out
images of two slices (two different views) every 1000 iterations
and writing out the data for the two slices (two different data
writers) as VTK files every 5000 iterations. It is using Paraview
4.4.


After 21000 iterations, the simulation is killed because the
memory on the compute nodes fills up. I usually know how to track
down memory problems in our code using valgrind and related tools,
but is that the right way to go to try and find this problem?


Are there any tips on how to isolate where the problem may be? I
don't know if it is in the adapter, or in paraview itself. Has
anybody encountered problems with runaway memory using Catalyst in
4.4 when writing images or VTK files?


I know when we use pvpython to generate images and loop over many
files, sometimes the memory also blows up and so we usually move
the loop over the files outside the pvpython script and into a
driver script that executes a new pvpython for each file. Is there
a way to shut down/start up Catalyst each time it needs to write
something? Is that advisable?


Thanks,


Tim


___
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 

Search the list archives at:
http://markmail.org/search/?q=ParaView


Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview




___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview


___
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: 

Re: [Paraview] Memory leak with Catalyst

[Gallagher, Timothy P]

Hi Andy,


Thanks for the tips. I will get working on the VTK_DEBUG_LEAKS now and see what 
it turns up.


The initialize/finalize every time is definitely a hack and not for long-term 
use. But, sponsors want a report on Monday and we need to be able to visualize 
things for that -- the simulation is too big to write data files and 
post-process later. So I modified the code to do that for now until I can find 
a proper fix.


I'll let you know if I get stuck with the log file.


Thanks again,


Tim



From: Andy Bauer 
Sent: Friday, May 20, 2016 2:39 PM
To: Gallagher, Timothy P
Cc: paraview@paraview.org
Subject: Re: [Paraview] Memory leak with Catalyst

Hi Tim,

If you build Catalyst with VTK_DEBUG_LEAKS enabled it is pretty good at finding 
VTK objects that aren't deleted properly. You should be able to run this with a 
small amount of calls to Catalyst as well. If you try this and want help 
understanding the output (if an object like a vtkUnstructuredGrid is leaked it 
will often give a whole bunch of false leaks that the unstructured grid is just 
holding the references to), just share your output file and I can take a look 
at it to try and narrow down the culprit. That may be slightly easier to use 
than Valgrind.

Beyond this, you could maybe try the same run but without doing any Catalyst 
work to see what happens then. That may be a lot of compute cycles but I'm not 
sure how else to try and bisect where the memory leak is occurring.

Initializing and finalizing Catalyst every time you want output would probably 
work but I'd think there may be significant overhead doing it like this. Plus, 
it's not really solving the problem -- just avoiding it.

Best,
Andy


On Fri, May 20, 2016 at 12:57 PM, Gallagher, Timothy P 
> wrote:

Hi,


One of our users is running a very big simulation and writing out images of two 
slices (two different views) every 1000 iterations and writing out the data for 
the two slices (two different data writers) as VTK files every 5000 iterations. 
It is using Paraview 4.4.


After 21000 iterations, the simulation is killed because the memory on the 
compute nodes fills up. I usually know how to track down memory problems in our 
code using valgrind and related tools, but is that the right way to go to try 
and find this problem?


Are there any tips on how to isolate where the problem may be? I don't know if 
it is in the adapter, or in paraview itself. Has anybody encountered problems 
with runaway memory using Catalyst in 4.4 when writing images or VTK files?


I know when we use pvpython to generate images and loop over many files, 
sometimes the memory also blows up and so we usually move the loop over the 
files outside the pvpython script and into a driver script that executes a new 
pvpython for each file. Is there a way to shut down/start up Catalyst each time 
it needs to write something? Is that advisable?


Thanks,


Tim

___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview


___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] Memory leak with Catalyst

[Andy Bauer]

Hi Tim,

If you build Catalyst with VTK_DEBUG_LEAKS enabled it is pretty good at
finding VTK objects that aren't deleted properly. You should be able to run
this with a small amount of calls to Catalyst as well. If you try this and
want help understanding the output (if an object like a vtkUnstructuredGrid
is leaked it will often give a whole bunch of false leaks that the
unstructured grid is just holding the references to), just share your
output file and I can take a look at it to try and narrow down the culprit.
That may be slightly easier to use than Valgrind.

Beyond this, you could maybe try the same run but without doing any
Catalyst work to see what happens then. That may be a lot of compute cycles
but I'm not sure how else to try and bisect where the memory leak is
occurring.

Initializing and finalizing Catalyst every time you want output would
probably work but I'd think there may be significant overhead doing it like
this. Plus, it's not really solving the problem -- just avoiding it.

Best,
Andy


On Fri, May 20, 2016 at 12:57 PM, Gallagher, Timothy P <
tim.gallag...@gatech.edu> wrote:

> Hi,
>
>
> One of our users is running a very big simulation and writing out images
> of two slices (two different views) every 1000 iterations and writing out
> the data for the two slices (two different data writers) as VTK files every
> 5000 iterations. It is using Paraview 4.4.
>
>
> After 21000 iterations, the simulation is killed because the memory on the
> compute nodes fills up. I usually know how to track down memory problems in
> our code using valgrind and related tools, but is that the right way to go
> to try and find this problem?
>
>
> Are there any tips on how to isolate where the problem may be? I don't
> know if it is in the adapter, or in paraview itself. Has anybody
> encountered problems with runaway memory using Catalyst in 4.4 when writing
> images or VTK files?
>
>
> I know when we use pvpython to generate images and loop over many files,
> sometimes the memory also blows up and so we usually move the loop over the
> files outside the pvpython script and into a driver script that executes a
> new pvpython for each file. Is there a way to shut down/start up Catalyst
> each time it needs to write something? Is that advisable?
>
>
> Thanks,
>
>
> Tim
>
> ___
> 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
>
> Search the list archives at: http://markmail.org/search/?q=ParaView
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/paraview
>
>
___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

[Paraview] Slow with just 1M cells

[Michele Battistoni]

Paraview is awesome for lots of functionalities, however I find it extremely 
slow in processing data with any filter type, or in changing timestep as soon 
as the model size is around one million cells or above. I have experience with 
a commercial tool which on the same model and pc is 100x faster. Let's say a 
second vs. a min!

Is there any specific settings for ram of parallelization among cores?

Thanks 
Michele


___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

[Paraview] Memory leak with Catalyst

[Gallagher, Timothy P]

Hi,


One of our users is running a very big simulation and writing out images of two 
slices (two different views) every 1000 iterations and writing out the data for 
the two slices (two different data writers) as VTK files every 5000 iterations. 
It is using Paraview 4.4.


After 21000 iterations, the simulation is killed because the memory on the 
compute nodes fills up. I usually know how to track down memory problems in our 
code using valgrind and related tools, but is that the right way to go to try 
and find this problem?


Are there any tips on how to isolate where the problem may be? I don't know if 
it is in the adapter, or in paraview itself. Has anybody encountered problems 
with runaway memory using Catalyst in 4.4 when writing images or VTK files?


I know when we use pvpython to generate images and loop over many files, 
sometimes the memory also blows up and so we usually move the loop over the 
files outside the pvpython script and into a driver script that executes a new 
pvpython for each file. Is there a way to shut down/start up Catalyst each time 
it needs to write something? Is that advisable?


Thanks,


Tim
___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] Connect ParaViewWeb to Catalyst

[Sebastien Jourdain]

Hi Sven,

I am not aware on any specific developer documentation for Catalyst on the
ParaView side (but I haven't worked on that subject for years), although
Utkarsh or Andy might know.

Usually looking at the code and redoing it in the Python world is what is
required, but as I said, I'm not sure of what it means since I don't know
that code anymore. ;-)

For the timeframe, I can't tell (meaning I don't know), but we can still
try to help you or implement the missing piece via support contract if that
make sense on your end.

Thanks,

Seb

On Fri, May 20, 2016 at 10:46 AM, Sven Kramer 
wrote:

> Hello Seb,
> glad to read your answer. So the problem is not only that I was unable to
> find the relevant information.
>
> You say, you have not (yet) written the required code. Does "not (yet)"
> mean that it is on the agenda maybe within the next half year? Then I could
> find a workaround and look forward to the next Paraview updates.
>
> Otherwise I would try to work on the implementation for connecting
> Paraviewweb to Catalyst output. Is there any developer documentation of
> Catalysts "specific socket connection"? Or some general Catalyst developer
> information? Those would be great to get started.
> My first attempt would be to "wrap" the functionality of
> Qt/ApplicationComponents/pqCatalystConnectReaction.cxx into pvserver and
> make it available to the web client. Or are the necessary steps much more
> involved?
>
> Thank you
> Sven
>
>
> 2016-05-20 15:42 GMT+02:00 Sebastien Jourdain <
> sebastien.jourd...@kitware.com>:
>
>> Hi Sven,
>>
>> Live catalyst connection require a specific socket connection to the
>> in-situ process with some special handling.
>> We did not (yet) wrote the Python code to perform that specific action
>> for ParaViewWeb so it could be triggered by the web client or configured
>> via an argument at launch time.
>> I don't see any reason why this couldn't work, but as for now, I also
>> don't know an easy step to do it without spending time doing it myself.
>>
>> Seb
>>
>> On Thu, May 19, 2016 at 1:52 PM, Sven Kramer 
>> wrote:
>>
>>> Hello,
>>> I am looking for the recommended steps how to display an in-situ (live)
>>> Catalyst simulation through ParaViewWeb.
>>>
>>> After some efforts I am able to run ParaViewWeb successfully and I can
>>> view a Catalyst-enabled simulation in paraview.
>>>
>>> I hope, it is also possible to show the live Catalyst output via
>>> ParaViewWeb, but I cannot imagine how to achieve this. I tried starting a
>>> pvserver as mentioned at the end of
>>> https://blog.kitware.com/introduction-to-paraview-catalyst-live/ and
>>> giving "--ds-host localhost --ds-port 1" options to
>>> pv_web_visualizer.py, but it doesn't help. I can't share anything to be
>>> displayed on the web.
>>>
>>> Below you find the (not too detailed) steps I took to have a working
>>> solution for either Catalyst-enabled simulations or a working web
>>> visualizer:
>>>
>>> Test connection from Catalyst simulation to paraview:
>>> 1) Build and execute paraview from ParaView-v5.0.1-source.tar.gz (from
>>> http://www.paraview.org/download/)
>>> 2) Choose Catalyst->Connect in paraview
>>> 3) Run CFullExample from
>>> https://github.com/Kitware/ParaViewCatalystExampleCode
>>> 4) Pipeline from CFullExample is shown in paraview.
>>> Success!
>>>
>>> Test ParaViewWeb:
>>> 1) Download ParaViewData-5.0.0.tar.gz from
>>> http://www.paraview.org/download/, extract in /data
>>> 2) Run $ParaView_DIR/bin/pvpython
>>> $ParaView_DIR/lib/site-packages/paraview/web/pv_web_visualizer.py --content
>>> $ParaView_DIR/www  --data-dir /data --port 8080
>>> 3) Open the Visualizer App http://localhost:8080/apps/Visualizer/
>>> Success!
>>>
>>> But how do I get Catalyst into the web visualizer? Is there any example
>>> how to combine them? Anybody who can suggest the required steps?
>>>
>>> Regards,
>>> Sven
>>>
>>>
>>> ___
>>> 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
>>>
>>> Search the list archives at: http://markmail.org/search/?q=ParaView
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/paraview
>>>
>>>
>>
>
___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] Connect ParaViewWeb to Catalyst

[Sven Kramer]

Hello Seb,
glad to read your answer. So the problem is not only that I was unable to
find the relevant information.

You say, you have not (yet) written the required code. Does "not (yet)"
mean that it is on the agenda maybe within the next half year? Then I could
find a workaround and look forward to the next Paraview updates.

Otherwise I would try to work on the implementation for connecting
Paraviewweb to Catalyst output. Is there any developer documentation of
Catalysts "specific socket connection"? Or some general Catalyst developer
information? Those would be great to get started.
My first attempt would be to "wrap" the functionality of
Qt/ApplicationComponents/pqCatalystConnectReaction.cxx into pvserver and
make it available to the web client. Or are the necessary steps much more
involved?

Thank you
Sven

2016-05-20 15:42 GMT+02:00 Sebastien Jourdain <
sebastien.jourd...@kitware.com>:

> Hi Sven,
>
> Live catalyst connection require a specific socket connection to the
> in-situ process with some special handling.
> We did not (yet) wrote the Python code to perform that specific action for
> ParaViewWeb so it could be triggered by the web client or configured via an
> argument at launch time.
> I don't see any reason why this couldn't work, but as for now, I also
> don't know an easy step to do it without spending time doing it myself.
>
> Seb
>
> On Thu, May 19, 2016 at 1:52 PM, Sven Kramer 
> wrote:
>
>> Hello,
>> I am looking for the recommended steps how to display an in-situ (live)
>> Catalyst simulation through ParaViewWeb.
>>
>> After some efforts I am able to run ParaViewWeb successfully and I can
>> view a Catalyst-enabled simulation in paraview.
>>
>> I hope, it is also possible to show the live Catalyst output via
>> ParaViewWeb, but I cannot imagine how to achieve this. I tried starting a
>> pvserver as mentioned at the end of
>> https://blog.kitware.com/introduction-to-paraview-catalyst-live/ and
>> giving "--ds-host localhost --ds-port 1" options to
>> pv_web_visualizer.py, but it doesn't help. I can't share anything to be
>> displayed on the web.
>>
>> Below you find the (not too detailed) steps I took to have a working
>> solution for either Catalyst-enabled simulations or a working web
>> visualizer:
>>
>> Test connection from Catalyst simulation to paraview:
>> 1) Build and execute paraview from ParaView-v5.0.1-source.tar.gz (from
>> http://www.paraview.org/download/)
>> 2) Choose Catalyst->Connect in paraview
>> 3) Run CFullExample from
>> https://github.com/Kitware/ParaViewCatalystExampleCode
>> 4) Pipeline from CFullExample is shown in paraview.
>> Success!
>>
>> Test ParaViewWeb:
>> 1) Download ParaViewData-5.0.0.tar.gz from
>> http://www.paraview.org/download/, extract in /data
>> 2) Run $ParaView_DIR/bin/pvpython
>> $ParaView_DIR/lib/site-packages/paraview/web/pv_web_visualizer.py --content
>> $ParaView_DIR/www  --data-dir /data --port 8080
>> 3) Open the Visualizer App http://localhost:8080/apps/Visualizer/
>> Success!
>>
>> But how do I get Catalyst into the web visualizer? Is there any example
>> how to combine them? Anybody who can suggest the required steps?
>>
>> Regards,
>> Sven
>>
>>
>> ___
>> 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
>>
>> Search the list archives at: http://markmail.org/search/?q=ParaView
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/paraview
>>
>>
>
___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] capability of ParaView, Catalyst in distributed computing environment ...

[Andy Bauer]

It may be possible to do this with Catalyst. I would guess that nearly all
of the complex work would need to be done in the adaptor to integrate this
properly though.

On Wed, May 18, 2016 at 11:17 AM,  wrote:

> Yes, you are right. In this case, there will be two separate
> MPI_COMM_WORLD. Plus, one that covers all the resources (let's say that
> global MPI_COMM_WORLD). Actually, this kind of setup is very common for
> multi-physics applications such as fluid-structure interaction. So, is it
> possible to tight this kind of environment with Catalyst? I am not expert
> about Catalyst but it seems that there might be a problem in the rendering
> stage even underlying grids and fields are defined without any problem.
>
> Regards,
>
> --ufuk
>
> > I'm not sure if this is exactly what the original user is referring to,
> > but it is possible to have two separate codes communicate using MPI
> > through the dynamic processes in MPI-2. Essentially, one program starts
> up
> > on N processors and begins running and gets an MPI_COMM_WORLD. It then
> > spawns another executable on M different processors and that new
> > executable will call MPI_INIT and also get its own MPI_COMM_WORLD. So you
> > have two, disjoint MPI_COMM_WORLD's that get linked together through a
> > newly created intercommunicator.
> >
> >
> > I've used this to couple a structural mechanics code to our fluid
> dynamics
> > solver for example. It sounds like that is similar to what is being done
> > here.
> >
> >
> > How that would interact with coprocessing is beyond my knowledge though.
> > It does sound like an interesting problem and one I would be very curious
> > to find out the details.
> >
> >
> > Tim
> >
> >
> > 
> > From: ParaView  on behalf of Andy Bauer
> > 
> > Sent: Wednesday, May 18, 2016 10:52 AM
> > To: Ufuk Utku Turuncoglu (BE)
> > Cc: paraview@paraview.org
> > Subject: Re: [Paraview] capability of ParaView, Catalyst in distributed
> > computing environment ...
> >
> > Hi,
> >
> > I'm a bit confused. MPI_COMM_WORLD is the global communicator and as far
> > as I'm aware, can't be modified which means there can't be two different
> > communicators.
> >
> > Catalyst can be set to use a specific MPI communicator and that's been
> > done by at least one code (Code_Saturne). I think they have a
> multiphysics
> > simulation as well.
> >
> > Cheers,
> > Andy
> >
> > On Wed, May 18, 2016 at 5:22 AM, Ufuk Utku Turuncoglu (BE)
> >  >>
> > wrote:
> > Hi All,
> >
> > I just wonder about the capability of ParaView, Catalyst in distributed
> > computing environment. I have little bit experience in in-situ
> > visualization but it is hard for me to see the big picture at this point.
> > So, i decided to ask to the user list to get some suggestion from the
> > experts. Hypothetically, lets assume that we have two simulation code
> that
> > are coupled together (i.e. fluid-structure interaction) and both of them
> > have their own MPI_COMM_WORLD and run on different processors (model1
> runs
> > on MPI rank 0,1,2,3 and model2 runs on 4,5,6,7). What is the correct
> > design to create integrated in-situ visualization analysis (both model
> > contributes to same visualization pipeline) in this case? Do you know any
> > implementation that is similar to this design? At least, is it possible?
> >
> > In this case, the adaptor code will need to access to two different
> > MPI_COMM_WORLD and it could run on all processor (from 0 to 7) or its own
> > MPI_COMM_WORLD (i.e. MPI ranks 8,9,10,11). Also, the both simulation code
> > have its own grid and field definitions (might be handled via defining
> > different input ports). Does it create a problem in Paraview, Catalyst
> > side, if the multiblock dataset is used to define the grids of the
> > components in adaptor. I am asking because some MPI processes (belongs to
> > adaptor code) will not have data for specific model component due to the
> > domain decomposition implementation of the individual models. For
> example,
> > MPI rank 4,5,6,7 will not have data for model1 (that runs on MPI rank
> > 0,1,2,3) and 0,1,2,3 will not have data for model2 (that runs on MPI rank
> > 4,5,6,7). To that end, do i need to collect all the data from the
> > components? If this is the case, how can i handle 2d decomposition
> > problem? Because, the adaptor code has no any common grid structure that
> > fits for all the model components.
> >
> > Regards,
> >
> > Ufuk Turuncoglu
> > ___
> > 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
> >
> > Search the list archives 

Re: [Paraview] Question about the ImageResampling Filter

[Utkarsh Ayachit]

Lukasz,

> The volume rendering algorithms in Paraview are ultrafast with VTK image 
> files but painfully slow with unstructured grids. I constantly have an idea 
> in mind to map unstructured meshes to image files and then do the volume 
> rendering.

That's indeed the reason by the "Resample to Image" filter was created
:). And it's expected to work in parallel for composite datasets too.
Of course, if you spot a bug, do let us know.

Utkarsh
___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] Paraview 5.0.1: Export Scene to pdf -- appears in white

[David Lonie]

On Fri, May 20, 2016 at 10:19 AM, Ramiro James Rebolledo Cormack <
ramre...@gmail.com> wrote:
>
> I compile paraview in my laptop (ubuntu 16.04) and my desktop (ubuntu
> 14.04) with exactly the same options in ccmake, in particular: OpenGL.
> In my laptop 'Export to pdf' works perfect.
> Is this related this the nvidia driver? In my desktop I have installed
> nvidia driver, but in my destop I have not installed nvidia driver.
>

Hmm, the opengl driver shouldn't matter on the OpenGL1 backend, unless
there was a bug in their feedback rendering mode. Are you trying to export
the same scene on both systems?


> + When you compiled 5.0.1 from source, I suspect you are getting the
>> old rendering backend too (unless you changed the CMake variable
>> VTK_RENDERING_BACKEND to OpenGL2). Not entirely sure why export would
>> fail in that case. There isn't any special flag to enable PDF export.
>>
>
> Now, in my desktop I'm trying compiling with OpenGL2 option (the option
> doesn't comes hiting the enter button, instead of my laptop, but I chosed
> writting it), and crossing my fingers.
>
> I appreciate any ideas or suggestions (I don't have more), to find a way
> for fix this 'little' problem: to have the export to pdf option.
>

I'd suggest just playing with the export options and see if there's a
solution there. If you keep having trouble, send me a small state file that
reproduces the issue and I'll take a look. There are certain cases where
the gl2ps exporter will fail to capture all of the details in a scene,
though it should produce more than an empty white image.

Dave
___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] Question about the ImageResampling Filter

[Paluszek, Lukasz]

Hi Utkarsh,

I am always building Paraview from source on Linux with all the features I 
need, but there is no rush, I can wait for the next release or if I badly need 
this functionality I will pull it from the “master”.

A little background:
I was actually playing around when I came across the issue, what I want to 
achieve is to do fast volume rendering on unstructured meshes. The volume 
rendering algorithms in Paraview are ultrafast with VTK image files but 
painfully slow with unstructured grids. I constantly have an idea in mind to 
map unstructured meshes to image files and then do the volume rendering. Simple 
as it sounds I could not find an automatic way to achieve this, in the end I 
had to manually generate image files in a text editor. I also tried with the 
Gaussian Resampling, but this filter fails in parallel, each process generates 
its own image file but there is no communication between them, it is not 
possible to resample data onto these images nor is it possible to save them 
(Paraview saves data from just one process). I am still hoping to find some 
smart way of generating image files, ideally automatically refined based on 
some flow variables of interest and then map the unstructured grid data on the 
generated VTK images for fast volume rendering.

Regards,
Lukasz


[Beschreibung: Beschreibung: Description : cid:image001.png@01CF0B8F.DB7831F0]
Łukasz Paluszek
Airbus Helicopters
Aerodynamics Department (ETGA)
86607 Donauwörth
Germany
Tel.: +49 (90) 671 8231
Fax.: +49 (90) 671 9122
lukasz.palus...@airbus.com

From: Utkarsh Ayachit [mailto:utkarsh.ayac...@kitware.com]
Sent: 20 May 2016 15:38
To: Paluszek, Lukasz
Cc: paraview@paraview.org
Subject: Re: [Paraview] Question about the ImageResampling Filter

Lukasz,

I'd suggest not to use 'ImageResampling' filter, it was a temporary fix and 
clearly is buggy. A new filter has been added to ParaView "master", name 
"Resample To Image". That would do what you want to do more reliably. What 
platform are you running on? I can send you links to the nightly binaries for 
the same.

Utkarsh

On Fri, May 20, 2016 at 3:17 AM, Paluszek, Lukasz 
> wrote:
Hello All,

Is the Image Resampling filter applicable to all datasets or only VTK Images? 
Each time I try to use this filter on any other dataset than a uniform image 
file, Paraview crashes. In Paraview Help it is written: “Accepts input of 
following types: vtkDataSet vtkCompositeDataSet”. I am using Paraview 5.0.0.

Regards,
Lukasz





[Beschreibung: Beschreibung: Description : cid:image001.png@01CF0B8F.DB7831F0]
Łukasz Paluszek
Airbus Helicopters
Aerodynamics Department (ETGA)
86607 Donauwörth
Germany
Tel.: +49 (90) 671 8231
Fax.: +49 (90) 671 9122
lukasz.palus...@airbus.com


AIRBUS HELICOPTERS DEUTSCHLAND GmbH

Sitz der Gesellschaft / Registered Office: Donauwörth

Registergericht / Registration Court: Amtsgericht Augsburg HRB 16508

Vorsitzender des Aufsichtsrates / Chairman of the Supervisory Board: Guillaume 
Faury

Geschäftsführung / Board of Management: Dr. Wolfgang Schoder, Vorsitzender / 
CEO; Thomas Hundt; Johannes Kleidorfer; Dr. Klaus Przemeck; Martin Schübel; 
Stefan Thomé



The information in this e-mail is confidential. The contents may not be 
disclosed or used by anyone other than the addressee. Access to this e-mail by 
anyone else is unauthorised.

If you are not the intended recipient, please notify Airbus immediately and 
delete this e-mail.

Airbus cannot accept any responsibility for the accuracy or completeness of 
this e-mail as it has been sent over public networks. If you have any concerns 
over the content of this message or its Accuracy or Integrity, please contact 
Airbus immediately.

All outgoing e-mails from Airbus are checked using regularly updated virus 
scanning software but you should take whatever measures you deem to be 
appropriate to ensure that this message and any attachments are virus free.







___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview


AIRBUS HELICOPTERS DEUTSCHLAND GmbH

Sitz der Gesellschaft / Registered Office: Donauwörth

Registergericht / Registration Court: Amtsgericht Augsburg HRB 16508

Vorsitzender des Aufsichtsrates / Chairman of the Supervisory Board: Guillaume 
Faury

Geschäftsführung / Board of Management: Dr. Wolfgang Schoder, Vorsitzender / 
CEO; Thomas Hundt; Johannes Kleidorfer; Dr. Klaus Przemeck; Martin Schübel; 
Stefan Thomé


The information in 

Re: [Paraview] Paraview 5.0.1: Export Scene to pdf -- appears in white

[David Lonie]

On Thu, May 19, 2016 at 10:16 PM, Utkarsh Ayachit <
utkarsh.ayac...@kitware.com> wrote:

> + Not sure what's the deal with 4.0.1, but it's too old at this point
> so let's ignore that.
> + When you downloaded ParaView 5.0.1 from paraview.org, starting with
> 5.0.1, we are using a new implementation of the rendering backend for
> our binaries [1]. This rendering backend, let's call OpenGL2, doesn't
> support exporting to PDF, at least, not in 5.0.1. It's been fixed in
> git "master".
> + I suspect ParaView 5.0.1 from Ubuntu is using the old rendering
> backend by default. The title bar should say something like "ParaView
> 5.0.1 (Legacy Rendering Backend)". This backend still support the old
> export to PDF code and hence should have that option.
> + When you compiled 5.0.1 from source, I suspect you are getting the
> old rendering backend too (unless you changed the CMake variable
> VTK_RENDERING_BACKEND to OpenGL2). Not entirely sure why export would
> fail in that case. There isn't any special flag to enable PDF export.
>
> However, the best option to try out Export to PDF would be build the
> latest "master" from source with VTK_RENDERING_BACKEND set to OpenGL2.
>
> (Dave, do correct me if I am misspoke).
>

This sounds about right. The gl2ps library we use to generate the pdfs was
not compatible with the new OpenGL2 backend, and I had to tweak it a bit to
get it working again. Looking at the git log, the modifications didn't make
it into the 5.0.1 release, so export would only work using the old backend
with that release.

The current development branch supports pdf export on both backends.

I'm curious about the white exported image, though. IIRC, the
vector-graphics export options shouldn't be shown on the versions of
paraview that don't support gl2ps, so if you're able to export, it should
be working. It sounds like you may have also brushed up against one of the
limitations of the gl2ps library -- for instance, it can't handle textured
objects (they'll just appear a solid color, rather than patterned). This
can be problematic as some of the color mapping techniques use textures.

If you're seeing incorrect output, try playing with the "rasterize 3D
geometry" and sort options to see if you can get a better representation of
the scene.

HTH,
Dave
___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] [Non-DoD Source] Re: paraview superbuild on Win7 with ninja/vs2013/qt4/mpi (UNCLASSIFIED)

[Su, Simon M CIV USARMY RDECOM ARL (US)]

CLASSIFICATION: UNCLASSIFIED

Stephane,

I am not sure about the superbuild process. But if your goal is to just build a 
ParaView for windows platform and not make a ParaView windows build using 
Superbuild, I can get you with all the dependencies library compiled with 
VS2013 express (which should be compatible with other VS 2013) that I used to 
build ParaView from source.

Let me know.

Best
-simon

-Original Message-
From: ParaView [mailto:paraview-boun...@paraview.org] On Behalf Of stephane 

Sent: Friday, May 20, 2016 1:44 AM
To: Joachim Pouderoux 
Cc: paraview 
Subject: [Non-DoD Source] Re: [Paraview] paraview superbuild on Win7 with 
ninja/vs2013/qt4/mpi

All active links contained in this email were disabled. Please verify the 
identity of the sender, and confirm the authenticity of all links contained 
within the message prior to copying and pasting the address to a Web browser. 






Hello,

any idea on how to solve the following build error?

NMAKE : fatal error U1073: don't know how to make 'c:/Program\'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 
12.0\VC\bin\amd64\nmake.exe"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: 'cd' : return code '0x2'
Stop.
ninja: build stopped: subcommand failed.

Stephane

川崎工場
火力タービン部　計画設計課
ンドング-メファネ　ステファン
工学博士

富士電機株式会社
〒210-9530川崎市川崎区田辺新田1-1
TEL 044-329-2155 FAX 044-329-2394

On Fri, May 20, 2016 at 2:42 PM, stephaneンドング メファネ  > wrote:


Hello,

any idea on how to solve the following build error?



川崎工場
火力タービン部　計画設計課
ンドング-メファネ　ステファン
工学博士

富士電機株式会社
〒210-9530川崎市川崎区田辺新田1-1
TEL 044-329-2155 FAX 044-329-2394

On Fri, May 20, 2016 at 8:33 AM, stephaneンドング メファネ 
 > wrote:


Hello,
As stated in my previous e-mail, building ninja from vs2013did 
not solve the problem. I also noticed that re-sending the ninja command after 
the "subcommand failed" kind of resume the process to some point. I've attached 
the corresponding log files.

Is it possible to build it with Visual Studio IDE instead of 
Ninja?

川崎工場
火力タービン部　計画設計課
ンドング-メファネ　ステファン
工学博士

富士電機株式会社
〒210-9530川崎市川崎区田辺新田1-1
TEL 044-329-2155 FAX 044-329-2394

On Thu, May 19, 2016 at 4:42 PM, Joachim Pouderoux 
 
> wrote:


Hello,


Did you compiled ninja using your VS2013?

Do you start ninja from a Visual Studio 2013 command 
line (so that cmake can find VS compiler in the environment)?


Regards,




Joachim Pouderoux


PhD, Technical Expert
Kitware SAS < Caution-http://www.kitware.fr > 



2016-05-19 7:49 GMT+02:00 stephaneンドング メファネ 
 >:


Hello,

I am sending a Log of the building process 


Ndong-Mefane Stephane, Dr.Eng
Basic Design Sec.
Steam Turbine Dept.
Kawasaki Factory

Fuji Electric Co., Ltd
1-1, Tanabeshinden, Kawasaki-ku,
Kawasaki-city 210-9530, Japan
Phone: +81-44-329-2155 < tel:%2B81-44-329-2155 
> 
Fax: +81-44-329-2394 < tel:%2B81-44-329-2394 > 



On Thu, May 19, 2016 at 1:54 PM, stephaneンドング 
メファネ  > 
wrote:


Hello, 
I've been trying to "superbuild" 
paraview 5.0 on Win7 without success.
I keep getting two errors:
1) the first one is related to szip at 

Re: [Paraview] Connect ParaViewWeb to Catalyst

[Sebastien Jourdain]

Hi Sven,

Live catalyst connection require a specific socket connection to the
in-situ process with some special handling.
We did not (yet) wrote the Python code to perform that specific action for
ParaViewWeb so it could be triggered by the web client or configured via an
argument at launch time.
I don't see any reason why this couldn't work, but as for now, I also don't
know an easy step to do it without spending time doing it myself.

Seb

On Thu, May 19, 2016 at 1:52 PM, Sven Kramer  wrote:

> Hello,
> I am looking for the recommended steps how to display an in-situ (live)
> Catalyst simulation through ParaViewWeb.
>
> After some efforts I am able to run ParaViewWeb successfully and I can
> view a Catalyst-enabled simulation in paraview.
>
> I hope, it is also possible to show the live Catalyst output via
> ParaViewWeb, but I cannot imagine how to achieve this. I tried starting a
> pvserver as mentioned at the end of
> https://blog.kitware.com/introduction-to-paraview-catalyst-live/ and
> giving "--ds-host localhost --ds-port 1" options to
> pv_web_visualizer.py, but it doesn't help. I can't share anything to be
> displayed on the web.
>
> Below you find the (not too detailed) steps I took to have a working
> solution for either Catalyst-enabled simulations or a working web
> visualizer:
>
> Test connection from Catalyst simulation to paraview:
> 1) Build and execute paraview from ParaView-v5.0.1-source.tar.gz (from
> http://www.paraview.org/download/)
> 2) Choose Catalyst->Connect in paraview
> 3) Run CFullExample from
> https://github.com/Kitware/ParaViewCatalystExampleCode
> 4) Pipeline from CFullExample is shown in paraview.
> Success!
>
> Test ParaViewWeb:
> 1) Download ParaViewData-5.0.0.tar.gz from
> http://www.paraview.org/download/, extract in /data
> 2) Run $ParaView_DIR/bin/pvpython
> $ParaView_DIR/lib/site-packages/paraview/web/pv_web_visualizer.py --content
> $ParaView_DIR/www  --data-dir /data --port 8080
> 3) Open the Visualizer App http://localhost:8080/apps/Visualizer/
> Success!
>
> But how do I get Catalyst into the web visualizer? Is there any example
> how to combine them? Anybody who can suggest the required steps?
>
> Regards,
> Sven
>
>
> ___
> 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
>
> Search the list archives at: http://markmail.org/search/?q=ParaView
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/paraview
>
>
___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] Question about the ImageResampling Filter

[Utkarsh Ayachit]

Lukasz,

I'd suggest not to use 'ImageResampling' filter, it was a temporary fix and
clearly is buggy. A new filter has been added to ParaView "master", name
"Resample To Image". That would do what you want to do more reliably. What
platform are you running on? I can send you links to the nightly binaries
for the same.

Utkarsh

On Fri, May 20, 2016 at 3:17 AM, Paluszek, Lukasz <
lukasz.palus...@airbus.com> wrote:

> Hello All,
>
>
>
> Is the Image Resampling filter applicable to all datasets or only VTK
> Images? Each time I try to use this filter on any other dataset than a
> uniform image file, Paraview crashes. In Paraview Help it is written:
> “Accepts input of following types: vtkDataSet vtkCompositeDataSet”. I am
> using Paraview 5.0.0.
>
>
>
> Regards,
>
> Lukasz
>
>
>
>
>
>
>
>
>
>
>
> [image: Beschreibung: Beschreibung: Description :
> cid:image001.png@01CF0B8F.DB7831F0]
>
> *Łukasz Paluszek*
>
> Airbus Helicopters
>
> Aerodynamics Department (ETGA)
>
> 86607 Donauwörth
>
> Germany
>
> Tel.: +49 (90) 671 8231
>
> Fax.: +49 (90) 671 9122
>
> lukasz.palus...@airbus.com
>
>
>
> AIRBUS HELICOPTERS DEUTSCHLAND GmbH
>
> Sitz der Gesellschaft / Registered Office: Donauwörth
>
> Registergericht / Registration Court: Amtsgericht Augsburg HRB 16508
>
> Vorsitzender des Aufsichtsrates / Chairman of the Supervisory Board:
> Guillaume Faury
>
> Geschäftsführung / Board of Management: Dr. Wolfgang Schoder, Vorsitzender
> / CEO; Thomas Hundt; Johannes Kleidorfer; Dr. Klaus Przemeck; Martin
> Schübel; Stefan Thomé
>
>
> The information in this e-mail is confidential. The contents may not be 
> disclosed or used by anyone other than the addressee. Access to this e-mail 
> by anyone else is unauthorised.
> If you are not the intended recipient, please notify Airbus immediately and 
> delete this e-mail.
> Airbus cannot accept any responsibility for the accuracy or completeness of 
> this e-mail as it has been sent over public networks. If you have any 
> concerns over the content of this message or its Accuracy or Integrity, 
> please contact Airbus immediately.
> All outgoing e-mails from Airbus are checked using regularly updated virus 
> scanning software but you should take whatever measures you deem to be 
> appropriate to ensure that this message and any attachments are virus free.
>
>
> ___
> 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
>
> Search the list archives at: http://markmail.org/search/?q=ParaView
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/paraview
>
>
___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

[Paraview] Question about the ImageResampling Filter

[Paluszek, Lukasz]

Hello All,

Is the Image Resampling filter applicable to all datasets or only VTK Images? 
Each time I try to use this filter on any other dataset than a uniform image 
file, Paraview crashes. In Paraview Help it is written: "Accepts input of 
following types: vtkDataSet vtkCompositeDataSet". I am using Paraview 5.0.0.

Regards,
Lukasz





[Beschreibung: Beschreibung: Description : cid:image001.png@01CF0B8F.DB7831F0]
Łukasz Paluszek
Airbus Helicopters
Aerodynamics Department (ETGA)
86607 Donauwörth
Germany
Tel.: +49 (90) 671 8231
Fax.: +49 (90) 671 9122
lukasz.palus...@airbus.com


AIRBUS HELICOPTERS DEUTSCHLAND GmbH

Sitz der Gesellschaft / Registered Office: Donauwörth

Registergericht / Registration Court: Amtsgericht Augsburg HRB 16508

Vorsitzender des Aufsichtsrates / Chairman of the Supervisory Board: Guillaume 
Faury

Geschäftsführung / Board of Management: Dr. Wolfgang Schoder, Vorsitzender / 
CEO; Thomas Hundt; Johannes Kleidorfer; Dr. Klaus Przemeck; Martin Schübel; 
Stefan Thomé


The information in this e-mail is confidential. The contents may not be 
disclosed or used by anyone other than the addressee. Access to this e-mail by 
anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and 
delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of 
this e-mail as it has been sent over public networks. If you have any concerns 
over the content of this message or its Accuracy or Integrity, please contact 
Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus 
scanning software but you should take whatever measures you deem to be 
appropriate to ensure that this message and any attachments are virus free.




___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview