The new stable 3.4.0 version of paraview is out: http://www.paraview.org/files/v3.4/paraview-3.4.0.tar.gz Reproducible: Always
Thank you very much for the note. Unfortunately, this version also has trouble with Qt-4.4.2 (at least for me) and the 3D view and I have yet to track down why. If somebody has any pointers please let me know. Thanks, Markus
Can you post your current ebuild and the patches for that? Then I can have a look at it. Thanks, Oliver
I'll commit them later and masked them so we can all have a look at it. Best, Markus
paraview-3.4.0 is now in portage, albeit masked until the GUI issues have been sorted out. Best, Markus
I've tested it on a x86 machine with x11-libs/qt-4.3.3. It compiles without any problems and I can load vtm and (p)vts files. But the OpenFOAM reader doesn't work properly. This is the output, if I want to open an openfoam case with paraview-3.4.0 (the same case works fine with paraview-3.3.0_pre): $ paraview ERROR: In /var/tmp/portage/sci-visualization/paraview-3.4.0/work/ParaView-3.4.0/Servers/Common/vtkProcessModule.cxx, line 1079 vtkProcessModule (0x81d9540): Cannot create object of type "vtkPOpenFOAMReader". while processing Message 0 = New Argument 0 = string_value {vtkPOpenFOAMReader} Argument 1 = id_value {83} ERROR: In /var/tmp/portage/sci-visualization/paraview-3.4.0/work/ParaView-3.4.0/Servers/Common/vtkProcessModule.cxx, line 1080 vtkProcessModule (0x81d9540): Aborting execution for debugging purposes. Why is paraview-3.4.0 installed in /usr/lib/paraview-3.3? Furthermore, is it possible to change back to EAPI="1" till portage-2.2 becomes stable? I really don't want to upgrade all workstations to an unstable portage version, just for paraview-3.4.0. Thanks for the ebuild, Oliver
(In reply to comment #5) > I've tested it on a x86 machine with x11-libs/qt-4.3.3. It compiles without any > problems and I can load vtm and (p)vts files. But the OpenFOAM reader doesn't > work properly. This is the output, if I want to open an openfoam case with > paraview-3.4.0 (the same case works fine with paraview-3.3.0_pre): > Hi Oliver, Thank you very much for testing and I am glad to hear that all is well with Qt-4.3.3. Qt-4.4 is still broken for me atm. I've fixed the install location and reverted back to EAPI=1 for now even though eventually I'd really like to go to 2. I re-did the OpenFOAM patch to use a slightly older version (basically the one used for paraview-3.3). Please let me know if it is still broken since I haven't tested it myself. If the plugin still does not work as expected would you perhaps be able to please post the foam example file so I can have a look. Thanks in advance. cheers, Markus
Hi Markus, the new ebuild works well an amd64 with nvidia drivers and on x86 with X11 drivers. I can load vtm, (p)vts and OpenFOAM cases. Also I can use the paraview python module. Both machines have installed qt-4.3.3. Is it possible to do the installation into /usr/lib/paraview-3.4? Because `paraview -V` gives me only the major and minor version back. So it will be hard to detect the micro version. I need this all, to append the /usr/lib/paraview-?.? path to the sys.path in python in a scriptable way, in order to load the paraview module. I know that EAPI="2" will bring several advantages, but I think we should wait to use them till portage-2.2 is stable. So, in my opinion the paraview-3.4.0 ebuild should use EAPI="1" in that time. Thanks, Oliver
(In reply to comment #7) > Hi Markus, > > the new ebuild works well an amd64 with nvidia drivers and on x86 with X11 > drivers. I can load vtm, (p)vts and OpenFOAM cases. Also I can use the paraview > python module. Both machines have installed qt-4.3.3. > Great, thank you very much for testing! The only remaining bit then seems to bit that darn qt-4.4.2 issue :( Well, I guess I won't be bored over the weekend then ;) > Is it possible to do the installation into /usr/lib/paraview-3.4? Because > `paraview -V` gives me only the major and minor version back. So it will be > hard to detect the micro version. I need this all, to append the > /usr/lib/paraview-?.? path to the sys.path in python in a scriptable way, in > order to load the paraview module. Yes, absolutely. I'll fix this soon. cheers, Markus
Thanks for the ebuild Markus. I have qt 4.4.2, though I can't see the problem you are pointing to. It is worth a note that the binary version that they ship has qt-4.3.5, so maybe qt-4.4 has not been tested yet. I don't think forcing EAPI=1 should be necessary for a masked ebuild.
(In reply to comment #9) > Thanks for the ebuild Markus. I have qt 4.4.2, though I can't see the problem > you are pointing to. Thank you very much for the feedback and it is good to know that other people have no such problems with qt-4.4.2. The issue could very well be specific to my setup but it is 100% reproducible. Best, Markus
Created attachment 170657 [details] OpenFOAM patch (see the included INSTALL file to apply) As to the OpenFOAM patch can you try the attached one? To install please see the included INSTALL file. P.S. FYI: It's now under review by Kitware but still has not included in the official source.
Created attachment 170661 [details] To load the case, open OpenFOAMSerialCase.foam included in the archive Here's a serial-run testcase (OpenFOAMSerialCase.tar.gz) so that Markus can test the reader. To load the case, open OpenFOAMSerialCase.foam included in the archive.
Created attachment 170667 [details] a parallel-run testcase (to load the case, open OpenFOAMParallelDecomposedCase.foam, set Case Type in the GUI to Decomposed Case and hit Apply) A parallel-run testcase. To load the case, open OpenFOAMParallelDecomposedCase.foam, set Case Type selection in the GUI to Decomposed Case and hit Apply.
Hi Takuya, Thank you very much for the patches, particularly the test cases. I appreciate your help. I'll give these a try as soon as I find some time ;) best, Markus
I've added the new OpenFOAM patch the the paraview-3.4.0 ebuild. It seems to work fine and loads the posted foam test cases just fine (thanks again for providing them). One minor wrinkle: Currently, vtkOpenFOAMReader.cxx unconditionally includes vtkzlib/zlib.h which won't fly if paraview is compiled against the system zlib like we do in the ebuild. Hence, I've replaced this by zlib.h in our patch. A more portable approach might be something like --- vtkOpenFOAMReader.cxx.old 2008-11-05 18:46:15.000000000 -0500 +++ vtkOpenFOAMReader.cxx 2008-11-05 18:48:55.000000000 -0500 @@ -60,7 +60,12 @@ #include "vtksys/DateStamp.h" #include "vtksys/SystemTools.hxx" #include <vtksys/ios/sstream> -#include <vtkzlib/zlib.h> + +#if defined(HAVE_VTK_ZLIB_H) +# include <vtkzlib/zlib.h> +#elif defined(HAVE_ZLIB_H) +# include <zlib.h> +#endif #include "vtkCellArray.h" #include "vtkCellData.h" Thanks again for the help. Best, Markus
Hello, the new version of the OpenFOAM reader works also fine for me, I've tested it with OF-1.4.1 and OF-1.5 cases. Thanks, Oliver
Guys thanks for the comments and the zlib fix :) I'll put it in my repository. I forgot to mention changes from the previous version: * Support for parallel reading of decomposed cases (new class vtkPopenFOAMReader) * Support for multiregion cases * Support for old mesh format (points/faces/cells) * labelField support for lagrangians * Changing case without reinstanciating the reader * Several bugfixes and small improvements
Markus: I also don't have any problems that are specific to qt-4.4.
(In reply to comment #18) > Markus: I also don't have any problems that are specific to qt-4.4. > Thanks much for the note! I've poked a bit more at this over the weekend and the issues I am having are definitely caused by my X setup combined with the newest nvidia drivers (177.80). Everything is fine with the nv driver as well as on one of my other machines that has an ATI card. Is anybody else running nvidia-drivers-177.80 and having issues? Thanks, Markus
> having are definitely caused by my X setup combined with the newest > nvidia drivers (177.80). Everything is fine with the nv driver > as well as on one of my other machines that has an ATI card. > Is anybody else running nvidia-drivers-177.80 and having issues? I've got 177.80 and don't seem to have problems as far as I know. x11-base/xorg-server 1.3.0.0-r6 x11-libs/libXmu-1.0.3 Using the nvidia opengl implementation. Let me know if you need other info.
I have run into problems trying to compile 3.4.0 on my x86. It compiled fine on my amd64. The compilation error I get is: "/var/tmp/paludis/sci-visualization-paraview-3.4.0/work/ParaView-3.4.0/Utilities/hdf5/H5Zdeflate.c: In function ' H5Z_filter_deflate': /var/tmp/paludis/sci-visualization-paraview-3.4.0/work/ParaView-3.4.0/Utilities/hdf5/H5Zdeflate.c:83: error: 'z_ stream' undeclared (first use in this function) /var/tmp/paludis/sci-visualization-paraview-3.4.0/work/ParaView-3.4.0/Utilities/hdf5/H5Zdeflate.c:83: error: (Ea ch undeclared identifier is reported only once /var/tmp/paludis/sci-visualization-paraview-3.4.0/work/ParaView-3.4.0/Utilities/hdf5/H5Zdeflate.c:83: error: for each function it appears in.) /var/tmp/paludis/sci-visualization-paraview-3.4.0/work/ParaView-3.4.0/Utilities/hdf5/H5Zdeflate.c:83: error: exp ected ';' before 'z_strm' /var/tmp/paludis/sci-visualization-paraview-3.4.0/work/ParaView-3.4.0/Utilities/hdf5/H5Zdeflate.c:91: error: 'z_ strm' undeclared (first use in this function) /var/tmp/paludis/sci-visualization-paraview-3.4.0/work/ParaView-3.4.0/Utilities/hdf5/H5Zdeflate.c:93: error: 'uI nt' undeclared (first use in this function) /var/tmp/paludis/sci-visualization-paraview-3.4.0/work/ParaView-3.4.0/Utilities/hdf5/H5Zdeflate.c:93: error: expected ';' before '_tmp_overflow2' /var/tmp/paludis/sci-visualization-paraview-3.4.0/work/ParaView-3.4.0/Utilities/hdf5/H5Zdeflate.c:93: error: expected ')' before '_tmp_overflow' /var/tmp/paludis/sci-visualization-paraview-3.4.0/work/ParaView-3.4.0/Utilities/hdf5/H5Zdeflate.c:93: error: '_tmp_overflow2' undeclared (first use in this function) /var/tmp/paludis/sci-visualization-paraview-3.4.0/work/ParaView-3.4.0/Utilities/hdf5/H5Zdeflate.c:95: error: expected ';' before '_tmp_overflow2' /var/tmp/paludis/sci-visualization-paraview-3.4.0/work/ParaView-3.4.0/Utilities/hdf5/H5Zdeflate.c:95: error: expected ')' before '_tmp_overflow' /var/tmp/paludis/sci-visualization-paraview-3.4.0/work/ParaView-3.4.0/Utilities/hdf5/H5Zdeflate.c:98: error: 'Z_OK' undeclared (first use in this function) /var/tmp/paludis/sci-visualization-paraview-3.4.0/work/ParaView-3.4.0/Utilities/hdf5/H5Zdeflate.c:104: error: 'Z_SYNC_FLUSH' undeclared (first use in this function) /var/tmp/paludis/sci-visualization-paraview-3.4.0/work/ParaView-3.4.0/Utilities/hdf5/H5Zdeflate.c:107: error: 'Z_STREAM_END' undeclared (first use in this function) /var/tmp/paludis/sci-visualization-paraview-3.4.0/work/ParaView-3.4.0/Utilities/hdf5/H5Zdeflate.c:150: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token ...." This is building with USE=-hdf5. If I try to build with USE=hdf5 or build with the same USE=-hdf5 on the amd64, it builds fine. If I try diff'ing the CMakeCache.txt from the x86 box against the amd64 box I get diff -u amd64cache x86cache | grep -i zlib -QT_ZLIB_LIBRARY:FILEPATH=/lib64/libz.so +QT_ZLIB_LIBRARY:FILEPATH=/lib/libz.so ZLIB_INCLUDE_DIR:PATH=/usr/include -ZLIB_LIBRARY:FILEPATH=/lib64/libz.so +ZLIB_LIBRARY:FILEPATH=/lib/libz.so //Details about finding ZLIB -FIND_PACKAGE_MESSAGE_DETAILS_ZLIB:INTERNAL=[/lib64/libz.so][/usr/include] +FIND_PACKAGE_MESSAGE_DETAILS_ZLIB:INTERNAL=[/lib/libz.so][/usr/include] -//Have include HAVE_ZLIB_H -HAVE_ZLIB_H:INTERNAL=1 +//Have includes HAVE_ZLIB_H +HAVE_ZLIB_H:INTERNAL= Similarly grepping for hdf did not yield anything interesting. Using cmake-2.6.2 on both systems. Not sure what is going on. Anyone else have similar experience?
Could you please post you complete CMakeCache (as an attachement) and possibly your emerge --info! According to your diff it almost looks like as if cmake picks up SYSTEM_ZLIB but then fails to define HAVE_ZLIB_H causing the zlib header to be missing. cheers, Markus
Created attachment 171995 [details] CMakeCache.txt that fails with USE=-hdf5
Created attachment 171997 [details] emerge --info for box that fails with USE=-hdf5
> and possibly your emerge --info! According to your diff it almost > looks like as if cmake picks up SYSTEM_ZLIB but then fails to > define HAVE_ZLIB_H causing the zlib header to be missing. Yes, I think so too, but I'm not sure why this is happening yet. I saw something on the cmake mailing list about changes to how the variable defined with -D for 2.6, so I will try installing with cmake 2.4 and see what happens.
same issue with cmake-2.4.8
I've problems with paraview, if qt4 is not installed with the png USE-flag. Can anybody reproduce that? So I think this should be captured in the ebuild. Furthermore I cannot compile paraview without the qt4 USE-flag at all. I don't think qt4 is optional for paraview, but I'm not 100% sure.
(In reply to comment #27) > I've problems with paraview, if qt4 is not installed with the png USE-flag. Can > anybody reproduce that? So I think this should be captured in the ebuild. > Could you please post the error and which qt4 version you are referring to? > Furthermore I cannot compile paraview without the qt4 USE-flag at all. I don't > think qt4 is optional for paraview, but I'm not 100% sure. It should be optional and works fine for me with USE="-qt4". Have you tried with MAKEOPTS="-j1", sometimes there are issues with parallel make. Thanks, Markus
(In reply to comment #28) > Could you please post the error and which qt4 version you are referring to? I can start the paraview GUI, but then there are no icons available. If a want to open a file, I get this Warning message: QPixmap::fromImage: Cannot convert a null image I've qt-4.3.3 installed on that server. > > It should be optional and works fine for me with USE="-qt4". Have you > tried with MAKEOPTS="-j1", sometimes there are issues with parallel > make. Ok, if I set MAKEOPTS="-j1" with USE="-qt4" I can compile paraview without problems. But then I have no paraview GUI, just the pvbatch, pvpython and pv*server utilities.
(In reply to comment #29) > (In reply to comment #28) > > Could you please post the error and which qt4 version you are referring to? > > I can start the paraview GUI, but then there are no icons available. If a want > to open a file, I get this Warning message: > > QPixmap::fromImage: Cannot convert a null image > > I've qt-4.3.3 installed on that server. > Yeah, png support will be required for the icons. I'll change the ebuild to check for png support in qt-4.3. > > > > It should be optional and works fine for me with USE="-qt4". Have you > > tried with MAKEOPTS="-j1", sometimes there are issues with parallel > > make. > > Ok, if I set MAKEOPTS="-j1" with USE="-qt4" I can compile paraview without > problems. But then I have no paraview GUI, just the pvbatch, pvpython and > pv*server utilities. > Well, that's exactly what the -qt4 flag is for: a headless server install. It looks like I'll have to force -j1 after all. cheers, Markus
Created attachment 177748 [details] screenshot with nvidia-drivers-177.82 As the nvidia-drivers-177.82 became stable, I got a problem with rendering in paraview-3.4.0 (see the attachment). The problem doesn't occur with the older nvidia-drivers-173.14.15. I've tried some different options in xorg.conf but with no success. Even the Option "AIGLX" "false" (http://openfoam.cfd-online.com/forum/messages/1/4438.html#POST14393), which solved problems for intel and sis graphic cards. The problem seems also to occur in other distros (https://bugs.launchpad.net/ubuntu/+source/paraview/+bug/294138). Maybe this problem is also related to bug 237177 and partially to bug 220477.
I've had to mask the qt4 useflag for this package, as 4.4.2 is going to be the only supported stable version, and 4.3.* is going to be hardmasked.
(In reply to comment #32) > I've had to mask the qt4 useflag for this package, as 4.4.2 is going to be the > only supported stable version, and 4.3.* is going to be hardmasked. > yes, during last update I have qt 4.4.2 and 3.3.8b-r1 installed but also paraview did recompiled {remerged} and now I am not able to start paraview GUI because qt4 use glaf is in brackets and with sign "-" please, let me know what to do, I need paraview for work. I did download paraview bin vrsion from their web and I can run that without problems.
(In reply to comment #32) > I've had to mask the qt4 useflag for this package, as 4.4.2 is going to be the > only supported stable version, and 4.3.* is going to be hardmasked. > I've got the same problem as comment #33. Maybe you want to mask the qt4 useflag only for version 4.3.*? Right now it is not possible to emerge a working Paraview at all!! Give the qt4 flag free!
Just to add another data point - I am using this version of paraview, had to unmask the use flag too. It works pretty well here, occasional glitches but I suspect these are driver issues. Using ~amd64, Nvidia binary drivers (180.27) and Qt 4.4.2. It would be good to get this ebuild out of package mask with its qt4 use flag.
I'm on amd64 and paraview-4.3.0 works without glitches for me. Also, using Qt-4.4.2 and nvidia binary drivers 177.82. Since these drivers are technically the "stable" version I believe that this package should be at least keyworded "~amd64". However, Qt-4.4.2 definitely breaks the latest paraview marked ~amd64... Hard masking this seems, at least to this user, a bit drastic from the results I am getting... Just my 2 cents. Thanks.
Actually I have compiled paraview 3.4 without problems when the qt4 flag was unmasked. Since it has been masked I haven't been able to recompile it. I also changed gcc in the meantime (4.3.2 to 4.3.3) so it may be related to that instead, cmake makes it very difficult to see what the problem is. My error: [ 95%] Building CXX object Servers/ServerManager/CMakeFiles/vtkPVServerManager.dir/vtkPVServerManagerInit.o [ 95%] Building CXX object Servers/ServerManager/CMakeFiles/vtkPVServerManager.dir/vtkPVServerManagerInstantiator.o Linking CXX shared library ../../bin/libvtkPVServerManager.so [ 95%] Built target vtkPVServerManager make: *** [all] Error 2 emerge --info Portage 2.2_rc26 (default/linux/x86/2008.0, gcc-4.3.3, glibc-2.9_p20081201-r2, 2.6.27-gentoo-r8 i686) ================================================================= System uname: Linux-2.6.27-gentoo-r8-i686-AMD_Athlon-tm-_XP_2600+-with-glibc2.0 Timestamp of tree: Thu, 19 Mar 2009 09:45:02 +0000 ccache version 2.4 [disabled] app-shells/bash: 3.2_p39 dev-java/java-config: 1.3.7-r1, 2.1.7 dev-lang/python: 2.5.2-r7 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r7 dev-util/cmake: 2.6.3 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.63 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.2 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=native -fomit-frame-pointer -pipe -fno-strict-aliasing" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -march=native -fomit-frame-pointer -pipe -fno-strict-aliasing" DISTDIR="/media/anthill/portage/distfiles" FEATURES="collision-protect distlocks fixpackages parallel-fetch preserve-libs protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="ftp://mirror.pacific.net.au/linux/Gentoo http://mirrors.tds.net/gentoo ftp://mirrors.tds.net/gentoo http://gentoo.eliteitminds.com" LDFLAGS="-Wl,--as-needed" LINGUAS="en_GB fr" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/media/anthill" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/sunrise /usr/portage/local/layman/science /usr/portage/local/layman/qting-edge /usr/local/portage /home/francois/Work/Gentoo-sage" SYNC="rsync://rsync.au.gentoo.org/gentoo-portage" USE="3dnow 3dnowext X a52 aac aalib acl acpi alsa amr ao apm asf audiofile berkdb bidi bootsplash branding bzip2 cairo cddb cdf cdparanoia cli composite cracklib crypt cups curl dbus device-mapper dga dmi dri dts dv dvd dvdr dvdread encode exif expat fb fbcon ffmpeg fftw flac fontconfig foomaticdb fortran fpx gdbm geoip gif gimpprint glib glitz glut gmp gpm graphviz gs gstreamer gtk gtk2 hal iconv id3tag idn imagemagick imlib imlib2 ipv6 ipython isdnlog jack java jbig joystick jpeg jpeg2k kde kdehiddenvisibility kpathsea ladspa lame lapack latex lcms libffi libsamplerate lzo mad mathml matroska midi mikmod mime mmx mmx2 mmxext mng motif mp3 mp4 mpeg mplayer mudflap musepack musicbrainz ncurses netcdf network nls nptl nptlonly ogg openal openexr opengl openmp pcre pdf perl png portaudio posix ppds pppd python qt3 qt4 quicktime readline reflection reiserfs sdl session sndfile sox spell spl sqlite3 sse ssl startup-notification svg svga sysfs szip t1lib tcl tcltk tcpd tetex tga theora tiff tk truetype unicode usb v4l2 vcd vidix vorbis wavpack webkit wmf x264 x86 xanim xattr xcb xcomposite xine xinerama xml xorg xpm xsl xv xvid xvmc zeroconf zlib" ALSA_CARDS="cmipci via82xx" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CAMERAS="canon ptp2" ELIBC="glibc" INPUT_DEVICES="evdev keyboard mouse joystick" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en_GB fr" USERLAND="GNU" VIDEO_CARDS="radeon" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
(In reply to comment #37) > My error: > [ 95%] Building CXX object > Servers/ServerManager/CMakeFiles/vtkPVServerManager.dir/vtkPVServerManagerInit.o > [ 95%] Building CXX object > Servers/ServerManager/CMakeFiles/vtkPVServerManager.dir/vtkPVServerManagerInstantiator.o > Linking CXX shared library ../../bin/libvtkPVServerManager.so > [ 95%] Built target vtkPVServerManager > make: *** [all] Error 2 > > dev-util/cmake: 2.6.3 Do you have checked, if it's working with the last stable cmake-2.6.2 or the oldstable cmake-2.4? Maybe it's a cmake error. If not, I would try the gcc-4.1.2, as this is the stable gcc.
(In reply to comment #38) > (In reply to comment #37) > > My error: > > [ 95%] Building CXX object > > Servers/ServerManager/CMakeFiles/vtkPVServerManager.dir/vtkPVServerManagerInit.o > > [ 95%] Building CXX object > > Servers/ServerManager/CMakeFiles/vtkPVServerManager.dir/vtkPVServerManagerInstantiator.o > > Linking CXX shared library ../../bin/libvtkPVServerManager.so > > [ 95%] Built target vtkPVServerManager > > make: *** [all] Error 2 > > > > dev-util/cmake: 2.6.3 > > Do you have checked, if it's working with the last stable cmake-2.6.2 or the > oldstable cmake-2.4? Maybe it's a cmake error. If not, I would try the > gcc-4.1.2, as this is the stable gcc. > I have downgraded to stable cmake and it didn't solve the issue. In view of the impeding stabilization of gcc-4.3 I wasn't willing to give it up. After learning about putting VERBOSE=1 in MAKEOPTS to get a verbose output from cmake I discovered a typical of parallel make failure. Building with -j1 instead of -j2 solved the problem. The failing target tries to link to the result of the next target: cd /media/anthill/portage/sci-visualization/paraview-3.4.0/work/build/Examples/All/Plugins/Filter && /usr/bin/cmake -E cmake_link_script CMakeFiles/SMMyElevation.dir/link.txt --verbose=1 /usr/bin/c++ -fPIC -O2 -march=native -fomit-frame-pointer -pipe -fno-strict-aliasing -Wno-deprecated -Wno-deprecated -Wl,--as-needed -shared -Wl,-soname,libSMMyElevation.so -o /media/anthill/portage/sci-visualization/paraview-3.4.0/work/build/bin/libSMMyElevation.so CMakeFiles/SMMyElevation.dir/vtkMyElevationFilter.o CMakeFiles/SMMyElevation.dir/vtkMyElevationFilterClientServer.o CMakeFiles/SMMyElevation.dir/SMMyElevationInit.o CMakeFiles/SMMyElevation.dir/vtkSMSMMyElevationInstantiator.o CMakeFiles/SMMyElevation.dir/vtkPVPluginInit_SMMyElevation.o -L/media/anthill/portage/sci-visualization/paraview-3.4.0/work/build/bin -L/usr/lib/python2.5/config -lvtkPVServerManager -lvtkPVFiltersCS -lvtkPVFilters -lvtkPVServerCommonCS -lvtkPVServerCommon -lvtkInfovisCS -lvtkInfovis -lvtkPVCommandOptions -lvtkPVPythonInterpretor /usr/lib/python2.5/config/libpython2.5.a -lutil -lvtkParallelCS -lvtkHybridCS -lvtkVolumeRenderingCS -lvtkVolumeRendering -lvtkWidgetsCS -lvtkWidgets -lvtkHybrid -lKWCommon -lvtkXdmfCS -lvtkRenderingCS -lvtkGenericFilteringCS -lvtkGenericFiltering -lvtkGraphicsCS -lvtkImagingCS -lvtkIOCS -lvtkFilteringCS -lvtkCommonCS -lvtkClientServer -lvtkXdmf -lXdmf -lvtkhdf5 -lm -lxml2 -lvtkParallel -lvtkRendering -lvtkIO -lvtkDICOMParser -lvtkmetaio -lvtksqlite -lpng -lz -ljpeg -ltiff -lexpat -lvtkGraphics -lvtkverdict -lvtkImaging -lvtkFiltering -lvtkCommon -lvtksys -lpthread -ldl -lm -lvtkftgl -lfreetype -lGL -lXt -lSM -lICE -lX11 -lXext -lvtkexoIIc -lvtkNetCDF -Wl,-rpath,/media/anthill/portage/sci-visualization/paraview-3.4.0/work/build/bin gmake[5]: Leaving directory `/media/anthill/portage/sci-visualization/paraview-3.4.0/work/build/Examples/All' gmake[4]: Leaving directory `/media/anthill/portage/sci-visualization/paraview-3.4.0/work/build/Examples/All' gmake[3]: Leaving directory `/media/anthill/portage/sci-visualization/paraview-3.4.0/work/build/Examples/All' /usr/lib/gcc/i686-pc-linux-gnu/4.3.3/../../../../i686-pc-linux-gnu/bin/ld: cannot find -lvtkPVServerManager collect2: ld returned 1 exit status gmake[5]: *** [/media/anthill/portage/sci-visualization/paraview-3.4.0/work/build/bin/libSMMyElevation.so] Error 1 gmake[4]: *** [Plugins/Filter/CMakeFiles/SMMyElevation.dir/all] Error 2 gmake[3]: *** [all] Error 2 make[2]: *** [ParaViewExamples] Error 1 make[2]: Leaving directory `/media/anthill/portage/sci-visualization/paraview-3.4.0/work/build' make[1]: *** [Examples/CMakeFiles/ParaViewExamplesTarget.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs.... [0mmake[2]: Leaving directory `/media/anthill/portage/sci-visualization/paraview-3.4.0/work/build' make -f Servers/ServerManager/CMakeFiles/vtkPVServerManager.dir/build.make Servers/ServerManager/CMakeFiles/vtkPVServerManager.dir/build make[2]: Entering directory `/media/anthill/portage/sci-visualization/paraview-3.4.0/work/build' /usr/bin/cmake -E cmake_progress_report /media/anthill/portage/sci-visualization/paraview-3.4.0/work/build/CMakeFiles /usr/bin/cmake -E cmake_progress_report /media/anthill/portage/sci-visualization/paraview-3.4.0/work/build/CMakeFiles [ 91%] [ 91%] [32mBuilding CXX object Servers/ServerManager/CMakeFiles/vtkPVServerManager.dir/vtkInitializationHelper.o
(In reply to comment #36) > I'm on amd64 and paraview-4.3.0 works without glitches for me. Also, using > Qt-4.4.2 and nvidia binary drivers 177.82. Since these drivers are technically > the "stable" version I believe that this package should be at least keyworded > "~amd64". However, Qt-4.4.2 definitely breaks the latest paraview marked > ~amd64... Hard masking this seems, at least to this user, a bit drastic from > the results I am getting... Just my 2 cents. Thanks. > Okay, not sure what the issue is here but paraview with the qt4 USE flag is still hardmasked. I have unmasked the latest version and with an amd64 system with nvidia drivers, the software is completely stable. My work flow as a researcher depends pretty heavily on Paraview and I'm sure others find it just as useful... Should this not be at least keyworded with the qt4 USE flag enabled. For those science minded folks using Gentoo without much background in portage I'm sure this would be mighty frustrating. Request to unmask the qt4 USE flag... please. I asked nicely. ;)
nick has a point here i think, paraview without qt4 support is really quite useless to a lot of people. plus, qt 4.4.2 is now stable in the tree. cheers! nico
also, all of qt-4.5.1 has gone stable on most architectures last week. this should give us a strong reason to reconsider the qt4-useflag blocker.
Whoops, just noticed that ParaView itself actually supports only Qt 4.3. Configuration with Qt 4.5.1 bails out with ============= *snip* ============= Qt 4.5.1 not supported. Please use Qt 4.3 (you may need to clean your dirtied cache). ============= *snap* ============= According to http://www.mail-archive.com/paraview@paraview.org/msg02858.html this won't change in the near future either. Anyone with successful compilations here? Cheers, Nico
Hm, this here http://public.kitware.com/cgi-bin/viewcvs.cgi/CMakeLists.txt?root=ParaView3&r1=1.96&r2=1.97 may work.
(In reply to comment #43) > this won't change in the near future either. Anyone with successful > compilations here? I'm running paraview 3.4.0 with QT 4.5.1 and it seems to be working just fine.
Just finished compiling the big boy, geez. Seems to be running now here on amd64, at least for what I need. Submitted a patch at bug #273086 that replaces the configuration error for >Qt-4.3 by a warning (taken from Kitware, see above). Cheers, Nico
As a heads up, Paraview 3.6 is supposed to come out any day now, which may change things.
Well, at least not on the Qt front: see link at comment #43.
(In reply to comment #46) > Just finished compiling the big boy, geez. Seems to be running now here on > amd64, at least for what I need. > Submitted a patch at bug #273086 that replaces the configuration error for > >Qt-4.3 by a warning (taken from Kitware, see above). > Compile and seems to run fine on x86 as well. I think a number of science devs who would normally care about paraview are missing in action at the moment. What's more it seems version 3.6 will include plenty more goodies, so it may take a bit to get the ebuild up to speed. So if no one has an objection I will push a patched and qt4 enabled paraview-3.4.0 in the science overlay soonish so that people can test and work with that.
(In reply to comment #49) > So if no one has an objection I will push a patched and qt4 enabled > paraview-3.4.0 in the science overlay soonish so that people can > test and work with that. > I don't think, that there is a serious reason for doing this. I would prefer, if it is needed, to patch the ebuild in the portage tree and not outside. Also I like to have qt4 disabled for my visualization servers.
(In reply to comment #50) > (In reply to comment #49) > > So if no one has an objection I will push a patched and qt4 enabled > > paraview-3.4.0 in the science overlay soonish so that people can > > test and work with that. > > > I don't think, that there is a serious reason for doing this. I would prefer, > if it is needed, to patch the ebuild in the portage tree and not outside. Also > I like to have qt4 disabled for my visualization servers. > It certainly would be better in the main tree but I am not sure how long it will take. I wasn't planning to force qt4, you would be able to use -qt4 as usual. From some of the comments in this bugs various people wants various things (as usual) and Gentoo in general tries to satisfies as many people as possible. Thanks for the feedback.
(In reply to comment #51) > It certainly would be better in the main tree but I am not sure how > long it will take. > Well that's right. Maybe we should discuss this on the science mailing, how to proceed, if the maintainer of an ebuild is more as 6 months away. And if it is then ok to bump it in the science overlay.
Folks, I've updated the paraview-3.4.0 ebuild a bit and it is now ready for qt-4.4 and 4.5. It compiles and works fine as far as I can tell. Please give it a whirl and let me know of any breakage. Unless there are major blockers I plan to unmask 3.4.0 asap once I've tracked down the person who can remove the qt4 use mask from the base profile. cheers, Markus
Created attachment 198025 [details, diff] EAPI2 useflags patch Hi Markus, No problem building it here, seems to run (x86). Since you moved to EAPI=2 I suggest this little patch to make the ebuild a bit cleaner. Francois
Hello, compilation is done fine on amd64, but I some problems. I think these are because of qt-4.5.*. As I can reproduce them also between ubuntu intrepid (qt-4.4.*) and ubuntu jaunty (qt-4.5.*). First I cannot open OpenFOAM cases anymore with the patched OpenFOAM reader. The following error messages occur: Warning: In /var/tmp/portage/sci-visualization/paraview-3.4.0/work/ParaView-3.4.0/VTK/IO/vtkOpenFOAMReader.cxx, line 3979 vtkOpenFOAMReaderPrivate (0x18af8f0): Different time directories with the same time value 0.224 and 0.264 found. 0.264 will be ignored. So only the first time step is loaded. If I convert the files to legacy vtk format (foamToVtk), I can load these files and all is fine. Second, the visualization of VRML files is very bad or in some cases not possible (Lego brick effect). I will attach an example wrl file and two png files. So is it possible to restrict the qt library to qt-4.4* for paraview-3.4.0? As upstream only supports qt-4.3, I'm not sure if this issues can be resolved. Oliver
Created attachment 198146 [details] VRML example
Created attachment 198147 [details] Blade screenshot as expected with qt-4.4*
Created attachment 198148 [details] Actual blade screenshot with qt-4.5*
Furthermore can you also install the python interface from /usr/lib/paraview/paraview/ into /usr/lib/python2.5/site-packages/paraview/ (or similar). So the paraview python interface can be imported by python automatically without setting any additional paths. Thanks, Oliver
(In reply to comment #54) > Created an attachment (id=198025) [edit] > EAPI2 useflags patch > > Hi Markus, > No problem building it here, seems to run (x86). > Since you moved to EAPI=2 I suggest this little patch > to make the ebuild a bit cleaner. > Francois > Thanks a lot. I'll add this to the ebuild.
(In reply to comment #55) > Hello, > > compilation is done fine on amd64, but I some problems. I think these are > because of qt-4.5.*. As I can reproduce them also between ubuntu intrepid > (qt-4.4.*) and ubuntu jaunty (qt-4.5.*). I really think we need to go with qt-4.5. 4.4 is already on its way out and it would be a major inconvenience to peg paraview's qt version at 4.4. Upstream has enabled qt-4.5 in svn so I presume the upcoming paraview-3.6 should work with it. Has anybody given 3.6 + qt4.5 a try yet? If paraview-3.4 is working well enough with qt-4.5 we could unmask it. If it is too crippled (like you show in your screenshots) we might want to wait for 3.6 which should come out soon (assuming it works with qt4.5). > > First I cannot open OpenFOAM cases anymore with the patched OpenFOAM reader. > The following error messages occur: > Are there any working OpenFOAM patches around for 3.4. The ones I am aware of are at http://sourceforge.net/projects/of-interfaces/. I'd appreciate if you could have a look and see if they work properly for your stuff. If yes, we can update the current patch, otherwise we might have to drop support for OpenFoam. Thanks much for all the help. Best, Markus
(In reply to comment #58) > Created an attachment (id=198148) [edit] > Actual blade screenshot with qt-4.5* > I just tried your blade.wrl with paraview and qt4.5.2 and it looks perfect (just like your qt4.4 screenshot). Can you make sure all is well with your qt4.5 install. Thanks, Markus
Hello Markus, well I think my qt-4.5.1 installation (the stable one) should be ok, as I haven't got any error messages during installation. But I can test the qt-4.5.2 with paraview-3.4 next week. On ubuntu jaunty qt-4.5.0 is installed, so I haven't not yet tested qt-4.5.2 with paraview. Maybe the OpenFOAM reader problems also vanish with qt-4.5.2. If not we can test a newer version of the OpenFOAM reader from the svn: http://of-interfaces.svn.sourceforge.net/viewvc/of-interfaces/tags/ Maybe this one will work with qt-4.5*. Oliver
(In reply to comment #63) Hi Oliver, > Maybe the OpenFOAM reader problems also vanish with qt-4.5.2. If not we can > test a newer version of the OpenFOAM reader from the svn: > http://of-interfaces.svn.sourceforge.net/viewvc/of-interfaces/tags/ > Maybe this one will work with qt-4.5*. The reader core has no dependence with Qt so that's quite possibly a bug in the reader. I have corrected a bug in removing duplicated time directories but still not sure if it really solves your problem. Can you pull the reader from svn co https://of-interfaces.svn.sourceforge.net/svnroot/of-interfaces/branches/vtkPOpenFOAMReader-r23-VTKcontrib , replace vtkOpenFOAMReader.{cxx,h} and see if it works? Meanwhile, can I ask you to attach a listing of your case directory (ls -al)? Takuya
(In reply to comment #64) Hello Takuya, the old patch worked fine till approximately four weeks ago. Since then, I got this error message with all OpenFOAM cases. I don't know what has changed exactly and caused this trouble. > Meanwhile, can I ask > you to attach a listing of your case directory (ls -al)? This is the listing of the standard icoFoam/cavity test case: 0 0.1 0.2 0.3 0.4 0.5 constant system Where the error also occur. I will test your new version soon. Thanks, Oliver
Created attachment 198685 [details] paraview-3.4.0-POpenFOAM-r119.patch I applied this patch to the paraview-3.4.0 ebuild but the error still remains: Warning: In /var/tmp/portage/sci-misc/paraview-3.4.0/work/ParaView-3.4.0/VTK/IO/vtkOpenFOAMReader.cxx, line 4285 vtkOpenFOAMReaderPrivate (0x1c8f430): Different time directories with the same time value 0 and 0.5 found. 0.5 will be ignored.
Oliver, Then it may not be a bug in the reader per se. Another possibility that comes to my mind is that you are affected by a locale problem that I reported on the OF Forum a while ago: http://www.cfd-online.com/Forums/openfoam-post-processing/65157-paraview-3-7-0-cvs-openfoam-reader-issues.html#post218689 Can you try running ParaView after exporting LANG=C? (In reply to comment #66) > Created an attachment (id=198685) [edit] > paraview-3.4.0-POpenFOAM-r119.patch > > I applied this patch to the paraview-3.4.0 ebuild but the error still remains: > > Warning: In > /var/tmp/portage/sci-misc/paraview-3.4.0/work/ParaView-3.4.0/VTK/IO/vtkOpenFOAMReader.cxx, > line 4285 > vtkOpenFOAMReaderPrivate (0x1c8f430): Different time directories with the same > time value 0 and 0.5 found. 0.5 will be ignored. >
(In reply to comment #67) Hello Takuya, > Can you try running ParaView after exporting LANG=C? Unfortunately, this doesn't help. But I have downgraded all my qt packages to version 4.4.2*, and this help. The error message doesn't occur anymore, the icoFoam/cavity case is the same. These are my installed qt packages: x11-libs/qt-assistant x11-libs/qt-core x11-libs/qt-dbus x11-libs/qt-gui x11-libs/qt-opengl x11-libs/qt-qt3support x11-libs/qt-script x11-libs/qt-sql x11-libs/qt-svg x11-libs/qt-test x11-libs/qt-webkit Do you have tested your OpenFoam reader with qt-4.5*?
(In reply to comment #68) Hi Oliver, Good to know it anyhow works again. > Do you have tested your OpenFoam reader with qt-4.5*? Not seriously as Qt 4.5 is not officially suppoted by Kitware yet, but It's working fine here with ParaView 3.7-cvs + Qt-4.5.0 under Ubuntu 9.04. I would rather attribute the problem to some subtle misconfiguration at either build- or run-time since the reader core does not depend on Qt. Takuya
Hello, I've now tested paraview also with qt-4.5.2 (all other packages are stable ones). But my two problems remain. The blade.wrl is rendered like in blade_qt45.png and also the OpenFOAM reader error remains. Oliver
(In reply to comment #70) I was able to reproduce your problems (the OpenFOAM reader error and the ragged VRML geometry of blade.wrl) under the aforementioned environment (PV 3.7-cvs + Qt 4.5.0, Ubuntu 9.04) when I set the locale to de_DE.UTF8 where I know from the OF forum thread above that comma (,) is assumed as decimal point. Hence basically I would attribute the problems to real numbers being truncated to integers due to periods (.) not being recognized as decimal points by atof() (which the VRML reader uses) and strtod() (which the OpenFOAM reader uses). I am not a Qt expert but if I try a vague guess this might be a changed behavior for Qt 4.5 because unless a program explicitly calls setlocale() the locale setting internally used should always be "C". Takuya
(In reply to comment #71) > I was able to reproduce your problems (the OpenFOAM reader error and the ragged > VRML geometry of blade.wrl) under the aforementioned environment (PV 3.7-cvs + > Qt 4.5.0, Ubuntu 9.04) when I set the locale to de_DE.UTF8 where I know from > the OF forum thread above that comma (,) is assumed as decimal point. Hello Takuya, thanks for your reply. I have had to change to LC_ALL=C, then both readers are working correctly. I don't needed to change the variables LANG=de_DE.utf8 and LANGUAGE=de_DE:de. Thanks for the hints, Oliver
(In reply to comment #72) > (In reply to comment #71) > > I was able to reproduce your problems (the OpenFOAM reader error and the ragged > > VRML geometry of blade.wrl) under the aforementioned environment (PV 3.7-cvs + > > Qt 4.5.0, Ubuntu 9.04) when I set the locale to de_DE.UTF8 where I know from > > the OF forum thread above that comma (,) is assumed as decimal point. > > Hello Takuya, > > thanks for your reply. I have had to change to LC_ALL=C, then both readers are > working correctly. I don't needed to change the variables LANG=de_DE.utf8 and > LANGUAGE=de_DE:de. > > Thanks for the hints, > Oliver > Very interesting and thanks much to Takuya for tracking this down to being a locale issue! That's quite weird I have to say. Which version of the OpenFoam plugin should I use for paraview-3.6.1? Is vtkPOpenFOAMReader-r64-20081005.tar.gz sufficient or is a recent svn snapshot the better solution? Thanks, Markus
(In reply to comment #73) > Which version of the OpenFoam plugin should I use for paraview-3.6.1? > Is vtkPOpenFOAMReader-r64-20081005.tar.gz sufficient or is a recent > svn snapshot the better solution? Hello Markus, I have tested the svn snapshot of the OpenFOAM reader with paraview-3.4.0 and it works so far for me. So I think we can test this version with paraview-3.6.1. Oliver
Created attachment 198886 [details] vtkPOpenFOAMReader for ParaView 3.6.1 see the included README to install
(In reply to comment #73) Hi Markus, > Which version of the OpenFoam plugin should I use for paraview-3.6.1? > Is vtkPOpenFOAMReader-r64-20081005.tar.gz sufficient or is a recent > svn snapshot the better solution? Attached another svn snapshot for ParaView 3.6.1 (vtkPOpenFOAMReader-r120.tar.bz2) which worked fine for me with ParaView 3.6.1 in a quick testing. As written in the included README, the snapshot contains a small additional UI code for some user convenience, but covered by the GPL (unlike the ParaView and the reader core which are covered by a BSDL). If that is acceptable, include the additional UI is appreciated. Otherwise, just including the BSDLed reader should be fine. Takuya
Another note: I think something has to be done for the locale problem but still haven't decided what to do. For the moment please set LC_ALL=C if one encounters the problem. Takuya
(In reply to comment #77) > Another note: I think something has to be done for the locale problem but still > haven't decided what to do. For the moment please set LC_ALL=C if one > encounters the problem. > > Takuya > Hi Takuya, Thank you very much for all the help with the OpenFoam patches and the locale issue. I've added your patches to the 3.6.1 ebuild. The GPL'd code should be fine but just to make sure I've split the patch into a BSD and GPL version so we can act on them individually in the future should the need arise. To everybody: I've just committed paraview-3.6.1 to portage. Please file any issues with 3.6.1 as new bugs. Also, if you post emerge failures or emerge logs I'd appreciate if you post ones generated with VERBOSE=TRUE MAKEOPTS="-j1" emerge paraview since otherwise the logs are very hard to decipher. cheers, Markus
