Package Details: elmerfem-git 9.0.r3246.g89b896c9b-1

Git Clone URL: https://aur.archlinux.org/elmerfem-git.git (read-only, click to copy)
Package Base: elmerfem-git
Description: A finite element software for multiphysical problems
Upstream URL: http://www.elmerfem.org
Licenses: GPL-2.0-or-later
Conflicts: elmerfem
Provides: elmerfem
Submitter: saxonbeta
Maintainer: saxonbeta (bartus)
Last Packager: bartus
Votes: 7
Popularity: 0.43
First Submitted: 2015-02-11 21:21 (UTC)
Last Updated: 2024-10-13 16:18 (UTC)

Dependencies (43)

Required by (0)

Sources (2)

Latest Comments

« First ‹ Previous 1 2 3 4 5 Next › Last »

Tempel commented on 2015-05-03 01:15 (UTC)

m24kus: no, it's not supposed to do that. See my earlier comments from 2015-02-22, or the PKGBUILD I posted at https://gist.github.com/Tempel/804486b4b05672fb5f1c (which, by the way, I just updated to build ElmerPost).

drhooves commented on 2015-05-02 13:01 (UTC)

Is $pkgbuild supposed to prefix the path's in build()? No other package I looked up does this. Replacing: -DCMAKE_INSTALL_PREFIX=$pkgdir/usr -DELMER_SOLVER_HOME=$pkgdir/usr/share/elmersolver -DELMER_INSTALL_LIB_DIR=$pkgdir/usr/lib with: -DCMAKE_INSTALL_PREFIX:PATH=/usr -DELMER_SOLVER_HOME:PATH=share/elmersolver -DELMER_INSTALL_LIB_DIR:PATH=lib fixed the ckoresko secound error for me. > 2) After the compiling is done there's this: > rm: cannot remove 'blah blah blah /elmerfem-git/pkg/elmerfem-git/usr/lib/libparpack.so’: No such file or directory > rm: cannot remove 'blah blah blah /elmerfem-git/pkg/elmerfem-git/usr/lib/libarpack.so’: No such file or directory

Tempel commented on 2015-05-01 22:35 (UTC)

I've managed to partially work around the qwt issue by setting an extra option on the cmake command: -DQWT_LIBRARY=/usr/lib/qwt/libqwt.so That allows Elmer to build, but the library still isn't found at runtime. Fortunately, that's easy to work around just by setting the environment variable LD_LIBRARY_PATH=/usr/lib/qwt. This has been reported as a bug ( https://bugs.archlinux.org/task/44590 ) and will hopefully be fixed soon with an update to qwt. My mostly-working PKGBUILD can be found at: https://gist.github.com/Tempel/804486b4b05672fb5f1c but don't forget to set LD_LIBRARY_PATH yourself.

titep commented on 2015-04-24 12:52 (UTC)

I copy qwt .so's in /usr/lib : cp /usr/lib/qwt/libqwt.so* /usr/lib/. and modify the PKGBUILD in build section : cmake -DWITH_ELMERGUI:BOOL=TRUE -DWITH_MPI:BOOL=TRUE -DCMAKE_INSTALL_PREFIX=/usr \ -DWITH_VTK:BOOL=TRUE -DWITH_OpenMP:BOOL=TRUE -DWITH_QWT:BOOL=TRUE \ -DELMER_SOLVER_HOME=/usr/share/elmersolver -DELMER_INSTALL_LIB_DIR=/usr/lib Seems to work with makepkg and pacman -U

ckoresko commented on 2015-04-15 15:50 (UTC)

Quick follow-up on my previous post: Turns out that qwt 6.1.2-1 stores its .so files in /usr/lib/qwt, whereas 6.1.1-1 puts them in /usr/lib. You can get a previously-compiled Elmer going by creating file /etc/ld.so.conf.d/qwt.conf with contents '/usr/lib/qwt' and then do 'sudo ldconfig'. But that doesn't fix the QWT problem building elmerfem-git.

ckoresko commented on 2015-04-15 14:15 (UTC)

This package doesn't build on my system. There are two issues I know about: 1) The latest upgrade to qwt (6.1.1-1 -> 6.1.2-1) causes the build to error out early on with CMake Error: The following variables are used in this project, but they are set to NOTFOUND. Please set them or make sure they are set and tested correctly in the CMake files: QWT_LIBRARY (ADVANCED) linked by target "ElmerGUI" in directory blah blah blah This can be cured by reverting to the previous version of qwt. 2) After the compiling is done there's this: rm: cannot remove 'blah blah blah /elmerfem-git/pkg/elmerfem-git/usr/lib/libparpack.so’: No such file or directory rm: cannot remove 'blah blah blah /elmerfem-git/pkg/elmerfem-git/usr/lib/libarpack.so’: No such file or directory I don't know how to fix this one.

ckoresko commented on 2015-03-25 23:02 (UTC)

After a big struggle I got Elmer working reasonably well (well enough to go through the first GUI tutorial, at least). Here are some notes from that effort. Unfortunately the notes I'm deriving these from are a bit incoherent, since I was trying all kinds of different things: The PKGBUILD has a couple of issues: It has a dependency on opencascade, which will not link to Elmer (as far as I can tell). You want the oce package from the AUR – that provides an alternate version of OpenCascade. Note that OpenCascade is needed to be able to read .step files (among other things). NB: The fact that this package is named 'oce' rather than 'occ' makes it very hard to find! It doesn't include the cmake switch to link to occ -DWITH_OCC:BOOL=TRUE It doesn't build the tetgen plugin. I don't know how to fix that in the PKGBUILD, so I built it manually: cd elmerfem-git/src/elmerfem/misc/tetgen_plugin/plugin qmake; make; sudo make install sudo cp libtetplugin.so.1.0.0 /usr/bin/elmer/lib/ cd /usr/bin/elmer/lib sudo ln -sf libtetplugin.so.1.0.0 libtetplugin.so sudo ln -sf libtetplugin.so.1.0.0 libtetplugin.so.1 sudo ln -sf libtetplugin.so.1.0.0 libtetplugin.so.1.0 Add /usr/bin/elmer/lib to your LD_LIBRARY_PATH environment variable At this point it should be possible to get the test app (testmain) to run. The default netgen package doesn't work (on my system, at least): it dies on launch with: X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 155 (GLX) Minor opcode of failed request: 3 (X_GLXCreateContext) Value in failed request: 0x0 So use the netgen-svn package instead. The basic elmerfem and elmerfem-git packages build without incident, but launching ElmerGUI brings up a series of warning boxes that various components aren't found. To fix that, you have to define two environment variables: export ELMER_HOME=/usr export ELMERGUI_HOME=/usr/share/ElmerGUI export NETGENDIR=/usr/bin # Needed for netgen support, which you probably want Add /usr/lib/Togl1.7 to the LD_LIBRARY_PATH I also set some environment variables for OpenCascade, but am not sure whether they are needed: export CASROOT="/opt/opencascade" export PATH="$PATH:$CASROOT/bin" export LD_LIBRARY_PATH="${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}$CASROOT/lib" export CSF_LANGUAGE=us export MMGT_CLEAR=1 export CSF_EXCEPTION_PROMPT=1 export CSF_SHMessage="$CASROOT"/src/SHMessage export CSF_MDTVTexturesDirectory="$CASROOT"/src/Textures export CSF_XSMessage="$CASROOT"/src/XSMessage export CSF_StandardDefaults="$CASROOT"/src/StdResource export CSF_PluginDefaults="$CASROOT"/src/StdResource export CSF_XCAFDefaults="$CASROOT"/src/StdResource export CSF_StandardLiteDefaults="$CASROOT"/src/StdResource export CSF_UnitsLexicon="$CASROOT"/src/UnitsAPI/Lexi_Expr.dat export CSF_UnitsDefinition="$CASROOT"/src/UnitsAPI/Units.dat export CSF_IGESDefaults="$CASROOT"/src/XSTEPResource export CSF_STEPDefaults="$CASROOT"/src/XSTEPResource export CSF_XmlOcafResource="$CASROOT"/src/XmlOcafResource export CSF_GraphicShr="$CASROOT"/lib/libTKOpenGl.so

ckoresko commented on 2015-02-26 01:42 (UTC)

Thanks, Tempel! Following your suggestion I changed the cmake command to the following, and the package built and appeared to install correctly. cmake -DWITH_ELMERGUI:BOOL=TRUE -DWITH_MPI:BOOL=TRUE -DCMAKE_INSTALL_PREFIX=/usr \ -DWITH_VTK:BOOL=TRUE -DWITH_OpenMP:BOOL=TRUE -DWITH_QWT:BOOL=TRUE \ -DELMER_SOLVER_HOME=/usr/share/elmersolver -DELMER_INSTALL_LIB_DIR=/usr/lib

Tempel commented on 2015-02-22 02:53 (UTC)

Ignore my previous comment; everything was fixed by modifying just the cmake lines in the PKGBUILD. Removing all the $pkgdir references on those three lines made everything go to the right locations, so the rm and mv lines were able to do their jobs. After that, ElmerGUI was able to run, though I haven't tested any further.

« First ‹ Previous 1 2 3 4 5 Next › Last »