Package Details: trilinos 16.0.0-1

Git Clone URL: https://aur.archlinux.org/trilinos.git (read-only, click to copy)
Package Base: trilinos
Description: algorithms for the solution of large-scale scientific problems
Upstream URL: http://trilinos.org
Keywords: computing scientific
Licenses: LGPL3
Provides: kokkos, trilinos-ml, trilinos-sacado, zoltan
Submitter: Alad
Maintainer: MartinDiehl
Last Packager: MartinDiehl
Votes: 5
Popularity: 0.001341
First Submitted: 2019-03-18 02:48 (UTC)
Last Updated: 2024-09-16 09:40 (UTC)

Required by (13)

Sources (1)

Pinned Comments

MartinDiehl commented on 2020-06-05 12:05 (UTC)

@hacksd: I had a look at the gtest issue, and I assume the following is happening: Trilinos brings its own version of gtest, hence the conflict with gtest. However, during build an existing gtest installation is required (in my case, the already installed trilinos package provides it). I'll figure out if this can be solved, but since disabling gtest works it's not on my list of priorities

I have disabled pyTrilinos in this package to have no dependency on python or python2. From https://trilinos.github.io/pytrilinos_faq.html, it seems that python3 is not supported. I also remember vaguely that even python2 (SWIG) caused problems. Also note that current gtest depends on python2.

Once gtest 1.10 (currently in testing) is available, I will see if trilinos works with a system-wide gtest.

Latest Comments

« First ‹ Previous 1 2 3 Next › Last »

pepijndevos commented on 2020-11-17 21:27 (UTC)

Would it be possible to extend the options for this package for use with Xyce? https://xyce.sandia.gov/documentation/BuildingGuide.html#parallelTrilinosCMake

drwells commented on 2020-06-19 15:12 (UTC)

@MartinDiehl You're right - I do not use panzer. Things work fine for me if I modify the PKGBUILD to only build the Trilinos packages I want to use (which is a pretty short list): I think its a problem with this particular release.

MartinDiehl commented on 2020-06-18 21:38 (UTC)

@drwells: I only use ml from Trilinos (via PETSc) and that does not cause any problems. As far as I understand, you do not use panzer. Have you tried to disable it?

drwells commented on 2020-06-18 20:58 (UTC)

I'm getting some problems when I try to run an application that links with Trilinos:

symbol lookup error: /usr/lib/libpanzer-disc-fe.so.12: undefined symbol: _ZN6panzer23getIntegrationRuleIndexEiRKNS_7WorksetERNS_22WorksetDetailsAccessorE

This looks like a problem with the build configuration - perhaps panzer should be disabled by default?

MartinDiehl commented on 2020-06-05 12:05 (UTC)

@hacksd: I had a look at the gtest issue, and I assume the following is happening: Trilinos brings its own version of gtest, hence the conflict with gtest. However, during build an existing gtest installation is required (in my case, the already installed trilinos package provides it). I'll figure out if this can be solved, but since disabling gtest works it's not on my list of priorities

I have disabled pyTrilinos in this package to have no dependency on python or python2. From https://trilinos.github.io/pytrilinos_faq.html, it seems that python3 is not supported. I also remember vaguely that even python2 (SWIG) caused problems. Also note that current gtest depends on python2.

Once gtest 1.10 (currently in testing) is available, I will see if trilinos works with a system-wide gtest.

hacksd commented on 2020-06-04 20:48 (UTC) (edited on 2020-06-04 20:49 (UTC) by hacksd)

@MartinnDiehi

  1. This is the issue with gtest:
- Searching for a lib in the set "gtest":
--   Searching for lib 'gtest' ...
-- NOTE: Did not find a lib in the lib set "gtest" for the TPL 'gtest'!
-- ERROR: Could not find the libraries for the TPL 'gtest'!
-- TIP: If the TPL 'gtest' is on your system then you can set:
     -Dgtest_LIBRARY_DIRS='<dir0>;<dir1>;...'
   to point to the directories where these libraries may be found.
   Or, just set:
     -DTPL_gtest_LIBRARIES='<path-to-libs0>;<path-to-libs1>;...'
   to point to the full paths for the libraries which will
   bypass any search for libraries and these libraries will be used without
   question in the build.  (But this will result in a build-time error
   if not all of the necessary symbols are found.)
-- ERROR: Failed finding all of the parts of TPL 'gtest' (see above), Aborting!

I required trilinos for elmerfem-git.

The trilinos-git has python2 as a dependency which is why I am not willing to give it a try. Do you think building from source is the only option?

MartinDiehl commented on 2020-06-04 06:54 (UTC) (edited on 2020-06-04 10:39 (UTC) by MartinDiehl)

@hacksd

  1. For some reasons, I don't have any issues with gtest. Could you elaborate which problems you are facing

  2. The error related to exodus seems to be an upstream bug, https://gitlab.kitware.com/vtk/vtk/issues/17774, https://bugs.gentoo.org/710356. I have patched this, but more patches are needed

hacksd commented on 2020-06-03 22:10 (UTC) (edited on 2020-06-04 20:39 (UTC) by hacksd)

Thanks for providing the package. I was facing issues with gtest, which I solved by disabling gtest in the PKGBUILD. Now I am facing this issue:

/usr/bin/ld: CMakeFiles/exodus.dir/src/ex_open_par.c.o:(.rodata+0x0): multiple definition of `exodus_unused_symbol_dummy_1'; 
CMakeFiles/exodus.dir/src/ex_create_par.c.o:(.rodata+0x0): first defined here
collect2: error: ld returned 1 exit status
make[2]: *** 
[packages/seacas/libraries/exodus/CMakeFiles/exodus.dir/build.make:4160: 
 packages/seacas/libraries/exodus/libexodus.so.12.18.1] Error 1

Any help is welcome.

MartinDiehl commented on 2020-04-27 18:53 (UTC)

@a.kudelin Why should I disable gtest?

a.kudelin commented on 2020-04-27 15:49 (UTC)

Please, remove strings containing 'gtest' from cmake configuration in PKGBUILD.

« First ‹ Previous 1 2 3 Next › Last »