Catalyst live visualization

can you do:
VERBOSE=1 make ExternalData/Testing/Data/Baseline/pqCoreBasicApp.png-hash-stamp

maybe this will give you more information on what is going on.

Hi
Actually, in order to make it faster, I replace make with ninja.

And here is the output:Object

SHA512=3405b32d38058a84dcb678c4b3dc8c0cbceae4e10aae4e8750f87ae2d07367d14c3084b8d91b3ea8ad8611a5225bbdbf248bc61dc7a52f2f87631a920db0efcb
not found at:

https://data.kitware.com/api/v1/file/hashsum/SHA512/3405b32d38058a84dcb678c4b3dc8c0cbceae4e10aae4e8750f87ae2d07367d14c3084b8d91b3ea8ad8611a5225bbdbf248bc61dc7a52f2f87631a920db0efcb/download (“Unsupported protocol”)
https://www.paraview.org/files/ExternalData/SHA512/3405b32d38058a84dcb678c4b3dc8c0cbceae4e10aae4e8750f87ae2d07367d14c3084b8d91b3ea8ad8611a5225bbdbf248bc61dc7a52f2f87631a920db0efcb (“Unsupported protocol”)

Does it have to make sure the ctest catalystlive work?

That is strange. If I click on any of the links you send I see the baseline it tries to download. Does this work for you?
What cmake version are you using? Maybe that does not support https?

cmake version 3.13.0
Is the protocol problem or the cmake problem?

Likely you are using a CMake not built with SSL support. You can download CMake from www.cmake.org and that should fix the problem.

What do you mean build cmake with SSL support as I have build cmake from the source package?

No, you don’t need to, but whoever built the CMake you are using may not have enabled SSL. Where did you get CMake from?

I download the cmake source package from the ww.cmake.org.
How can I enable the SSL support with cmake?

How can I enable the SSL support with cmake?

That’s a question for the CMake mailing list: https://cmake.org/mailing-lists/. Do search the archives first as it has probably been asked in the past.

I recommend downloading and using the CMake binaries from www.cmake.org.

I successfully build paraview with BUILD_TESTING=on. But when I test the catalystlive, it always stops at the second one and no response at all.

Are there any variables I should pay attention to when building the paraview?

Do you have all these variables on?
BUILD_TESTING, PARAVIEW_USE_MPI and PARAVIEW_ENABLE_PYTHON.

Use ctest -N -V -R CatalystLIve

to find out the actual commands executed and then execute the second command to see a better error message.

Yes, I set these variables correctly.
Here is the output after I run the command:

UpdateCTestConfiguration from :/home/lcui/Downloads/Paraview/build/DartConfiguration.tcl
Parse Config file:/home/lcui/Downloads/Paraview/build/DartConfiguration.tcl
Add coverage exclude regular expressions.
Add coverage exclude: vtk[^.]+(Java|Python).cxx
Add coverage exclude: .vtkOpenGLState.
Add coverage exclude: .Testing.Cxx.cxx
Add coverage exclude: .Testing.Cxx.h
Add coverage exclude: .moc_.cxx
Add coverage exclude: .
/Rendering/OpenGL/vtkgl.

Add coverage exclude: .
/Utilities/.

Add coverage exclude: .
/ThirdParty/.

Add coverage exclude: .vtkOpenGLPolyDataMapper.
Add coverage exclude: ./VTK/.
Add coverage exclude: vtk[^.]+ClientServer.cxx
Add coverage exclude: vtk[^.]+Python.cxx
Add coverage exclude: ui_[^.]+.h
Add coverage exclude: moc_[^.]+.h
Add coverage exclude: vtkprotobuf
SetCTestConfiguration:CMakeCommand:/usr/local/bin/cmake
UpdateCTestConfiguration from :/home/lcui/Downloads/Paraview/build/DartConfiguration.tcl
Parse Config file:/home/lcui/Downloads/Paraview/build/DartConfiguration.tcl
Test project /home/lcui/Downloads/Paraview/build
Constructing a list of tests
Done constructing a list of tests
Updating test list for fixtures
Added 0 tests to meet fixture requirements

1970: Test command: /home/lcui/Downloads/Paraview/build/bin/smTestDriver “–enable-bt” “–script-ignore-output-errors” “–script” “/home/lcui/Downloads/Paraview/build/bin/pvbatch” “-sym” “/home/lcui/Downloads/Paraview/paraview/Applications/ParaView/Testing/XML/CatalystWa
veletDriver.py” “CatalystWaveletCoprocessing” “222” “–client” “/home/lcui/Downloads/Paraview/build/bin/paraview” “–enable-bt” “-dr” “–test-directory=/home/lcui/Downloads/Paraview/build/Testing/Temporary” “–test-script=/home/lcui/Downloads/Paraview/paraview/Applicatio
ns/ParaView/Testing/XML/CatalystLiveSetBreakpoint.xml” “–test-baseline=/home/lcui/Downloads/Paraview/build/ExternalData/Testing/Data/Baseline/CatalystLiveSetBreakpoint.png” “–exit”
Labels: CATALYST PARAVIEW
Test #1970: pv.CatalystLiveSetBreakpoint

1971: Test command: /home/lcui/Downloads/Paraview/build/bin/smTestDriver “–enable-bt” “–script-np” “5” “–script-ignore-output-errors” “–script” “/home/lcui/Downloads/Paraview/build/bin/pvbatch” “-sym” “/home/lcui/Downloads/Paraview/paraview/Applications/ParaView/Test
ing/XML/CatalystWaveletDriver.py” “CatalystWaveletCoprocessing” “222” “–server” “/home/lcui/Downloads/Paraview/build/bin/pvserver” “–enable-bt” “–client” “/home/lcui/Downloads/Paraview/build/bin/paraview” “–enable-bt” “-dr” “–test-directory=/home/lcui/Downloads/Para
view/build/Testing/Temporary” “–test-script=/home/lcui/Downloads/Paraview/paraview/Applications/ParaView/Testing/XML/CatalystLiveSetBreakpoint.xml” “–test-baseline=/home/lcui/Downloads/Paraview/build/ExternalData/Testing/Data/Baseline/CatalystLiveSetBreakpoint.png” “–
exit”
Labels: CATALYST PARAVIEW
Test #1971: pvcs.CatalystLiveSetBreakpoint

1972: Test command: /home/lcui/Downloads/Paraview/build/bin/smTestDriver “–enable-bt” “–script-ignore-output-errors” “–script” “/home/lcui/Downloads/Paraview/build/bin/pvbatch” “-sym” “/home/lcui/Downloads/Paraview/paraview/Applications/ParaView/Testing/XML/CatalystWa
veletDriver.py” “CatalystWaveletCoprocessing” “80” “–client” “/home/lcui/Downloads/Paraview/build/bin/paraview” “–enable-bt” “–live=22222” “-dr” “–test-directory=/home/lcui/Downloads/Paraview/build/Testing/Temporary” “–test-script=/home/lcui/Downloads/Paraview/parav
iew/Applications/ParaView/Testing/XML/CatalystLivePause.xml” “–test-baseline=/home/lcui/Downloads/Paraview/build/ExternalData/Testing/Data/Baseline/CatalystLivePause.png” “–exit”
Labels: CATALYST PARAVIEW
Test #1972: pv.CatalystLivePause

1973: Test command: /home/lcui/Downloads/Paraview/build/bin/smTestDriver “–enable-bt” “–script-np” “5” “–script-ignore-output-errors” “–script” “/home/lcui/Downloads/Paraview/build/bin/pvbatch” “-sym” “/home/lcui/Downloads/Paraview/paraview/Applications/ParaView/Test
ing/XML/CatalystWaveletDriver.py” “CatalystWaveletCoprocessing” “80” “–server” “/home/lcui/Downloads/Paraview/build/bin/pvserver” “–enable-bt” “–client” “/home/lcui/Downloads/Paraview/build/bin/paraview” “–enable-bt” “–live=22222” “-dr” “–test-directory=/home/lcui/
Downloads/Paraview/build/Testing/Temporary” “–test-script=/home/lcui/Downloads/Paraview/paraview/Applications/ParaView/Testing/XML/CatalystLivePause.xml” “–test-baseline=/home/lcui/Downloads/Paraview/build/ExternalData/Testing/Data/Baseline/CatalystLivePause.png” “–ex
it”
Labels: CATALYST PARAVIEW
Test #1973: pvcs.CatalystLivePause

Total Tests: 4

No errors show. I am new to this and cannot read these output. Can you help me out?

I am continuing the conversation from About the In Situ Support category in this thread, since it seems related.

First and foremost, what version of ParaView you using? I will try to use the same version and create a simply driver/script for you to use for the test.

The version is 5.6.0-364-g1c776910c8. Thanks

Attached is a CxxFullExample.patch (1.3 KB) that does the following:

  1. add a sleep to the CxxFullExample/FEDriver.cxx to make it loop a tad slowly to help see the simulation progress.
  2. enable live visualization in the Catalyst script CxxFullExample/SampleScripts/feslicescript.py.

Apply this patch to your paraview source and then rebuild the examples.

Now, launch ParaView and select the menu options Catalyst > Connect …, accept the Catalyst Server Port dialog with default options and hit OK.

Next, launch the sim/miniapp as follows:

…/CxxFullExample [full path to ParaVIew source]/Examples/Catalyst/CxxFullExample/SampleScripts/feslicescript.py

As soon as the sim connects to ParaView, you’ll see something like this:

image

While you’re figuring things out, I’d recommend pausing the sim once this happens. To do that, chose Catalyst > Pause Simulation menu option.

Next, click on the image next to the Slice1 entry in the PIpeline Browser. This will result in the following:

image

The Extract: Slice1 is the data generated from the Slice1 filter being executing in the in situ pipeline made available to ParaView for viz. You can toggle visibility, change scalar coloring, add filters, etc to the Extract: Slice1 data source just like a regular data source in ParaView. Try turning on the visibility for Extract: Slice1 and then color by Velocity (and move the camera, since the default view has the slice orthogonal to the view plane).

Choose Catalyst > Continue menu option to let the sim continue and you’ll see the color update showing the sim progressing.

Hope that gets you going.

Hi
Pretty appreciate for the patch. But after I did every step you told me I still have the same issues, which are that the animation is not the correct and the socket errors at the end of the simulation.

As you said I can ignore the socket error, but what’s going on with the animation?

Thanks

What’s going on with the animation? You’ll need to describe in more details the steps that you are taking and the results you’re seeing before I can comment. I don’t know what do you mean by the animation is not correct.

catalyst-2018-12-02_13.21.23.avi

Sorry about that. I attach a video of the animation. Maybe it is best to describe the mistake.
Thanks

This is exactly what the animation is expected to do. The CxxFullExample example is a very simple driver code with minimal changes to the velocity field. Catalyst Live does not rescale the look up table automatically in the GUI. You may want to look through the Catalyst User’s Guide which is available at https://www.paraview.org/in-situ/ and spend some time looking through the CxxFullExample code itself to better understand what is happening in the example.

Thanks for the responses. I read the source code of CxxFullExample again and I mistake something.
But I am still not sure is it ok to ignore the socketing errors at the end of simulation?