ParaView

http://www.paraview.org/

ParaView is an open-source, multi-platform data analysis and visualization application. Users can quickly build visualizations to analyze their data using qualitative and quantitative techniques. The data exploration can be done interactively in 3D or programmatically using ParaView's batch processing capabilities.

Refresh
Refresh
Source Files (show merged sources derived from linked package)
Filename Size Changed Actions
ParaView-v5.8.0.tar.xz 0049789116 47.5 MB 3 months
ParaViewGettingStarted-5.8.0.pdf 0001326335 1.26 MB 3 months
ParaViewGuide-5.8.0.pdf 0049311320 47 MB 3 months
_constraints 0000000121 121 Bytes 3 months
bundled_exodusii_add_missing_libpthread.patch 0000001385 1.35 KB 22 days
fix-3d48a287-support-new-api-cgio_read_data_type.patch 0000022445 21.9 KB about 2 months
fix-libharu-missing-m.patch 0000000575 575 Bytes 4 months
paraview-desktop-entry-fix.patch 0000000458 458 Bytes 3 months
paraview-rpmlintrc 0000000274 274 Bytes 3 months
paraview.changes 0000025319 24.7 KB 22 days
paraview.spec 0000009254 9.04 KB 22 days
Comments for paraview 11

Mark Olesen's avatar

openfoam wrote 29 days ago

Encountered problems trying to build plugins against the paraview-devel. The missing static libraries cause it to fail.

https://gitlab.kitware.com/paraview/paraview/-/issues/19706#note_746262


Atri Bhattacharya's avatar

badshah400 wrote 29 days ago

Guess we'll have to have a -devel-static pkg. Thanks for raising the issue, I'll try and do this today.


Mark Olesen's avatar

openfoam wrote 28 days ago

Thanks


Mark Olesen's avatar

openfoam wrote 25 days ago

Cannot download/test paraview-5.8 on leap15.1 (not built), but the 5.7 version doesn't load. Presumably the same issue will occur in 5.8:

paraview: symbol lookup error: /usr/bin/../lib64/libvtkh5part-pv5.7.so.1: undefined symbol: H5Oget_info

Just using paraview --version is enough to provoke this.


Atri Bhattacharya's avatar

badshah400 wrote 25 days ago

This isn't an issue; I think this happens because you have the more recent hdf5 libraries from science against which paraview 5.7 hasn't been built for Leap 15.1. I suggest using the version of paraview and hdf5 available from the Leap 15.1 main-oss repository. The other option is to get paraview building on 15.1 again, but that's beyond my abilities.


Mark Olesen's avatar

openfoam wrote 4 days ago

building on leap15.1 without ninja helps somewhat, or at least moves the problem further.


Atri Bhattacharya's avatar

badshah400 wrote 4 days ago

Not sure what you mean, but my recollection is that the build failure (for Leap 15.1) occurs during the configuring stage (i.e. when running cmake, since it doesn't find protobuf properly). ninja has nothing to do with this stage — it is used in the next stage when compiling the code.


Mark Olesen's avatar

openfoam wrote 3 days ago

I have pretty much gone past understanding any of this. What I do know is that I can build paraview-5.8.0 manually from source on my leap15.1 system but not with the RPM build. So I figured there must be a solution for leap15.1 with RPM, but just need to find it.

First change was to remove the cmake restriction, since my system has cmake-3.10.2-lp151.4.1.x86_64 installed which clearly does work. At the same time I of course also changed to non-external use for the protobuf. Having made this first change, I immediately noticed that after the initial config stage absolutely nothing else happened. So then next bit to examine was the fact that my manual build does not specify ninja. Removed the ninja build for leap15.1 and suddenly things progress much further.

In the next bits, I simply tried to do without external components as much as possible. In doing so, I noticed that the hdf5 includes from leap15.1 may potentially not fit with what the paraview/thirdparty sources expect (sorry have forgotten which error message now). So explicitly disabled external use for hdf5 and proceeded much further. Now stuck with link errors for various math functions (pow, lroundf,...). It appears that the RPM link might be doing something different here.

None of this really seems to make much sense, but perhaps a more systematic approach will yield results. In any case, limiting the cmake version makes the whole problem disappear by simply not building on leap15.1, but doesn't really solve things. Of course, another answer could be just to hope that leap15.2 comes out soonish and we ignore leap15.1 entirely.


Atri Bhattacharya's avatar

badshah400 wrote 3 days ago

Limiting cmake to a version that supplies protobuf.cmake, which paraview's cmake script explicitly looks for, is the right solution. Perhaps you should see if the cmake maintainers would like to update the version of cmake in 15.1 or patch it to provide the protobuf file instead (either by using bugzilla or sending them an email).

Otherwise, can't you simply aggregatepac the pkg cmake from devel:tools:building into your home branch project? That should resolve the unresolvable status for 15.1 and start building it. I don't think you need any modifications to paraview's spec file really.

Btw, if it compiles on your system using cmake 3.10 from Leap 15.1, it probably reverts to using the internally bundled protobuf (something we would like to avoid for system packages as much as possible).


Mark Olesen's avatar

openfoam wrote 3 days ago

can we aggerate this one for use in science? https://build.opensuse.org/package/show/devel:tools:building/cmake

not sure how building things in my home helps if we would like to have an updated paraview/paraview-devel working for science.


Atri Bhattacharya's avatar

badshah400 wrote 3 days ago

I would be okay with it, but imo it needs more discussion and something of a consensus amongst other maintainers of the science project.