Trilinos issueshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues2016-12-10T03:19:17Zhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/904Check-in test script reports TCL errors2016-12-10T03:19:17ZJames WillenbringCheck-in test script reports TCL errors*Created by: mhoemmen*
```
sems-python/2.7.9(32):ERROR:102: Tcl command execution failed: if {[module-info mode remove]} {
set local_compiler_version $env(SEMS_PYTHON_LOCAL_COMPILER_VERSION)
unsetenv SEMS_PYTHON_LOCAL_COMPILER_VE...*Created by: mhoemmen*
```
sems-python/2.7.9(32):ERROR:102: Tcl command execution failed: if {[module-info mode remove]} {
set local_compiler_version $env(SEMS_PYTHON_LOCAL_COMPILER_VERSION)
unsetenv SEMS_PYTHON_LOCAL_COMPILER_VERSION
} else {
set local_compiler_version [semsModuleSupport::getCurrentVersion gcc]
setenv SEMS_PYTHON_LOCAL_COMPILER_VERSION $local_compiler_version
}
sems-python/2.7.9(32):ERROR:102: Tcl command execution failed: if {[module-info mode remove]} {
set local_compiler_version $env(SEMS_PYTHON_LOCAL_COMPILER_VERSION)
unsetenv SEMS_PYTHON_LOCAL_COMPILER_VERSION
} else {
set local_compiler_version [semsModuleSupport::getCurrentVersion gcc]
setenv SEMS_PYTHON_LOCAL_COMPILER_VERSION $local_compiler_version
}
```
The script still runs, apparently, but it reports the above errors every time I run it.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/906checkin-test-sems.sh cannot find module command from non-bash shells2016-12-10T03:17:12ZJames Willenbringcheckin-test-sems.sh cannot find module command from non-bash shells*Created by: kddevin*
In #895, it was discovered that checkin-test-sems.sh could not find the "module" command from shells that were not bash shells. The problem is not specific to Mac OS X; I can reproduce it on a RHEL system. Thus, ...*Created by: kddevin*
In #895, it was discovered that checkin-test-sems.sh could not find the "module" command from shells that were not bash shells. The problem is not specific to Mac OS X; I can reproduce it on a RHEL system. Thus, I am starting a new issue (but leaving much of the background in #895).
I think the issue with bash vs other shells is that
/usr/local/opt/modules/Modules/init/bash
defines the "module" command as a function for bash, while for other shells, "module" is defined as an alias (e.g., /usr/local/opt/modules/Modules/init/tcsh).
Aliases don't get transferred to the bash script checkin-test-sems.sh in the same way that the module function is.
http://unix.stackexchange.com/questions/1496/why-doesnt-my-bash-script-recognize-aliases
Thus, checkin-test-sems.sh fails to find the module command, and eventually fails.
A workaround is to run checkin-test-sems.sh from a bash script that first sources /usr/local/opt/modules/Modules/init/bash. Doing so is only a little hassle, but it allows checkin-test-sems.sh to at least launch correctly. If this workaround is the final solution, it needs to be documented somewhere (besides here). But perhaps there is a better solution that can be implemented within checkin-test-sems.sh.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/910Failing MueLu tests in CI build starting 12/7/20162016-12-09T20:25:26ZJames WillenbringFailing MueLu tests in CI build starting 12/7/2016*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @trilinos/muelu
**Description:**
A push last night broke two MueLu tests. The most current CI build still shows the failures:
* http://testing.sandia.gov/cdash/index.php?proj...*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @trilinos/muelu
**Description:**
A push last night broke two MueLu tests. The most current CI build still shows the failures:
* http://testing.sandia.gov/cdash/index.php?project=Trilinos&parentid=2646684&filtercount=3&showfilters=1&field1=groupname&compare1=61&value1=Continuous&field2=buildstarttime&compare2=84&value2=now&filtercombine=and
No one can use the checkin-test-sems.sh script to push while these tests are failing (unless they disable these tests which is what I did last night).https://gitlab.osti.gov/jmwille/Trilinos/-/issues/924Work-around (not a bug) for recent changes to check-in test script2016-12-22T23:08:54ZJames WillenbringWork-around (not a bug) for recent changes to check-in test script*Created by: mhoemmen*
I discussed this with @maherou , and he agreed that it would be helpful for me to post these instructions, as a way to smooth the eventual transition to a pull request model.
Suppose that you were using the (ol...*Created by: mhoemmen*
I discussed this with @maherou , and he agreed that it would be helpful for me to post these instructions, as a way to smooth the eventual transition to a pull request model.
Suppose that you were using the (old) check-in test script before. The #482 fix broke this process. If you want your old check-in test scripts to work, you'll need to do the following:
1. Change path to internal check-in.py script: `${TRILINOS_PATH}/cmake/tribits/ci_support/checkin-test.py` (replace `${TRILINOS_PATH}` with path to your Trilinos source directory)
2. Add the following arguments to the script: `--default-builds="" –extra-builds=MPI_DEBUG,SERIAL_RELEASE` (this removes that MPI_RELEASE_DEBUG_* build and replaces it with the old builds, and also enables all packages, not just Primary Tested)https://gitlab.osti.gov/jmwille/Trilinos/-/issues/930New "check-in policies page" gives incorrect directions 2016-12-15T21:15:10ZJames WillenbringNew "check-in policies page" gives incorrect directions *Created by: mhoemmen*
The following page:
https://github.com/trilinos/Trilinos/wiki/Policies-|-Safe-Checkin-Testing
gives incorrect directions for running the new checkin-test-sems.sh script. It also does not mention anything ab...*Created by: mhoemmen*
The following page:
https://github.com/trilinos/Trilinos/wiki/Policies-|-Safe-Checkin-Testing
gives incorrect directions for running the new checkin-test-sems.sh script. It also does not mention anything about the `TRILINOS_DIR` environment variable.
@trilinos/framework https://gitlab.osti.gov/jmwille/Trilinos/-/issues/931emails are not being posted to MueLu or Ifpack2's developer's list2016-12-15T01:09:54ZJames Willenbringemails are not being posted to MueLu or Ifpack2's developer's list*Created by: jhux2*
@jwillenbring Emails to the MueLu developer's list are not being posted, and they are not showing up in the archive.*Created by: jhux2*
@jwillenbring Emails to the MueLu developer's list are not being posted, and they are not showing up in the archive.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/937CMake configure (runtime) tests and Cross compiling2017-03-17T01:00:11ZJames WillenbringCMake configure (runtime) tests and Cross compiling*Created by: jjellio*
I am having a problem configuring Trilinos using the Cray programming environment.
Specifically, I have ParMETIS and Zoltan2 enabled. Zoltan2 requires ParMETIS >= 4.0.3.
The test for this builds a simple bina...*Created by: jjellio*
I am having a problem configuring Trilinos using the Cray programming environment.
Specifically, I have ParMETIS and Zoltan2 enabled. Zoltan2 requires ParMETIS >= 4.0.3.
The test for this builds a simple binary that includes parmetis.h and checks that the version is sufficient.
The problem seems to be that on Mutrino, the node used for compiling is not the same ARCH as the target. E.g., Cray's CC sets -xCORE-AVX2 for haswell, but the login nodes actually support AVX1 only.
The offending configure step is part of the Find ParMetis macro:
> -- Performing Test HAVE_PARMETIS_VERSION_4_0_3
> -- Run Output:
> Please verify that both the operating system and the processor support Intel(R) MOVBE, F16C, FMA, BMI, LZCNT and AVX2 instructions.
In this case, the test that fails is:
cmake/TPLs/FindTPLParMETIS.cmake, which calls CHECK_C_SOURCE_RUNS. The test executable is built using the cray wrappers (CC/cc) and will not run because the system does not support the instruction set.
```
FUNCTION(CHECK_PARMETIS_HAS_VERSION_4_0_3 VARNAME)
SET(SOURCE
"
#include <stdio.h>
#include <parmetis.h>
int main()
{
if( PARMETIS_MAJOR_VERSION > 4 )
return 0;
if( PARMETIS_MAJOR_VERSION == 4 )
if( PARMETIS_MINOR_VERSION > 0 )
return 0;
if( PARMETIS_MAJOR_VERSION == 4 )
if( PARMETIS_MINOR_VERSION == 0 )
if( PARMETIS_SUBMINOR_VERSION >= 3 )
return 0;
return 1;
}
"
)
SET(CMAKE_REQUIRED_INCLUDES ${TPL_ParMETIS_INCLUDE_DIRS})
SET(CMAKE_REQUIRED_LIBRARIES ${TPL_ParMETIS_LIBRARIES})
SET(CMAKE_REQUIRED_FLAGS ${CMAKE_EXE_LINKER_FLAGS})
CHECK_C_SOURCE_RUNS("${SOURCE}" ${VARNAME})
ENDFUNCTION()
```
The output above is from instrumenting the CHECK_C_SOURCE_RUNS so I can see why it is failing. You can obtain the same error by copy the source from CMakeFiles/CMakeError.log and compiling it.
I am a bit confused as to why other configure checks do not fail, or is it that Trilinos' CMake avoids checks that require executing a built binary?
@trilinos/zoltan2 @bartlettroscoe https://gitlab.osti.gov/jmwille/Trilinos/-/issues/945checkin-test-sems.sh with GCC 4.7.2 fails on RHEL 72017-01-12T16:11:31ZJames Willenbringcheckin-test-sems.sh with GCC 4.7.2 fails on RHEL 7*Created by: tawiesn*
Using the new checkin-test-sems.sh script on a SEMS-enabled RHEL 7 machine fails.
Obviously, the script loads the modules
`sems-gcc/4.7.2` and `sems-cmake/3.5.2`
The `cmake` call crashes with the following e...*Created by: tawiesn*
Using the new checkin-test-sems.sh script on a SEMS-enabled RHEL 7 machine fails.
Obviously, the script loads the modules
`sems-gcc/4.7.2` and `sems-cmake/3.5.2`
The `cmake` call crashes with the following error message
> cmake: /projects/sems/install/rhel7-x86_64/sems/compiler/gcc/4.7.2/base/lib64/libstdc++.so.6: version `GLIBCXX_3.4.18' not found (required by cmake)
This is obviously a problem with the SEMS module for cmake.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/947checkin-test-sems.sh uses same -jN for ctest as for make2016-12-21T16:42:34ZJames Willenbringcheckin-test-sems.sh uses same -jN for ctest as for make*Created by: mhoemmen*
@trilinos/framework
checkin-test-sems.sh uses the same -jN argument for ctest as for make. This is a bad idea, because many tests use both MPI processes and threads.*Created by: mhoemmen*
@trilinos/framework
checkin-test-sems.sh uses the same -jN argument for ctest as for make. This is a bad idea, because many tests use both MPI processes and threads.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/951Belos: Work around ancient Doxygen version to display SolverFactory table cor...2016-12-22T19:23:31ZJames WillenbringBelos: Work around ancient Doxygen version to display SolverFactory table correctly *Created by: mhoemmen*
@trilinos/belos @trilinos/framework
The online Doxygen documentation linked from trilinos.org uses an ancient version of Doxygen that does not understand Markdown tables. Thus, I changed the documentation of ...*Created by: mhoemmen*
@trilinos/belos @trilinos/framework
The online Doxygen documentation linked from trilinos.org uses an ancient version of Doxygen that does not understand Markdown tables. Thus, I changed the documentation of Belos::SolverFactory to use an HTML table instead of a Markdown table. Hopefully this makes the table show up correctly.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/982Set up automated develop->master testing2017-05-04T20:45:37ZJames WillenbringSet up automated develop->master testing*Created by: jwillenbring*
@trilinos/framework
To set up an automated test for develop->master testing we need to finish the following tasks:
1. Reconcile differences between the two current CI builds. Default in the direction of...*Created by: jwillenbring*
@trilinos/framework
To set up an automated test for develop->master testing we need to finish the following tasks:
1. Reconcile differences between the two current CI builds. Default in the direction of changing the old CI build to match the new one. (@jwillenbring)
2. Test reliability of return codes for automated builds. Strategy: modify existing Jenkins-initiated build with failures to a subset with no failures and see if build reports "pass". (@bmpersc)
3. Solve the issue of how we will push directly within a Jenkins job to master (authentication issue).
4. Set up a Jenkins job to run the automated testing that can also push to master when tests 100% pass.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/991Treatment of 'deprecated' warnings in builds2017-01-16T20:29:15ZJames WillenbringTreatment of 'deprecated' warnings in builds*Created by: dridzal*
@trilinos/framework @trilinos/muelu @trilinos/tpetra
The @trilinos/rol team has been seeing this warning for several months, so it may be good to register this as an issue (or at least document it). We don't k...*Created by: dridzal*
@trilinos/framework @trilinos/muelu @trilinos/tpetra
The @trilinos/rol team has been seeing this warning for several months, so it may be good to register this as an issue (or at least document it). We don't know if this is related to the internal compiler error (see below) --probably not. In any case, it was my understanding that we needed to keep the nightly builds clean of any warnings. If 'deprecated' doesn't fall into this category, should we not disable such warnings in said builds? Please advise on policy.
http://testing.sandia.gov/cdash/viewBuildError.php?type=0&buildid=2694326
In file included from /data/jenkins/slave/workspace/Trilinos_continuous/CONTINUOUS_MPI_OPT_DEV_SHARED/Trilinos/packages/muelu/src/Interface/../Utils/MueLu_Utilities_decl.hpp:59:0,
from /data/jenkins/slave/workspace/Trilinos_continuous/CONTINUOUS_MPI_OPT_DEV_SHARED/BUILD/packages/muelu/src/MueLu_Utilities.hpp:1,
from /data/jenkins/slave/workspace/Trilinos_continuous/CONTINUOUS_MPI_OPT_DEV_SHARED/Trilinos/packages/muelu/src/Interface/../MueCentral/MueLu_Level.hpp:68,
from /data/jenkins/slave/workspace/Trilinos_continuous/CONTINUOUS_MPI_OPT_DEV_SHARED/Trilinos/packages/muelu/src/Interface/../MueCentral/MueLu_Factory.hpp:65,
from /data/jenkins/slave/workspace/Trilinos_continuous/CONTINUOUS_MPI_OPT_DEV_SHARED/Trilinos/packages/muelu/src/Interface/../Smoothers/MueLu_SmootherPrototype_decl.hpp:52,
from /data/jenkins/slave/workspace/Trilinos_continuous/CONTINUOUS_MPI_OPT_DEV_SHARED/BUILD/packages/muelu/src/MueLu_SmootherPrototype.hpp:1,
from /data/jenkins/slave/workspace/Trilinos_continuous/CONTINUOUS_MPI_OPT_DEV_SHARED/Trilinos/packages/muelu/src/Interface/../Smoothers/MueLu_Ifpack2Smoother_decl.hpp:74,
from /data/jenkins/slave/workspace/Trilinos_continuous/CONTINUOUS_MPI_OPT_DEV_SHARED/BUILD/packages/muelu/src/MueLu_Ifpack2Smoother.hpp:1,
from /data/jenkins/slave/workspace/Trilinos_continuous/CONTINUOUS_MPI_OPT_DEV_SHARED/Trilinos/packages/muelu/src/Interface/../Smoothers/MueLu_SmootherCloner.hpp:56,
from /data/jenkins/slave/workspace/Trilinos_continuous/CONTINUOUS_MPI_OPT_DEV_SHARED/Trilinos/packages/muelu/src/Interface/../MueCentral/MueLu_Hierarchy_decl.hpp:59,
from /data/jenkins/slave/workspace/Trilinos_continuous/CONTINUOUS_MPI_OPT_DEV_SHARED/BUILD/packages/muelu/src/MueLu_Hierarchy.hpp:1,
from /data/jenkins/slave/workspace/Trilinos_continuous/CONTINUOUS_MPI_OPT_DEV_SHARED/Trilinos/packages/muelu/src/Interface/../Headers/MueLu.hpp:68,
from /data/jenkins/slave/workspace/Trilinos_continuous/CONTINUOUS_MPI_OPT_DEV_SHARED/Trilinos/packages/rol/example/PDE-OPT/poisson-boltzmann/../TOOLS/solver.hpp:68,
from /data/jenkins/slave/workspace/Trilinos_continuous/CONTINUOUS_MPI_OPT_DEV_SHARED/Trilinos/packages/rol/example/PDE-OPT/poisson-boltzmann/../TOOLS/pdeconstraint.hpp:54,
from /data/jenkins/slave/workspace/Trilinos_continuous/CONTINUOUS_MPI_OPT_DEV_SHARED/Trilinos/packages/rol/example/PDE-OPT/poisson-boltzmann/example_01.cpp:62:
/data/jenkins/slave/workspace/Trilinos_continuous/CONTINUOUS_MPI_OPT_DEV_SHARED/Trilinos/packages/xpetra/src/CrsMatrix/Xpetra_TpetraBlockCrsMatrix.hpp: In instantiation of ‘void Xpetra::TpetraBlockCrsMatrix<Scalar, LocalOrdinal, GlobalOrdinal, Node>::getLocalDiagOffsets(Teuchos::ArrayRCP<long unsigned int>&) const [with Scalar = double; LocalOrdinal = int; GlobalOrdinal = int; Node = Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::Serial>]’:
/data/jenkins/slave/workspace/Trilinos_continuous/CONTINUOUS_MPI_OPT_DEV_SHARED/Trilinos/packages/rol/example/PDE-OPT/poisson-boltzmann/example_01.cpp:180:1: required from here
/data/jenkins/slave/workspace/Trilinos_continuous/CONTINUOUS_MPI_OPT_DEV_SHARED/Trilinos/packages/xpetra/src/CrsMatrix/Xpetra_TpetraBlockCrsMatrix.hpp:339:7: warning: ‘void Tpetra::Experimental::BlockCrsMatrix<S, LO, GO, N>::getLocalDiagOffsets(Teuchos::ArrayRCP<long unsigned int>&) const [with Scalar = double; LO = int; GO = int; Node = Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::Serial>]’ is deprecated (declared at /data/jenkins/slave/workspace/Trilinos_continuous/CONTINUOUS_MPI_OPT_DEV_SHARED/Trilinos/packages/tpetra/core/src/Tpetra_Experimental_BlockCrsMatrix_decl.hpp:660) [-Wdeprecated-declarations]
g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1001Get standard Trilinos CI build working with SEMS env with CMake 3.3+ on RHEL 72017-05-11T02:55:55ZJames WillenbringGet standard Trilinos CI build working with SEMS env with CMake 3.3+ on RHEL 7*Created by: bartlettroscoe*
The SEMS env for the GCC 4.7.2 stack used by the standard Trilinos CI build (#482) fails with CMake 3.3+ on RHEL 7 machines (see #945). This story is to find a way to fix things so that this env works out o...*Created by: bartlettroscoe*
The SEMS env for the GCC 4.7.2 stack used by the standard Trilinos CI build (#482) fails with CMake 3.3+ on RHEL 7 machines (see #945). This story is to find a way to fix things so that this env works out of the box on RHEL 7 without hacks.
Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/1002Upgrade standard Trilinos CI build env from GCC 4.7.2 to GCC 4.9.32017-05-15T14:28:29ZJames WillenbringUpgrade standard Trilinos CI build env from GCC 4.7.2 to GCC 4.9.3*Created by: bartlettroscoe*
**Next Action Status:**
Transition to GCC 4.9.3 for CI build is complete and CI server working well from 5/11 to 5/15/2017
**Blocking:** #1167
**CC:** @trilinos/framework
**Description:**
Now t...*Created by: bartlettroscoe*
**Next Action Status:**
Transition to GCC 4.9.3 for CI build is complete and CI server working well from 5/11 to 5/15/2017
**Blocking:** #1167
**CC:** @trilinos/framework
**Description:**
Now that an important internal Trilinos customer is moving from GCC 4.7.2 to 4.9.3, we should switch the [standard Trilinos CI build](https://github.com/trilinos/Trilinos/wiki/Policies-%7C-Safe-Checkin-Testing) to match. We have been promised that we can make this switch the first of Feb. 2017.
**Tasks:**
1. Try out CI build for all of Trilinos with GCC 4.9.3 SEMS module on branch gcc-4.9.3-ci-1002-and-yaml-cpp-1167 (see [below](https://github.com/trilinos/Trilinos/issues/1002#issuecomment-300805240) [Done]
2. Announce switch from GCC 4.7.2 to GCC 4.9.3 to trilinos-developers (see [below](https://github.com/trilinos/Trilinos/issues/1002#issuecomment-300880843)) [Done]
3. Change over post-push CI build to GCC 4.9.3 and update the build name replacing GCC-4.7.2 with GCC-4.9.3 on branch 'gcc-4.9.3-ci-1002-and-yaml-cpp-1167' (test locally) (see [below](https://github.com/trilinos/Trilinos/issues/1002#issuecomment-300912887)) [Done]
4. Do the switchover (in short order): (see [below](https://github.com/trilinos/Trilinos/issues/1002#issuecomment-300946627) [Done]
4.1. Merge and push the branch 'gcc-4.9.3-ci-1002-and-yaml-cpp-1167' to 'develop' [Done]
4.2. Kill and restart the CI server on ceerws1113 [Done]
4.3. Update all of the Trilinos GitHub wiki page documentation for change to GCC 4.9.3 (look for all links with GCC-4.7.2) [Done]
5. Watch CI build for a while and look out for issues ...
Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/1012Soft links in zip distribution2017-01-21T22:41:59ZJames WillenbringSoft links in zip distribution*Created by: dridzal*
I received an email from a collaborator at LANL, who downloaded the zip file from the github website. Apparently, his build fails due to soft links in CMakeLists files. I'm not sure I fully understand the issue, ...*Created by: dridzal*
I received an email from a collaborator at LANL, who downloaded the zip file from the github website. Apparently, his build fails due to soft links in CMakeLists files. I'm not sure I fully understand the issue, but here is the explanation:
_In the zip distribution, the CMakeLists.txt file for the poisson-inversion test was a soft-link, but it pointed to some kind of long regex list, apparently describing the lines they wanted in the file. I wasn't familiar with that type of soft-link, but I figure it's something the developers somehow use temporarily when they're testing something new. But it broke this configuration script, so I just replaced it with a regular CMakeLists.txt file for the two tests in that directory and it then it worked fine. The tests even ran and passed. You might want to pass this on to whoever controls the distribution, so they can update the zip file. The last time I tried to clone something from git-hub it didn't work because of our firewall. Maybe there's a workaround, but I don't know it, because I usually only use our local one._
Have you seen this?
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1039Trilinos 11.10.22017-05-14T05:16:17ZJames WillenbringTrilinos 11.10.2*Created by: aprokop*
@trilinos/framework @bmpersc @jwillenbring
On trilinos.org website one can download version 11.10.2 [here](https://trilinos.org/download/previous-releases/download-11-10/). However, I cannot figure out how to g...*Created by: aprokop*
@trilinos/framework @bmpersc @jwillenbring
On trilinos.org website one can download version 11.10.2 [here](https://trilinos.org/download/previous-releases/download-11-10/). However, I cannot figure out how to get the corresponding hash from trilinos source tags and/or branches. None of them seem to contain any combination of numbers 11, 10 and 2. The only thing I see is 11.10.1 release there.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1045Troubles with TPL HDF5 parallel2017-02-28T16:43:41ZJames WillenbringTroubles with TPL HDF5 parallel*Created by: jjellio*
Hello,
I am having a problem when building with HDF5. On this system, hdf5 is provided in both parallel and serial versions.
/opt/cray/pe/hdf5-parallel/1.8.16
/opt/cray/pe/hdf5/1.8.16
In the parallel's lib...*Created by: jjellio*
Hello,
I am having a problem when building with HDF5. On this system, hdf5 is provided in both parallel and serial versions.
/opt/cray/pe/hdf5-parallel/1.8.16
/opt/cray/pe/hdf5/1.8.16
In the parallel's lib directory, hdf5_fortran is a symbolic link to hdf5_fortran_parallel (the same for other hdf5 libs)
When I configure trilinos, it is not obvious which library names I should provide to TPL_HDF5_LIBRARIES.
If I use
` -D TPL_HDF5_LIBRARIES:PATH="${HDF5_ROOT}/lib/libhdf5hl_fortran.a;${HDF5_ROOT}/lib/libhdf5_fortran.a;${HDF5_ROOT}/lib/libhdf5_hl.a;${HDF5_ROOT}/lib/libhdf5.a;/usr/lib64/libz.a" \`
e.g., `hdf5hl_fortran.a; hdf5_fortran.a; hdf5_hl.a; hdf5.a; libz.a`
Then I have found some unit tests that want to link `-lhdf5hl_fortran_parallel -lhdf5_fortran_parallel`
For example, EpetraExt_View unit test
`/opt/cray/pe/craype/2.5.6/bin/CC -xCORE-AVX2 -mkl=parallel -g1 -std=c++11 -qopenmp -O3 -DNDEBUG -xCORE-AVX2 -mkl=parallel CMakeFiles/EpetraExt_View.dir/cxx_main.cpp.o -o EpetraExt_View.exe ../../src/libepetraext.a ../../../triutils/src/libtriutils.a ../../../epetra/src/libepetra.a ../../../teuchos/kokkoscomm/src/libteuchoskokkoscomm.a ../../../teuchos/kokkoscompat/src/libteuchoskokkoscompat.a ../../../teuchos/remainder/src/libteuchosremainder.a ../../../teuchos/numerics/src/libteuchosnumerics.a /usr/projects/hpcsoft/cle6.0/common/intel-clusterstudio/2017.1.024/compilers_and_libraries_2017/linux/mkl/lib/intel64/libmkl_intel_lp64.a /usr/projects/hpcsoft/cle6.0/common/intel-clusterstudio/2017.1.024/compilers_and_libraries_2017/linux/mkl/lib/intel64/libmkl_intel_thread.a /usr/projects/hpcsoft/cle6.0/common/intel-clusterstudio/2017.1.024/compilers_and_libraries_2017/linux/mkl/lib/intel64/libmkl_core.a /usr/projects/hpcsoft/cle6.0/common/intel-clusterstudio/2017.1.024/compilers_and_libraries_2017/linux/lib/intel64/libiomp5.a /usr/lib64/libpthread.a /usr/lib64/libm.a /usr/projects/hpcsoft/cle6.0/common/intel-clusterstudio/2017.1.024/compilers_and_libraries_2017/linux/mkl/lib/intel64/libmkl_intel_lp64.a /usr/projects/hpcsoft/cle6.0/common/intel-clusterstudio/2017.1.024/compilers_and_libraries_2017/linux/mkl/lib/intel64/libmkl_intel_thread.a /usr/projects/hpcsoft/cle6.0/common/intel-clusterstudio/2017.1.024/compilers_and_libraries_2017/linux/mkl/lib/intel64/libmkl_core.a /usr/projects/hpcsoft/cle6.0/common/intel-clusterstudio/2017.1.024/compilers_and_libraries_2017/linux/lib/intel64/libiomp5.a /usr/lib64/libpthread.a /usr/lib64/libm.a ../../../teuchos/comm/src/libteuchoscomm.a ../../../teuchos/parameterlist/src/libteuchosparameterlist.a ../../../teuchos/core/src/libteuchoscore.a ../../../kokkos/core/src/libkokkoscore.a /usr/lib64/libdl.a /opt/cray/pe/hdf5-parallel/1.8.16/INTEL/15.0/lib/libhdf5hl_fortran.a /opt/cray/pe/hdf5-parallel/1.8.16/INTEL/15.0/lib/libhdf5_fortran.a /opt/cray/pe/hdf5-parallel/1.8.16/INTEL/15.0/lib/libhdf5_hl.a /opt/cray/pe/hdf5-parallel/1.8.16/INTEL/15.0/lib/libhdf5.a /usr/lib64/libz.a -lhdf5hl_fortran_parallel -lhdf5_fortran_parallel`
Is there a recommended way for writing my configuration script to avoid this? One thought, is to specify BOTH the serial and parallel libnames back to back.. but that would require modifications to the script when linking serial vs parallel HDF5
```
-D TPL_ENABLE_Netcdf=ON \
-D Netcdf_INCLUDE_DIRS:PATH="${NETCDF_ROOT}/include" \
-D Netcdf_LIBRARY_DIRS:PATH="${NETCDF_ROOT}/lib" \
-D TPL_Netcdf_LIBRARIES:PATH="${NETCDF_ROOT}/lib/libnetcdf.a;${HDF5_ROOT}/lib/libhdf5hl_fortran.a;${HDF5_ROOT}/lib/libhdf5_fortran.a;${HDF5_ROOT}/lib/libhdf5_hl.a;${HDF5_ROOT}/lib/libhdf5.a;${PNETCDF_ROOT}/lib/libpnetcdf.a;/usr/lib64/libz.a" \
-D TPL_Netcdf_PARALLEL:BOOL=ON \
-D TPL_ENABLE_HDF5=ON \
-D HDF5_INCLUDE_DIRS:PATH="${HDF5_ROOT}/include" \
-D TPL_HDF5_LIBRARIES:PATH="${HDF5_ROOT}/lib/libhdf5hl_fortran.a;${HDF5_ROOT}/lib/libhdf5_fortran.a;${HDF5_ROOT}/lib/libhdf5_hl.a;${HDF5_ROOT}/lib/libhdf5.a;/usr/lib64/libz.a" \
```
@bartlettroscoe @trilinos/framework https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1047Add topics2017-09-21T21:09:10ZJames WillenbringAdd topics*Created by: aprokop*
Github has a new feature: [topics](https://github.com/blog/2309-introducing-topics) that allows for a better discoverability of projects on Github. Please consider adding it to the repository.
@trilinos/framework *Created by: aprokop*
Github has a new feature: [topics](https://github.com/blog/2309-introducing-topics) that allows for a better discoverability of projects on Github. Please consider adding it to the repository.
@trilinos/framework https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1091Set up automated testing with SuperLUDist enabled2017-02-24T16:00:22ZJames WillenbringSet up automated testing with SuperLUDist enabled*Created by: ibaned*
As pointed out in #410, #1083, and #1090, it would be valuable to have automated Trilinos testing that enables the SuperLUDist TPL.
@trilinos/framework *Created by: ibaned*
As pointed out in #410, #1083, and #1090, it would be valuable to have automated Trilinos testing that enables the SuperLUDist TPL.
@trilinos/framework https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1097TeuchosComm Requires MPI v2 but this is not tested for at compile time.2017-03-22T04:30:52ZJames WillenbringTeuchosComm Requires MPI v2 but this is not tested for at compile time.*Created by: jjellio*
Reported by David Hysom,
`MPI_Comm_create_keyval` is an MPI2 function, if a user attempts to build with MPI-1, they will get atleast the error below (potentially others?). Is there a compile time check for the M...*Created by: jjellio*
Reported by David Hysom,
`MPI_Comm_create_keyval` is an MPI2 function, if a user attempts to build with MPI-1, they will get atleast the error below (potentially others?). Is there a compile time check for the MPI spec the compiler supports? If not, attempting to compile a program with `MPI_Comm_create_keyval` could be an option.
```
packages/teuchos/comm/src/Teuchos_MpiReductionOpSetter.cpp:171:43: error: 'MPI_Comm_create_keyval' was not declared in this scope
&key, NULL);
```
@trilinos/teuchos @trilinos/framework