ParaView issueshttps://gitlab.kitware.com/paraview/paraview/-/issues2024-01-04T21:24:45-05:00https://gitlab.kitware.com/paraview/paraview/-/issues/22393The IOSS reader is failing reading variables2024-01-04T21:24:45-05:00W. Alan ScottThe IOSS reader is failing reading variablesThe IOSS reader is failing reading variable data for a dataset. This shows with one file of the 640 file dataset. I am giving this file to @cory.quammen. It is ok to pass to anyone at Kitware, but file is DoNotRelease.
* 5 12.0-RC1, L...The IOSS reader is failing reading variable data for a dataset. This shows with one file of the 640 file dataset. I am giving this file to @cory.quammen. It is ok to pass to anyone at Kitware, but file is DoNotRelease.
* 5 12.0-RC1, Linux, builtin server.
* Open IOSS-VariablesDontRead-DoNotRelease.exo. Apply. This will read all blocks and variables.
* Try to paint by a variable from the Properties tab variable list. You can't. This is a bug.
* Delete the file.
* Tools/ Manage Plugins/ load the LegacyExodusReader.
* Open IOSS-VariablesDontRead-DoNotRelease.exo. Use the LegacyExodusReader. Turn on the variables. Apply.
* You will be able to paint by different variables from the Properties tab.
@spiros.tsalikis5.13 (Summer 2024)Spiros TsalikisSpiros Tsalikishttps://gitlab.kitware.com/paraview/paraview/-/issues/22221min/max variable values on a per block basis2023-08-29T16:35:00-04:00Boonthanome Nouanesengsymin/max variable values on a per block basisFor some of our codes, the grid is organized into various blocks. For example, a dataset may be split such that each material is in a separate block in a multiblock dataset.
It would be good to have some method that will calculate stand...For some of our codes, the grid is organized into various blocks. For example, a dataset may be split such that each material is in a separate block in a multiblock dataset.
It would be good to have some method that will calculate standard values, such as mininum/maximum variable values on a per block basis, and have the results listed out neatly in a table. For example, if each material block had a `density` variable, have a method to compute the local minimum and maximum density value of each block, and list them out in a table.
@patchett2002 @berkgeveci @cory.quammenYohann Bearzi (Kitware)Yohann Bearzi (Kitware)https://gitlab.kitware.com/paraview/paraview/-/issues/21849Temporal data with SpreadSheet View crash remote server sometimes when updati...2024-01-27T14:53:55-05:00W. Alan ScottTemporal data with SpreadSheet View crash remote server sometimes when updating progressWe have a crash with the spreadsheet view and remote server related to progress updates
* master (v5.11.1-RC1-906-gbbaa7a81bd), Linux, remote server (1 rank).
* Load can.e4.[0-3]. Apply.
* Split Screen hozizontal, spreadsheet view. Tu...We have a crash with the spreadsheet view and remote server related to progress updates
* master (v5.11.1-RC1-906-gbbaa7a81bd), Linux, remote server (1 rank).
* Load can.e4.[0-3]. Apply.
* Split Screen hozizontal, spreadsheet view. Turn eye ball on.
* Close RenderView
* Play forward, play back, play forward until it crashes.
Here is the output:
```
Wrong tag but don't know how to handle it... 102290
[cello:384883] *** Process received signal ***
[cello:384883] Signal: Aborted (6)
[cello:384883] Signal code: (-6)
[cello:384883] [ 0] /lib/x86_64-linux-gnu/libc.so.6(+0x42520)[0x75049ba42520]
[cello:384883] [ 1] /lib/x86_64-linux-gnu/libc.so.6(pthread_kill+0x12c)[0x75049ba969fc]
[cello:384883] [ 2] /lib/x86_64-linux-gnu/libc.so.6(raise+0x16)[0x75049ba42476]
[cello:384883] [ 3] /lib/x86_64-linux-gnu/libc.so.6(abort+0xd3)[0x75049ba287f3]
[cello:384883] [ 4] /home/local/KHQ/spiros.tsalikis/Programming/Cpp/ParaView/cmake-build-relwithdebinfo/bin/../lib/libvtkRemotingServerManager-pv5.12.so.1(_ZN18vtkSMSessionClient15OnWrongTagEventEP9vtkObjectmPv+0xcd)[0x750499c5c1ed]
[cello:384883] [ 5] /home/local/KHQ/spiros.tsalikis/Programming/Cpp/ParaView/cmake-build-relwithdebinfo/bin/../lib/libvtkCommonCore-pv5.12.so.1(+0x1d5b82d)[0x75049555b82d]
[cello:384883] [ 6] /home/local/KHQ/spiros.tsalikis/Programming/Cpp/ParaView/cmake-build-relwithdebinfo/bin/../lib/libvtkParallelCore-pv5.12.so.1(_ZN21vtkSocketCommunicator13ReceiveTaggedEPviiiPKc+0x230)[0x7504995edd30]
[cello:384883] [ 7] /home/local/KHQ/spiros.tsalikis/Programming/Cpp/ParaView/cmake-build-relwithdebinfo/bin/../lib/libvtkParallelCore-pv5.12.so.1(_ZN21vtkSocketCommunicator16ReceiveVoidArrayEPvxiii+0x150)[0x7504995f1db0]
[cello:384883] [ 8] /home/local/KHQ/spiros.tsalikis/Programming/Cpp/ParaView/cmake-build-relwithdebinfo/bin/../lib/libvtkParallelCore-pv5.12.so.1(_ZN15vtkCommunicator17ReceiveDataObjectEii+0x41)[0x7504995ce891]
[cello:384883] [ 9] /home/local/KHQ/spiros.tsalikis/Programming/Cpp/ParaView/cmake-build-relwithdebinfo/bin/../lib/libvtkPVVTKExtensionsFiltersRendering-pv5.12.so.1(_ZN23vtkClientServerMoveData11RequestDataEP14vtkInformationPP20vtkInformationVectorS3_+0x14e)[0x7504931c140e]
[cello:384883] [10] /home/local/KHQ/spiros.tsalikis/Programming/Cpp/ParaView/cmake-build-relwithdebinfo/bin/../lib/libvtkCommonExecutionModel-pv5.12.so.1(_ZN12vtkExecutive13CallAlgorithmEP14vtkInformationiPP20vtkInformationVectorS3_+0x58)[0x75049856a758]
[cello:384883] [11] /home/local/KHQ/spiros.tsalikis/Programming/Cpp/ParaView/cmake-build-relwithdebinfo/bin/../lib/libvtkCommonExecutionModel-pv5.12.so.1(_ZN23vtkDemandDrivenPipeline11ExecuteDataEP14vtkInformationPP20vtkInformationVectorS3_+0x3b)[0x75049855fc2b]
[cello:384883] [12] /home/local/KHQ/spiros.tsalikis/Programming/Cpp/ParaView/cmake-build-relwithdebinfo/bin/../lib/libvtkCommonExecutionModel-pv5.12.so.1(_ZN24vtkCompositeDataPipeline11ExecuteDataEP14vtkInformationPP20vtkInformationVectorS3_+0x89)[0x75049855bfd9]
[cello:384883] [13] /home/local/KHQ/spiros.tsalikis/Programming/Cpp/ParaView/cmake-build-relwithdebinfo/bin/../lib/libvtkCommonExecutionModel-pv5.12.so.1(_ZN23vtkDemandDrivenPipeline14ProcessRequestEP14vtkInformationPP20vtkInformationVectorS3_+0x34c)[0x750498562e9c]
[cello:384883] [14] /home/local/KHQ/spiros.tsalikis/Programming/Cpp/ParaView/cmake-build-relwithdebinfo/bin/../lib/libvtkCommonExecutionModel-pv5.12.so.1(_ZN32vtkStreamingDemandDrivenPipeline14ProcessRequestEP14vtkInformationPP20vtkInformationVectorS3_+0x381)[0x7504985dc941]
[cello:384883] [15] /home/local/KHQ/spiros.tsalikis/Programming/Cpp/ParaView/cmake-build-relwithdebinfo/bin/../lib/libvtkCommonExecutionModel-pv5.12.so.1(_ZN32vtkStreamingDemandDrivenPipeline6UpdateEiP20vtkInformationVector+0x11a)[0x7504985de0ba]
[cello:384883] [16] /home/local/KHQ/spiros.tsalikis/Programming/Cpp/ParaView/cmake-build-relwithdebinfo/bin/../lib/libvtkRemotingViews-pv5.12.so.1(_ZN18vtkSpreadSheetView18FetchBlockCallbackEx+0x184)[0x750491994804]
[cello:384883] [17] /home/local/KHQ/spiros.tsalikis/Programming/Cpp/ParaView/cmake-build-relwithdebinfo/bin/../lib/libvtkRemotingViews-pv5.12.so.1(_ZN18vtkSpreadSheetView10FetchBlockEx+0x98)[0x750491996298]
[cello:384883] [18] /home/local/KHQ/spiros.tsalikis/Programming/Cpp/ParaView/cmake-build-relwithdebinfo/bin/../lib/libvtkRemotingViews-pv5.12.so.1(_ZN18vtkSpreadSheetView18GetNumberOfColumnsEv+0x160)[0x750491991e60]
[cello:384883] [19] /home/local/KHQ/spiros.tsalikis/Programming/Cpp/ParaView/cmake-build-relwithdebinfo/bin/../lib/libpqCore-pv5.12.so.1(_ZNK22pqSpreadSheetViewModel11columnCountERK11QModelIndex+0x1c)[0x75049a7dd01c]
[cello:384883] [20] /lib/x86_64-linux-gnu/libQt5Core.so.5(_ZNK18QAbstractItemModel8hasIndexEiiRK11QModelIndex+0x60)[0x750496054c70]
[cello:384883] [21] /lib/x86_64-linux-gnu/libQt5Core.so.5(_ZNK19QAbstractTableModel5indexEiiRK11QModelIndex+0x32)[0x750496054cc2]
[cello:384883] [22] /lib/x86_64-linux-gnu/libQt5Widgets.so.5(_ZN10QTableView10paintEventEP11QPaintEvent+0x78a)[0x75049b243d2a]
[cello:384883] [23] /home/local/KHQ/spiros.tsalikis/Programming/Cpp/ParaView/cmake-build-relwithdebinfo/bin/../lib/libpqCore-pv5.12.so.1(_ZN23pqSpreadSheetViewWidget10paintEventEP11QPaintEvent+0x9b)[0x75049a7e2c5b]
[cello:384883] [24] /lib/x86_64-linux-gnu/libQt5Widgets.so.5(_ZN7QWidget5eventEP6QEvent+0x20e)[0x75049afaf4ee]
[cello:384883] [25] /lib/x86_64-linux-gnu/libQt5Widgets.so.5(_ZN6QFrame5eventEP6QEvent+0x22)[0x75049b05d422]
[cello:384883] [26] /lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN23QCoreApplicationPrivate29sendThroughObjectEventFiltersEP7QObjectP6QEvent+0xaa)[0x7504960b9b9a]
[cello:384883] [27] /lib/x86_64-linux-gnu/libQt5Widgets.so.5(_ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent+0x72)[0x75049af6c702]
[cello:384883] [28] /lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent+0x13a)[0x7504960b9e3a]
[cello:384883] [29] /lib/x86_64-linux-gnu/libQt5Widgets.so.5(_ZN14QWidgetPrivate14sendPaintEventERK7QRegion+0x3a)[0x75049afa743a]
[cello:384883] *** End of error message ***
```
Another way to reproduce it:
Using the Prism plugin remote server creates a crash. I was remote server with 16 ranks. No warning (no popup, nothing in the output view, no nothing.). I then tried running forward in time, and ended up with the following crash (possibly related to #21847). Crash is client side, as the server just says the socket died.
* master (v5.11.1-RC1-906-gbbaa7a81), Linux, remote server (16 ranks).
* Tools/ Manage Plugins. Prism. Load Selected.
* Load SymetricImpact2.hscth.
* Apply Table to Points filter. X Column == XPOSITION, Y Column == YPOSITION, Z Column == ZPOSITION. Apply. (Is this correct? Does it make sense to map X, Y and Z to Prism space?)
* Select RenderView, and turn on visibility for Table to Points filter.
* Load proxium.asc. Apply.
* Select PrismView. Turn on eyeball for Table to Points filter. We are attempting to put the data from the the SymetricImpact2.hscth dataset and proxium.asc into a PrismView.
@spiros.tsalikis @cory.quammen5.12.1 (Spring 2024)Spiros TsalikisSpiros Tsalikishttps://gitlab.kitware.com/paraview/paraview/-/issues/21741Catalyst needs to output warning when Catalyst version and script version dif...2023-03-01T15:02:12-05:00W. Alan ScottCatalyst needs to output warning when Catalyst version and script version differ.Catalyst needs to output a warning when Catalyst version and ParaView version that created script differ.Catalyst needs to output a warning when Catalyst version and ParaView version that created script differ.5.12 (Winter 2023)Spiros TsalikisSpiros Tsalikishttps://gitlab.kitware.com/paraview/paraview/-/issues/21630v5.11-RC2 crash on switching to 'Surface" representation for large grid2023-03-17T06:01:00-04:00Jean M. Favrev5.11-RC2 crash on switching to 'Surface" representation for large gridI have a simulation grid of size [21504x448x1120] saved in *.vtr format
I am loading it with 4 MPI tasks, and 32 threads available per task. I have plenty of memory (512 GB) and 4 GPUs (A100 with 96 GB each)
my TBB is /opt/intel/oneapi...I have a simulation grid of size [21504x448x1120] saved in *.vtr format
I am loading it with 4 MPI tasks, and 32 threads available per task. I have plenty of memory (512 GB) and 4 GPUs (A100 with 96 GB each)
my TBB is /opt/intel/oneapi/tbb/2021.2.0
Since the X dimension is much larger, the default UPDATE_SPLIT_MODE of the ExtentTranslator would split the data along the X direction. This results in very poor I/O performance.
So I am overriding the default split mode to use Z_SLAB_MODE
outInfo.Set(vtk.vtkExtentTranslator.UPDATE_SPLIT_MODE(), vtk.vtkExtentTranslator.Z_SLAB_MODE)
I have found out that I can load/create a grid of size up to [17058,448,1120] and this will work just fine. If I go over to [17059,448,1120], it will crash. The crash is here for my first process (0 out of 4):
```
Thread 1 "pvserver" received signal SIGTERM, Terminated.
0x00001489bc391da3 in tbb::detail::d1::start_for<tbb::detail::d1::blocked_range<long long>, vtk::detail::smp::FuncCall<vtk::detail::smp::UnaryTransformCall<int*, int*, vtk::detail::smp::FillFunctor<int> > >, tbb::detail::d1::auto_partitioner const>::execute(tbb::detail::d1::execution_data&) () from /scratch/e1000/jfavre/ParaView/ParaView-v5.11.0-RC2Build-cpeGNU-EGL/lib64/libvtkFiltersGeometry-pv5.11.so.1
(gdb) where
#0 0x00001489bc391da3 in tbb::detail::d1::start_for<tbb::detail::d1::blocked_range<long long>, vtk::detail::smp::FuncCall<vtk::detail::smp::UnaryTransformCall<int*, int*, vtk::detail::smp::FillFunctor<int> > >, tbb::detail::d1::auto_partitioner const>::execute(tbb::detail::d1::execution_data&) ()
from /scratch/e1000/jfavre/ParaView/ParaView-v5.11.0-RC2Build-cpeGNU-EGL/lib64/libvtkFiltersGeometry-pv5.11.so.1
#1 0x00001489e1753d33 in tbb::detail::r1::task_dispatcher::local_wait_for_all<false, tbb::detail::r1::external_waiter> (this=<optimized out>, t=0x1489a2317c00, waiter=...)
at /localdisk/ci/builds/YKkZxBPD/0/DeveloperProducts/Runtimes/Threading/onetbb/onetbb_source_code/src/tbb/task_dispatcher.h:315
#2 tbb::detail::r1::task_dispatcher::local_wait_for_all<tbb::detail::r1::external_waiter> (this=<optimized out>, t=<optimized out>, waiter=...)
at /localdisk/ci/builds/YKkZxBPD/0/DeveloperProducts/Runtimes/Threading/onetbb/onetbb_source_code/src/tbb/task_dispatcher.h:456
#3 tbb::detail::r1::task_dispatcher::execute_and_wait (t=0xff17fc, wait_ctx=..., w_ctx=...)
at /localdisk/ci/builds/YKkZxBPD/0/DeveloperProducts/Runtimes/Threading/onetbb/onetbb_source_code/src/tbb/task_dispatcher.cpp:168
#4 0x00001489bc38f387 in void vtk::detail::smp::ExecuteFunctorTBB<vtk::detail::smp::UnaryTransformCall<int*, int*, vtk::detail::smp::FillFunctor<int> > >(void*, long long, long long, long long) () from /scratch/e1000/jfavre/ParaView/ParaView-v5.11.0-RC2Build-cpeGNU-EGL/lib64/libvtkFiltersGeometry-pv5.11.so.1
#5 0x00001489e1efca60 in vtk::detail::smp::vtkSMPToolsImplForTBB(long long, long long, long long, void (*)(void*, long long, long long, long long), void*) ()
from /scratch/e1000/jfavre/ParaView/ParaView-v5.11.0-RC2Build-cpeGNU-EGL/lib64/libvtkCommonCore-pv5.11.so.1
#6 0x00001489bc39097d in void vtk::detail::smp::vtkSMPToolsImpl<(vtk::detail::smp::BackendType)2>::For<vtk::detail::smp::UnaryTransformCall<int*, int*, vtk::detail::smp::FillFunctor<int> > >(long long, long long, long long, vtk::detail::smp::UnaryTransformCall<int*, int*, vtk::detail::smp::FillFunctor<int> >&) ()
from /scratch/e1000/jfavre/ParaView/ParaView-v5.11.0-RC2Build-cpeGNU-EGL/lib64/libvtkFiltersGeometry-pv5.11.so.1
#7 0x00001489bc358e18 in (anonymous namespace)::ExtractCellBoundaries<int>::CreatePointMap(long long) ()
from /scratch/e1000/jfavre/ParaView/ParaView-v5.11.0-RC2Build-cpeGNU-EGL/lib64/libvtkFiltersGeometry-pv5.11.so.1
#8 0x00001489bc38b4d1 in int (anonymous namespace)::ExecuteStructured<int>(vtkGeometryFilter*, vtkDataSet*, vtkPolyData*, int*, vtkExcludedFaces<int>*, bool*) ()
from /scratch/e1000/jfavre/ParaView/ParaView-v5.11.0-RC2Build-cpeGNU-EGL/lib64/libvtkFiltersGeometry-pv5.11.so.1
#9 0x00001489bc38bd88 in vtkGeometryFilter::StructuredExecute(vtkDataSet*, vtkPolyData*, int*, vtkPolyData*, bool*) ()
from /scratch/e1000/jfavre/ParaView/ParaView-v5.11.0-RC2Build-cpeGNU-EGL/lib64/libvtkFiltersGeometry-pv5.11.so.1
#10 0x00001489dca58b33 in vtkPVGeometryFilter::ImageDataExecute(vtkImageData*, vtkPolyData*, int, int, int const*) ()
```
I am including a reproducer based on a simple ProgrammableSource(). The reproducer uses ImageData instead of RectilinearGrid, but it is the same crash happening.
[pvImageDataCreator.py](/uploads/f77aca42c3706becf3730fc59b0364f3/pvImageDataCreator.py)https://gitlab.kitware.com/paraview/paraview/-/issues/21359Fonts don't scale in split view screenshots saved using Macro2023-03-17T09:46:10-04:00Maxwell JacksonFonts don't scale in split view screenshots saved using MacroFontScaling=‘Scale fonts proportionally’ in SaveScreenshot function does not work in split views, but only when screenshot is saved from a macro script. The color bar labels and title comes out very large. Tested in 5.10.1 on MacOS.
To ...FontScaling=‘Scale fonts proportionally’ in SaveScreenshot function does not work in split views, but only when screenshot is saved from a macro script. The color bar labels and title comes out very large. Tested in 5.10.1 on MacOS.
To reproduce:
1. Use wavelet, add contour
2. Split the view horizontally (both render views), check eyeball on for wavelet and contour
3. Link cameras
4. Start Trace (default settings) and change to a smaller layout size (Lock View Size Custom in Tools, make sure to press Apply) and save a screenshot
5. Stop Trace and save trace as macro
6. Reset Session
7. Redo Steps 1-3
8. Run macro and compare screenshots
Image from Manual Screenshot
![6febdf1387963ff02011390e21522bf81b8a6009](/uploads/ccf8e11ffe9b435d592a80317d13f7ac/6febdf1387963ff02011390e21522bf81b8a6009.png)
Image from Macro Screenshot
![c85061c03846b48773d186c5bd052f7ffab44ccf](/uploads/46c2f38b693fcb0ad75241248068fa44/c85061c03846b48773d186c5bd052f7ffab44ccf.png)Yohann Bearzi (Kitware)Yohann Bearzi (Kitware)https://gitlab.kitware.com/paraview/paraview/-/issues/21268Make Ghost Cells Generator HTG compatible2022-03-14T10:43:47-04:00Yohann Bearzi (Kitware)Make Ghost Cells Generator HTG compatibleCurrently, the `Ghost Cells Generator` doesn't work for Hyper Tree Grids. There is a specific ghost cells generator for them called `Hyper Tree Grid Ghost Cells Generator`. `Ghost Cells Generator` should be HTG compatible and `Hyper Tree...Currently, the `Ghost Cells Generator` doesn't work for Hyper Tree Grids. There is a specific ghost cells generator for them called `Hyper Tree Grid Ghost Cells Generator`. `Ghost Cells Generator` should be HTG compatible and `Hyper Tree Grid Ghost Cells Generator` be removed with correct backward compatibility.Yohann Bearzi (Kitware)Yohann Bearzi (Kitware)https://gitlab.kitware.com/paraview/paraview/-/issues/20314v5.9-RC1 file is constantly re-opened and read when playing camera keyframes ...2020-11-20T08:43:47-05:00Jean M. Favrev5.9-RC1 file is constantly re-opened and read when playing camera keyframes animationThe issue raised https://discourse.paraview.org/t/xmlimagedatareader-keeps-re-executing-with-a-static-dataset-when-playing-keyframes-animation/5692 appears in v5.9-RC1. A reproducer is included on the discourse pageThe issue raised https://discourse.paraview.org/t/xmlimagedatareader-keeps-re-executing-with-a-static-dataset-when-playing-keyframes-animation/5692 appears in v5.9-RC1. A reproducer is included on the discourse page5.9 (Fall 2020)Utkarsh AyachitUtkarsh Ayachithttps://gitlab.kitware.com/paraview/paraview/-/issues/20277PV5.9 OSPRay pathtracer cylinders/lines are about 3x slower than PV5.82024-03-07T20:47:16-05:00Jean M. FavrePV5.9 OSPRay pathtracer cylinders/lines are about 3x slower than PV5.8testing PV5.8.1 against PV master (build with OSPRay 2.4) shows a slowdown of about 3x with the pathtracer.
@demarle has a copy of the test script.testing PV5.8.1 against PV master (build with OSPRay 2.4) shows a slowdown of about 3x with the pathtracer.
@demarle has a copy of the test script.5.13 (Summer 2024)David E. DeMarleDavid E. DeMarlehttps://gitlab.kitware.com/paraview/paraview/-/issues/20275pvtp files write incorrectly with time and a dot in name2024-03-07T20:47:16-05:00W. Alan Scottpvtp files write incorrectly with time and a dot in namePvtp files are being created incorrectly when there is an additional dot in the name. Here is how to replicate:
* Master (v5.8.1-1342-g1db9898), Linux, builtin server.
* In a terminal window external to ParaView, create a trash directo...Pvtp files are being created incorrectly when there is an additional dot in the name. Here is how to replicate:
* Master (v5.8.1-1342-g1db9898), Linux, builtin server.
* In a terminal window external to ParaView, create a trash directory. Mine is called junkDir. Make two directories in here, one called `goodA`, and one called `bad.B.` Notice the extra period.
* Load can.exo. Apply.
* Merge Blocks. Apply.
* Extract Surface. Apply.
Create good output
* File/ Save Data/ save in junkDir/goodA. File name is goodA. Files of type: .pvtp. OK. Write All Timesteps as a File Series. OK.
Look at directory goodA in a terminal window. This has created a good dataset, with time data. Try opening it. It is good, and shows all time data.
Create bad output
* File/ Save Data/ save in junkDir/bad.B. File name is bad.B. Files of type: .pvtp. OK. Write All Timesteps as a File Series. OK.
Look at this directory in a terminal window. This has created a bad dataset, I believe overwriting all time data in directory bad. Try opening it. Only the last timestep exists, over and over again.
Marking important, as there is a workaround. But this really needs to be fixed.5.13 (Summer 2024)https://gitlab.kitware.com/paraview/paraview/-/issues/20198WaveletPhiThetaExtractsWithCinema: incorrect image size when saving immediate...2020-09-10T13:58:17-04:00Utkarsh AyachitWaveletPhiThetaExtractsWithCinema: incorrect image size when saving immediate extracts`WaveletPhiThetaExtractsWithCinema` test does not save correct image size when saving immediate extracts...need to track it down.`WaveletPhiThetaExtractsWithCinema` test does not save correct image size when saving immediate extracts...need to track it down.5.9 (Fall 2020)Utkarsh AyachitUtkarsh Ayachithttps://gitlab.kitware.com/paraview/paraview/-/issues/19689resampleToImage filter sets color legend min wrong2024-03-07T20:47:12-05:00W. Alan ScottresampleToImage filter sets color legend min wrongThe ResampleToImage filter sets the min wrong on the color legend. The Rescale to Data Range fails, as does Rescale to Data Range over All Timesteps. The only workaround is to use Rescale to Custom Data Range.
Here is how to replicate...The ResampleToImage filter sets the min wrong on the color legend. The Rescale to Data Range fails, as does Rescale to Data Range over All Timesteps. The only workaround is to use Rescale to Custom Data Range.
Here is how to replicate:
* 5.8.0, Linux, builtin server.
* disk_out_ref.exo. All vars on. Apply.
* Color by Temp. Note the min and max. It is about 290 to 910.
* Volume Render. This is what it should look like.
* Resampe to Image. Apply.
Notice that the color legend is now 0 to 910. This is a bug.
Because this makes huge data difficult, and is confusing, marking as required.
@patchett2002 @boonth5.13 (Summer 2024)Yohann Bearzi (Kitware)Yohann Bearzi (Kitware)https://gitlab.kitware.com/paraview/paraview/-/issues/19234Clarifications and modifications to Global Ids2024-03-07T20:47:08-05:00W. Alan ScottClarifications and modifications to Global IdsFrom an e-mail thread with Utkarsh:
We surely have some confusion between the name of an array and it's
"attribute" type. To clarify, let's recollect that VTK has a notion of
an array that can be flagged as "GLOBAL_IDS". This means som...From an e-mail thread with Utkarsh:
We surely have some confusion between the name of an array and it's
"attribute" type. To clarify, let's recollect that VTK has a notion of
an array that can be flagged as "GLOBAL_IDS". This means something
very specific to all filters; it means that two elements with the same
"Global ID" are indeed the same and filters (such as D3) may use this
fact to speed things up. When any filter splits an element or creates
new elements, the GLOBAL_IDS in the input cannot be preserved (without
regenerating them) and hence they are often dropped -- this is the oft
seen issue where global ids suddenly disappears. At the same time, an
array maybe named "GlobalIds" or "GlobalElementId" or whatever. That
really doesn't mean anything for the VTK pipeline. Oftentimes the
array named GlobalIds is indeed the GLOBAL_IDS but not always. For
example, if you open disk_out_ref.ex2 and tetrahedralize it, the array
named "GlobalElementId" still exists in the output, but it's not
longer a GLOBAL_IDS as far as VTK/ParaView is concerned.
Following a discussion with Berk, here's a thought to make this more
streamlined:
* readers like Exodus which have unique ids for elements should indeed
add those arrays to the output and flag them as GLOBAL_IDS but name
the arrays using the format conventions e.g. ExodusNodeId,
ExodusElementId, exo_id or whatever makes sense.
* panels like spreadsheet view and information tab should explicitly
indicate which arrays are GLOBAL_IDS. That helps users identify them
irrespective of how they are named. Maybe different color for the
column in the Spreadsheet view, a different icon and tooltip in
Information tab, or something like that.
* filters that cannot preserve GLOBAL_IDS, such as contour etc, should
not drop them entirely instead flag them as PEDIGREE_IDS instead.
Thus, after such a filter, ExodusElementId array will not disappear
(as it does now) and continue to exist but will no longer be flagged
GLOBAL_IDS instead as PEDIGREE_IDS. While users don't really need to
know what the qualification of PEDIGREE_IDS means, it means that these
are the original GLOBAL_IDS that these elements came from. For all
intents and purposes, PEDIGREE_IDS notion can continue to stay
internal to VTK/ParaView. Currently, the PedigreeNodeId and
PedigreeElementId arrays are added by the Exodus reader. It should
stop doing that.
* the Point ID, Cell ID columns in the spreadsheet view are simply the
point's (or cell's) index in the local dataset. Maybe we rename them
to "Point Index" or "Cell Index" to avoid confusion with other IDs.
Thoughts?
Utkarsh
Then, from Watney:
* From a user's perspective, I don't mind that some variables "internal" to paraview are exposed; in fact it is necessary to understand what paraview is doing.
* It should be clear which variables are internal vs. which are read in. I'm fine with prefixing internal variables with vtk or something similar. For the processID example, I don't think it is far fetched that a simulation code running in parallel would write the processID to the output, and it should be easy to distinguish that from the processID for the parallel paraview session.
* Variable names should be consistent throughout.
* I think it would be helpful to have the exodus reader display variables ExodusGlobalElementID and ExodusGloalNodeID, etc., but I also recognize that for exodus this would probably be disruptive for backwards compatibility and that whoever writes a reader might have good reasons for not modifying that format's variable names. Maybe a checkbox to allow name munging?
* Where it makes sense, access to the mapping between internal variables and those read in should be accessible. (Of course, by variables here I mean mesh topology fields like block, cell, and point identifiers.) I guess this would have to be provided by the reader, since e.g., the exodus reader knows that exodus format defines a global element id and a global node id, and since it is a reader for paraview it should also know that the GlobalElementID is a VTK GLOBAL_IDS. On the other hand, structured cgns has no concept of a global cell id; it has blocks, and within each block there is i, j, k; if the cgns reader provided the (block, i, j, k) to GLOBAL_IDS mapping that would be great. One reason it would be great is then, in the FindData, the user could query for cells of (block, i, j, k) to get cells or lines or slices (in i, j, k space, not x, y, z space); without the reader providing this mapping, as a user I have to know how to get the internal GLOBAL IDS and then find the one that matches the (block, i, j, k) coordinate that I may be more familiar with. Of course, this extends beyond FindData to any place the user wants to identify a cell or point by the ID system of the mesh (mesh format) then ran their simulation on.
* Thank you for the explanation of GLOBAL_IDS and PEDIGREE_IDS, I never understood the distinction. I agree that that the behavior should be initially, an array is marked GLOBAL_IDS, on modification they are re-marked as PEDIGREE_IDS; and then also expose the new (internal) array marked GLOBAL_IDS. Also agree with Exodus reader behavior being modified.
* Perhaps the local Point ID and Cell ID should be consistently treated throughout paraview. If I can see those indices in the spreadsheet, I should be able to display them in the selection inspector, query on them in FindData, etc. Also, please be clear if they are indexes or IDs. (This applies to all the other variables we have been discussing; I think they have all been IDs.) I recognize that exposing these variables everywhere, as well as global ids and other reader-specific variables, might be excessive.
Thanks for digging into all this.
Watney5.13 (Summer 2024)Yohann Bearzi (Kitware)Yohann Bearzi (Kitware)https://gitlab.kitware.com/paraview/paraview/-/issues/19216Composable+Recolorable specD export of mandelbrot crashes2019-08-13T09:22:25-04:00Ethan StamComposable+Recolorable specD export of mandelbrot crashesTested on MacOS 10.13.6 with the 5.7.0-RC1 nightly binary
Follow along with #19215, but use the Mandelbrot source
* Enable and pick iterations in export inspector->advanced->data extracts->cinema image options
* Export a static cinem...Tested on MacOS 10.13.6 with the 5.7.0-RC1 nightly binary
Follow along with #19215, but use the Mandelbrot source
* Enable and pick iterations in export inspector->advanced->data extracts->cinema image options
* Export a static cinema image database with composable+recolorable selected
* Check "Save the cinema D table" as well
* File -> Export Now crashes my client
This seems too specific to worry about getting a fix in 5.7.0, as it is the only case we've found to cause the crash.
cc: @demarle @dhr5.7 (Summer 2019)https://gitlab.kitware.com/paraview/paraview/-/issues/19194Problems reading Truchas data2019-09-23T13:40:31-04:00John TourtellottProblems reading Truchas dataThere are two possibly-related issues with Truchas-generated hdf5 files loaded with our "TRUCHAS Reader".
1. When first loading the file, the Cell Arrays are missing. If you load the same file a second time, however, the cell arrays do ...There are two possibly-related issues with Truchas-generated hdf5 files loaded with our "TRUCHAS Reader".
1. When first loading the file, the Cell Arrays are missing. If you load the same file a second time, however, the cell arrays do get loaded.
2. When the cell data is loaded, the time snapshots appear to be incorrect. If the sequence of snapshots is labelled 0, 1, 2, ..., N, then what actually shows up in paraview is 0, 0, 1, 2, ..., N-1. The initial snapshot is duplicated and the final snapshot missing.
You can download an example file at https://data.kitware.com/api/v1/file/5d35f1e4877dfcc90223f5ba/download/preheat.h5 (79 MB). It has 6 cell data arrays: CENTROID, Grad_T, Z_ENTHALPY, Z_RHO, Z_TEMP, dTdt. The Z_TEMP is a good example of where the first two snapshots are the same (easy to see in the spreadsheet view).David E. DeMarleDavid E. DeMarlehttps://gitlab.kitware.com/paraview/paraview/-/issues/19042Inf and NaN values are not read in correctly for ascii datasets2019-08-07T17:09:57-04:00Boonthanome NouanesengsyInf and NaN values are not read in correctly for ascii datasetsParaview cannot correctly load an ascii data set which contains Inf and/or NaN. According to @demarle, it's related to this issue: https://stackoverflow.com/questions/11420263/is-it-possible-to-read-infinity-or-nan-values-using-input-str...Paraview cannot correctly load an ascii data set which contains Inf and/or NaN. According to @demarle, it's related to this issue: https://stackoverflow.com/questions/11420263/is-it-possible-to-read-infinity-or-nan-values-using-input-streams.
To reproduce, load the below file in Paraview. This should produce an error message about a data array being too short.
[pv_insitu_1_2_0.vtu](/uploads/a8651bff3b444fdb21eea9bcd6797858/pv_insitu_1_2_0.vtu).
@patchett20025.7 (Summer 2019)Feimi YuFeimi Yuhttps://gitlab.kitware.com/paraview/paraview/-/issues/18885Make Eye Dome Lightning not a plugin2020-01-21T12:33:08-05:00Ethan StamMake Eye Dome Lightning not a plugin@patchett2002 @demarle Please edit as you see fit.
There is interest at LANL to have Eye Dome Lightning integrated better in the build and test process of ParaView. Eye Dome Lighting should not be a plugin.@patchett2002 @demarle Please edit as you see fit.
There is interest at LANL to have Eye Dome Lightning integrated better in the build and test process of ParaView. Eye Dome Lighting should not be a plugin.5.8 (Winter 2020)David E. DeMarleDavid E. DeMarlehttps://gitlab.kitware.com/paraview/paraview/-/issues/18484Python time controls documentation is non existant2022-05-20T09:32:38-04:00W. Alan ScottPython time controls documentation is non existantThe animation section of the ParaView guide is totally unacceptable from a Python perspective. Please document how to do AT LEAST the following in Python:
* How to get handles to the time controls.
* Return how many timesteps there are...The animation section of the ParaView guide is totally unacceptable from a Python perspective. Please document how to do AT LEAST the following in Python:
* How to get handles to the time controls.
* Return how many timesteps there are.
* Return start time, return stop time.
* Go to first step, go to last step, go to next timestep, go to last timestep, go to N timestep, go to T time.
* How to change the mode.
* How to animate the camera. Include examples on the python setting up all 4 camera animations.5.11 (Spring 2022)Spiros TsalikisSpiros Tsalikishttps://gitlab.kitware.com/paraview/paraview/-/issues/17247OSPRay rendering in client-server mode does not remove interactive widgets wh...2023-02-22T05:37:45-05:00Jean M. FavreOSPRay rendering in client-server mode does not remove interactive widgets when asked toParaView 5.3 RC3 in client-server mode
when switching the "Show Plane" button OFF, OSPRay still renders it, resulting in a non-usable image.
[Update 5.11 RC]
Still an issue for the box interactive widget at leastParaView 5.3 RC3 in client-server mode
when switching the "Show Plane" button OFF, OSPRay still renders it, resulting in a non-usable image.
[Update 5.11 RC]
Still an issue for the box interactive widget at leasthttps://gitlab.kitware.com/paraview/paraview/-/issues/16920ospray memory leak with time varying data2020-11-30T08:43:26-05:00David E. DeMarleospray memory leak with time varying dataopen up can.ex2 and turn on the memory inspector
play the animation in a loop. see memory climb rapidly at first but then more or less stop at the high water mark when all the steps have been seen (and saved in paraview's animation cach...open up can.ex2 and turn on the memory inspector
play the animation in a loop. see memory climb rapidly at first but then more or less stop at the high water mark when all the steps have been seen (and saved in paraview's animation cache no doubt). Stop the animation.
now turn on OSPRay and play again. see the memory continue to climb without bound.David E. DeMarleDavid E. DeMarle