Trilinos issueshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues2018-01-11T19:18:36Zhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/1246Create initial standard shared build configuration files and scripts for ATDM...2018-01-11T19:18:36ZJames WillenbringCreate initial standard shared build configuration files and scripts for ATDM builds of Trilinos*Created by: bartlettroscoe*
**Description:**
This story is to track the creation of standard build configuration files and scripts for Trilinos on ATDM systems as per the strategy outlined in:
* https://sems.sandia.gov/jira/brows...*Created by: bartlettroscoe*
**Description:**
This story is to track the creation of standard build configuration files and scripts for Trilinos on ATDM systems as per the strategy outlined in:
* https://sems.sandia.gov/jira/browse/TRIL-171
The idea is that ATDM-funded Trilinos Developers, ATDM application developers, ATDM application users, automated builds of Trilinos, and others who build Trilinos on ATDM platforms related to ATDM will use the same set of configuration files and scripts. This will provide a point of collaboration and coordination between all of these people and processes.
**Definition of Done:**
* ToDo: What is the full scope of this story? How many ATDM platforms need be collected into this system before we close this story?
**CC:** @trilinos/framework, @bathmatt, @rppawlo, @kruger
Get Trilinos builds and testing for ATDM under coordinated version controlhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/1237KokkosKernels CI build failure on 4/12/20172017-04-12T16:26:22ZJames WillenbringKokkosKernels CI build failure on 4/12/2017*Created by: bartlettroscoe*
A KokkosKernels build failure was caught by the standard CI build:
* http://testing.sandia.gov/cdash/index.php?project=Trilinos&filtercount=3&showfilters=1&filtercombine=and&field1=buildname&compare1=61&v...*Created by: bartlettroscoe*
A KokkosKernels build failure was caught by the standard CI build:
* http://testing.sandia.gov/cdash/index.php?project=Trilinos&filtercount=3&showfilters=1&filtercombine=and&field1=buildname&compare1=61&value1=Linux-GCC-4.7.2-MPI_RELEASE_DEBUG_SHARED_PT_CI&field2=groupname&compare2=61&value2=Continuous&field3=buildstarttime&compare3=84&value3=now
in the first CI iteration this morning:
* http://testing.sandia.gov/cdash/index.php?project=Trilinos&parentid=2834087&filtercount=3&showfilters=1&field1=groupname&compare1=61&value1=Continuous&field2=buildstarttime&compare2=84&value2=now&filtercombine=and
(which suggests the checkin-test-sems.sh script should have caught this build failure before the push). But this was only a test/example failure which does not disable KokkosKernels in downstream packages. (Note that we will lose this behavior once we do the single configure, build, and tests https://github.com/TriBITSPub/TriBITS/issues/183 ).
But it looks like @crtrott reacted to this quickly fixed the KokkosKernels in the latest CI build iteration:
* http://testing.sandia.gov/cdash/index.php?project=Trilinos&parentid=2834513&filtercount=3&showfilters=1&field1=groupname&compare1=61&value1=Continuous&field2=buildstarttime&compare2=84&value2=now&filtercombine=and
Note that since this was only a test/example failure for KokkosKernels, this would not have stopped anyone else's pushes using the checkin-test-sems.sh script where were only changing a package downstream from KokkosKernels.
Just added this issue to document this failure since it was interesting for a few reasons:
* The build failure should have likely have been caused by the checkin-test-sems.sh script
* The failure was seen and fixed in the very next CI iteration
* This was only a build failure for examples/tests so this would not have blocked anyone else's push to changes in packages downstream from KokkosKernels
Since Trilinos CDash info is forgotten pretty quickly (just a month or so).
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1232Create and publish an official Trilinos User Support Policy2017-09-19T16:55:37ZJames WillenbringCreate and publish an official Trilinos User Support Policy*Created by: maherou*
The user support policy for Trilinos has been implicit from project inception. We need to make an explicit policy. Basic elements are:
- [x] Expectations for the general community.
- [x] Expectations for fund...*Created by: maherou*
The user support policy for Trilinos has been implicit from project inception. We need to make an explicit policy. Basic elements are:
- [x] Expectations for the general community.
- [x] Expectations for funded projects.
- [x] Roles and accountability.
**CC:** @trilinos/frameworkImprove productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/1227Trilinos CI build broken starting on 4/8/2017 with failing NOX and Teko tests2017-04-10T20:10:25ZJames WillenbringTrilinos CI build broken starting on 4/8/2017 with failing NOX and Teko tests*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @trilinos/teko, @trilinos/nox
Hello @csiefer2 and @tawiesn,
One (or more) of the commits pushed by you to Trilinos 'develop' on 4/8/2017 broke the CI build (with failing t...*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @trilinos/teko, @trilinos/nox
Hello @csiefer2 and @tawiesn,
One (or more) of the commits pushed by you to Trilinos 'develop' on 4/8/2017 broke the CI build (with failing tests NOX_1DfemStratimikosPrec_MPI_4 and Teko_DiagonallyScaledPreconditioner_MPI_1) as shown here:
* http://testing.sandia.gov/cdash/index.php?project=Trilinos&filtercount=3&showfilters=1&filtercombine=and&field1=buildname&compare1=61&value1=Linux-GCC-4.7.2-MPI_RELEASE_DEBUG_SHARED_PT_CI&field2=groupname&compare2=61&value2=Continuous&field3=buildstarttime&compare3=84&value3=now
and in more detail here:
* http://testing.sandia.gov/cdash/index.php?project=Trilinos&parentid=2827563&filtercount=3&showfilters=1&field1=groupname&compare1=61&value1=Continuous&field2=buildstarttime&compare2=84&value2=now&filtercombine=and
The only commits pulled that CI iteration were commits from you two as shown, for example, here:
* http://testing.sandia.gov/cdash/viewNotes.php?buildid=2827737##note0
The test Teko_DiagonallyScaledPreconditioner_MPI_1 failure at:
* http://testing.sandia.gov/cdash/testDetails.php?test=37874341&build=2827737
shows:
```
4. tDiagonallyScaledPreconditioner_application_test_row_UnitTest ... Teko: Inverse "Amesos" is of type strat prec = 0, strat solv = 1, block prec = 0
Teko: Inverse "ML" is of type strat prec = 1, strat solv = 0, block prec = 0
Error, the parameter {name="refmaxwell: 11list",type="ParameterList",value="..."}
in the parameter (sub)list "ANONYMOUS->Preconditioner Types->ML->ML Settings"
was not found in the list of valid parameters!
```
The other test failure does not show any useful output.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1208Teuchos: Address issus with calling Fortran LAPACK rountines from C++ on Powe...2018-10-14T21:01:05ZJames WillenbringTeuchos: Address issus with calling Fortran LAPACK rountines from C++ on Power8 with GCC/gfortran*Created by: mhoemmen*
**Next Action Status:**
Looks like it was a problem with BLAS and LAPACK after all (see https://github.com/trilinos/Trilinos/issues/2454#issuecomment-386271621).
**Blocks:** #1191
**Duplicates:** #347
*...*Created by: mhoemmen*
**Next Action Status:**
Looks like it was a problem with BLAS and LAPACK after all (see https://github.com/trilinos/Trilinos/issues/2454#issuecomment-386271621).
**Blocks:** #1191
**Duplicates:** #347
**Analogous to:** #1210
**CC:** @trilinos/teuchos @trilinos/framework
**Description:**
**NOTE:** The below original description does not pin-point the actual problem that was causing the failures on 'ride'. The real problem is what appears to be a mixed language calling defect summarized [below](https://github.com/trilinos/Trilinos/issues/1208#issuecomment-298767449).
**Original Description:**
BLAS and LAPACK libraries offer a Fortran 77 interface, but we want to call them from C++ code. This matters both in terms of Fortran function name mangling, and in terms of how to pass arguments into Fortran functions (the "application binary interface" or ABI). Most arguments just go into Fortran from the C or C++ world by pointer. However, some Fortran compilers have a different ABI for passing strings (`CHARACTER(*)`). Some compilers just take `char*`, but others may take `char*, unsigned int` or even `char*, unsigned int*` (or not `unsigned`). Fortran programmers don't see this; only programmers working in other languages (like C or C++), who need to know the Fortran ABI, may see this.
Teuchos' BLAS and LAPACK wrappers have two macros that govern the Fortran string ABI: `CHAR_MACRO(c)` and `Teuchos_fcd`.
`CHAR_MACRO(c)`, defined redundantly in `teuchos/numerics/src/Teuchos_LAPACK.cpp` and `Teuchos_BLAS.cpp`, takes a `const char c` and does the right thing with it to pass it into a Fortran function. Teuchos offers two definitions of `CHAR_MACRO`:
```
#if defined (INTEL_CXML)
#define CHAR_MACRO(char_var) &char_var, one
#else
#define CHAR_MACRO(char_var) &char_var
#endif
namespace {
#if defined (INTEL_CXML)
unsigned int one=1;
#endif
// ...
}
```
Per discussion in #1191, it looks like we need another definition for OpenBLAS on POWER, that passes in the constant `one` by address rather than by value.
`Teuchos_fcd`, defined redundantly in `teuchos/numerics/src/Teuchos_LAPACK_wrappers.hpp` and `Teuchos_BLAS_wrappers.hpp`, has the following definition:
```
#if defined(INTEL_CXML)
# define PREFIX __stdcall
# define Teuchos_fcd const char *, unsigned int
#elif defined(INTEL_MKL)
# define PREFIX
# define Teuchos_fcd const char *
#else /* Not CRAY_T3X or INTEL_CXML or INTEL_MKL */
# define PREFIX
# define Teuchos_fcd const char *
#endif
```
In the comments, `CRAY_T3X` refers to the Cray T3D and T3E, two mid-'90s distributed-memory computer architectures. This should give you an idea of the age of this code. In any case, we would need to add a new definition of Teuchos_fcd:
```
# define Teuchos_fcd const char*, const int*
```
(See comments below for why it's an `int` and not `unsigned int`. It would be better to use `int32_t`, but Teuchos cannot assume C++11 / C99 types.)
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1188Create jenkins tests for GCC 4.9.3 SERIAL and WError and add to dashboard2017-05-04T20:32:57ZJames WillenbringCreate jenkins tests for GCC 4.9.3 SERIAL and WError and add to dashboard*Created by: william76*
@trilinos/framework
Get tests for GCC 4.9.3 running and put them onto the Experimental CDash board.
So far, these are the tests in the [Experimental](http://testing.sandia.gov/cdash/index.php?project=Trili...*Created by: william76*
@trilinos/framework
Get tests for GCC 4.9.3 running and put them onto the Experimental CDash board.
So far, these are the tests in the [Experimental](http://testing.sandia.gov/cdash/index.php?project=Trilinos##Experimental) dashboard:
- Linux-gcc-4.9.3-SERIAL_Release_gcc_4.9.3__DEV
- @bmpersc pretty much put this one together using his parameterized build.
- Linux-GCC-4.9.3-MPI_Release_Werror_DEV
- I put this together. The CMake scripts are in my fork in the [rhel6-x86_64 directory on my gcc-4.9.3-MPI-Werror branch](https://github.com/william76/Trilinos/tree/gcc-4.9.3-MPI-Werror/cmake/ctest/drivers/rhel6-x86_64).
@jwillenbring , @bmpersc : Have a look at the #WError test that's running under experimental to make sure it's running a reasonable configuration so we can decide if I should put in a pull request to move my CMake files over.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1182Gather information about all existing nightly builds2017-05-08T14:47:51ZJames WillenbringGather information about all existing nightly builds*Created by: jwillenbring*
@trilinos/framework
As discussed at the 3/27 Framework stand-up, we are going to gather information about all existing nightly builds as a first step towards cleaning up all current nightly dashboard failu...*Created by: jwillenbring*
@trilinos/framework
As discussed at the 3/27 Framework stand-up, we are going to gather information about all existing nightly builds as a first step towards cleaning up all current nightly dashboard failures (where clean-up means fix in source code, or otherwise eliminate the failure, potentially by demoting the build to experimental or updating the build so the failure no longer occurs).
Here are the tasks that need to be completed for this story:
1) @bmpersc will comment on this ticket with a list of the machine/build name pairs currently on the nightly dashboard and will identify a POC for each build.
2) @jwillenbring will create a draft list of questions to ask each build POC.
3) The list of questions will be iterated on by the Framework team and other interested Trilinos community members before being sent to the build POC's.
4) Based on the POC's responses to the questions in the survey, we will define in this ticket a specific plan for eliminating all nightly failures. Implementing that plan will be addressed in other GitHub Issues.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1180Consider taking advantage of new CUDA language support in CMake 3.8.02017-09-13T22:41:43ZJames WillenbringConsider taking advantage of new CUDA language support in CMake 3.8.0*Created by: bartlettroscoe*
**Description:**
I was looking over the release notes for CMake 3.8 at:
* https://cmake.org/cmake/help/v3.8/release/3.8.html
and it says that CUDA is now a first-class CMake language and it supports...*Created by: bartlettroscoe*
**Description:**
I was looking over the release notes for CMake 3.8 at:
* https://cmake.org/cmake/help/v3.8/release/3.8.html
and it says that CUDA is now a first-class CMake language and it supports the nvcc compiler.
Should this be something that we look into for Trilinos?
**CC:** @trilinos/framework, @trilinos/tpetra, @crtrott, @nmhamster
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1175https://trilinos.org/ access blocked by Firefox and Chromium (as not secure)2017-03-23T20:03:08ZJames Willenbringhttps://trilinos.org/ access blocked by Firefox and Chromium (as not secure)*Created by: jschleus*
Half OT: Firefox and Chromium (Linux) block the access to https://trilinos.org/ as "not secure", for e.g. Firefox reports:
```
trilinos.org uses an invalid security certificate.
The certificate is not trust...*Created by: jschleus*
Half OT: Firefox and Chromium (Linux) block the access to https://trilinos.org/ as "not secure", for e.g. Firefox reports:
```
trilinos.org uses an invalid security certificate.
The certificate is not trusted because it was signed using a signature algorithm
that was disabled because that algorithm is not secure.
```https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1167Add 'yaml-cpp' TPL to Trilinos CI build2017-05-12T00:00:22ZJames WillenbringAdd 'yaml-cpp' TPL to Trilinos CI build*Created by: ibaned*
**Next Action Status:**
Waiting for Trilinos to switch CI build from GCC 4.7.2 to GCC 4.7.3 (see #1002) ...
**Description:**
This issue is to get the standard Trilinos CI build to enable the `yaml-cpp` TPL ...*Created by: ibaned*
**Next Action Status:**
Waiting for Trilinos to switch CI build from GCC 4.7.2 to GCC 4.7.3 (see #1002) ...
**Description:**
This issue is to get the standard Trilinos CI build to enable the `yaml-cpp` TPL which is now being used by Albany and other customers.
Done for this issue that there exists a Trilinos CI build with the `yaml-cpp` TPL enabled. This TPL already exists as a SEMS module.
**Blocked by:** #1002 (SEMS `yaml-cpp` TPL does not exist for GCC 4.7.2 in SEMS env)https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1158Set up Windows Jenkins slave2017-08-30T23:31:19ZJames WillenbringSet up Windows Jenkins slave*Created by: jwillenbring*
@trilinos/framework
The Windows VM for Windows testing of Trilinos needs to be set up as a Jenkins slave so that we can automatically run jobs on it. Eventually we will have 2 such VMs, and only 1 should b...*Created by: jwillenbring*
@trilinos/framework
The Windows VM for Windows testing of Trilinos needs to be set up as a Jenkins slave so that we can automatically run jobs on it. Eventually we will have 2 such VMs, and only 1 should be used with Jenkins.
Done for this story is to have a functional Jenkins slave set up on one of the Trilinos Windows VMs.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1157Set up Windows VMs for Trilinos testing2018-03-01T20:43:01ZJames WillenbringSet up Windows VMs for Trilinos testing*Created by: jwillenbring*
@trilinos/framework
As discussed earlier today, we need to set up a couple of VMs for Trilinos testing on Windows. Here is a rough outline of the associated tasks:
1) Install all necessary software on 1...*Created by: jwillenbring*
@trilinos/framework
As discussed earlier today, we need to set up a couple of VMs for Trilinos testing on Windows. Here is a rough outline of the associated tasks:
1) Install all necessary software on 1st VM. Visual Studio 2015 is the current target at a high level, but we also need git (and possibly putty to support git), CMake, blas, lapack and mpi.
2) Test first VM by building some subset of Trilinos.
3) When VM seems to be in good shape, copy the VM so that we eventually have 1 that runs Jenkins jobs, and 1 developers are allowed to log directly in to for debugging.
We can split some of this into separate tickets in the future if it makes sense.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1129Xyce testing not working2017-05-08T16:11:39ZJames WillenbringXyce testing not working*Created by: bmpersc*
@hkthorn reported that the Trilinos Xyce testing is not running correctly and it looks like the issue is the environment is not set right. @trilinos/framework *Created by: bmpersc*
@hkthorn reported that the Trilinos Xyce testing is not running correctly and it looks like the issue is the environment is not set right. @trilinos/framework https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1114Trilinos master is broken for Albany2017-03-08T22:27:30ZJames WillenbringTrilinos master is broken for Albany*Created by: ibaned*
This issue is part short-term and part long-term.
In the short term, kokkos/kokkos-kernels#8 is broken in Trilinos master, and a fix has been pushed to Trilinos develop (0a2eee9). I'd like someone to merge develop ...*Created by: ibaned*
This issue is part short-term and part long-term.
In the short term, kokkos/kokkos-kernels#8 is broken in Trilinos master, and a fix has been pushed to Trilinos develop (0a2eee9). I'd like someone to merge develop into master to get this fix through.
In the long term, it would be highly beneficial to include an application that uses Trilinos as part of the CI process that determines when to merge develop into master. Any application that uses the Tpetra stack would have failed to build due to kokkos/kokkos-kernels#8, but no internal Trilinos tests could have caught it.
I'd be more than happy to work with the Trilinos team to set up a minimal Albany build as an additional CI test, and I think that the same goal could be accomplished using any other application, if there is another application that suits the role better.
@trilinos/framework @jwillenbring @bmpersc https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1109checkin-test-sems.sh: how to control -j for make and ctest ?2017-03-06T16:18:22ZJames Willenbringcheckin-test-sems.sh: how to control -j for make and ctest ?*Created by: ibaned*
I'm trying to give separate `-j` arguments to `make` and `ctest` through `checkin-test-sems.sh`. This is the way I'm trying to do it:
```bash
../cmake/std/sems/checkin-test-sems.sh \
--do-all --make-options="-j16...*Created by: ibaned*
I'm trying to give separate `-j` arguments to `make` and `ctest` through `checkin-test-sems.sh`. This is the way I'm trying to do it:
```bash
../cmake/std/sems/checkin-test-sems.sh \
--do-all --make-options="-j16" --ctest-options="-j1"
```
But that runs the following make command:
```bash
make -j4 -j16
```
How do I make the first `-j4` disappear ?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 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/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/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/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 Trilinos