Trilinos issueshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues2017-07-10T14:58:26Zhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/1483Make the parameterized builds capable of changing the configure through a jen...2017-07-10T14:58:26ZJames WillenbringMake the parameterized builds capable of changing the configure through a jenkins parameter*Created by: bmpersc*
@trilinos/framework a question about using a parameter to change the configuration of the parameterized builds was brought up in another issue. We should discuss the pros and cons of that here.
The initial conce...*Created by: bmpersc*
@trilinos/framework a question about using a parameter to change the configuration of the parameterized builds was brought up in another issue. We should discuss the pros and cons of that here.
The initial concern was mentioned in #1393 and was brought up because to resolve that ticket for the clean build we are going to disable the offending tests. However, the easy way to do that for now is to modify the configuration of the parameterized build which would affect more than just the clean builds that we are trying to fix.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1468Improper python environment on test machine hansel2017-06-30T19:54:49ZJames WillenbringImproper python environment on test machine hansel*Created by: jhux2*
@trilinos/framework There appears to be a problem with the python environment on the test machine ```hansel.sandia.gov```. As a result, two ML tests are failing for the 12.10.1 release. The symptom is
```
'imp...*Created by: jhux2*
@trilinos/framework There appears to be a problem with the python environment on the test machine ```hansel.sandia.gov```. As a result, two ML tests are failing for the 12.10.1 release. The symptom is
```
'import site' failed; use -v for traceback
Traceback (most recent call last):
File "/jenkins/slave/workspace/Trilinos_hansel_release_12.10/MPI_RELEASE_12.10.1_SHARED/Trilinos/commonTools/test/utilities/compareTestOutput", line 9, in <module>
import re
ImportError: No module named re
```
Errors can be found [here](https://testing.sandia.gov/cdash/testDetails.php?test=39699947&build=2975943) and [here](https://testing.sandia.gov/cdash/viewTest.php?onlyfailed&buildid=2975354).https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1457Set up new continuous builds2017-08-02T01:27:34ZJames WillenbringSet up new continuous builds*Created by: jwillenbring*
@trilinos/framework
In alignment with the discussion at the Framework Standup this morning, we need to set up 2 new continuous builds on the newer build farm - one to support GCC 4.8.4, the other to suppor...*Created by: jwillenbring*
@trilinos/framework
In alignment with the discussion at the Framework Standup this morning, we need to set up 2 new continuous builds on the newer build farm - one to support GCC 4.8.4, the other to support GCC 4.9.3.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1427-openmp option is deprecated in icpc2017-08-23T20:08:19ZJames Willenbring-openmp option is deprecated in icpc*Created by: srajama1*
When enabling OpenMP with intel 17 I get tons of these
icpc: command line remark #10411: option '-openmp' is deprecated and will be removed in a future release. Please use the replacement option '-qopenmp'
C...*Created by: srajama1*
When enabling OpenMP with intel 17 I get tons of these
icpc: command line remark #10411: option '-openmp' is deprecated and will be removed in a future release. Please use the replacement option '-qopenmp'
Can we change the configure logic to handle this ?
@trilinos/framework @bartlettroscoe https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1422Get all SERIAL tests in Trilinos to run as 1-process tests in MPI builds2017-08-22T19:15:01ZJames WillenbringGet all SERIAL tests in Trilinos to run as 1-process tests in MPI builds*Created by: bartlettroscoe*
**CC:** @trilinos/framework
**Description:**
A big problem we have with SQA and test of Trilinos is that many Trilinos packages have significant numbers of tests that only run in a non-MPI serial buil...*Created by: bartlettroscoe*
**CC:** @trilinos/framework
**Description:**
A big problem we have with SQA and test of Trilinos is that many Trilinos packages have significant numbers of tests that only run in a non-MPI serial build (e.g. Pamgan #1415 and SEACAS #1392). That means that running the standard CI build MPI_RELEASE_DEBUG_SHARED_PT does not run any of these tests.
This story is to create a place-marker for package-specific stories to get all of their single-process tests now running only in the non-MPI serial build to also run in the MPI builds. This way, the set of tests run in a serial build will be a strict subset of the tests run in the MPI build. Therefore, passing the MPI build will give higher confidence that the serial build will also pass all of its tests.
Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/1416Question: Nightly testing with large or internal Sandia data files2017-10-20T21:21:20ZJames WillenbringQuestion: Nightly testing with large or internal Sandia data files*Created by: ndellingwood*
What is the best way (if possible) to set up a nightly test that may use large data files or internal data files that cannot be stored within Trilinos?
In particular for Amesos2, we'd like to set up a night...*Created by: ndellingwood*
What is the best way (if possible) to set up a nightly test that may use large data files or internal data files that cannot be stored within Trilinos?
In particular for Amesos2, we'd like to set up a nightly test for the following cases:
1. Using matrix market files provided by a customer that cannot be released in Trilinos for a unit test that would catch issues like those in #1289
2. Potentially using a larger matrix market file for performance testing (e.g. 60MB+).
On this topic, what is the threshold for size of data files allowed to be stored in Trilinos?
@bmpersc @maherou @srajama1 @bartlettroscoe
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1388Get templated code in Trilinos to use ETI as much as possible to reduce (re)b...2017-06-02T23:46:23ZJames WillenbringGet templated code in Trilinos to use ETI as much as possible to reduce (re)build times and resources*Created by: bartlettroscoe*
**Blocked By:** (The ETI issues for individual packages as they get created.)
**CC:** @trilinos/framework, @rppawlo, @maherou
**Description:**
This story is a place marker to push the issue of gett...*Created by: bartlettroscoe*
**Blocked By:** (The ETI issues for individual packages as they get created.)
**CC:** @trilinos/framework, @rppawlo, @maherou
**Description:**
This story is a place marker to push the issue of getting templated packages in Trilinos to use explicit template instantiation (ETI) to reduce build times and especially rebuild times for these packages. Long build times is a huge impediment to development, testing, and usage of Trilinos.
For example, it is reported (by @dridzal) that some ROL examples consume huge amounts of compiler time and system memory in order to compile because they directly include headers from Belos, Amesos2, Ifpack2, MueLu, etc. If ETI was being used by these packages, then it is likely that those examples would compile much more quickly and use less memory.
Another example is the xSDK project where Trilinos is constantly getting hit for large build times and resources. (In fact, the xSDK installer for Trilinos was modified to remove the templated packages because of this.)
Now that Trilinos has top-level options for enabling/disabling scale types like `float`, `complex<float>`, and `complex<double>` (see #362, and there are similar options for ordinal types), every Trilinos package that has templated code needs to, as much as possible, provide for ETI based on those requested types. Note that this does *not* require packages to use a consistent system for ETI (hence, #546 is not needed). It just requires that they do ETI and respond to those type enables/disables.
It is expected that new Issues will be created for specific packages to get their code to use ETI more. Those new issues will block this Issue.
Reduce build times for Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/1362Record pushes to Trilinos 'develop' for later analysis2017-06-03T19:21:49ZJames WillenbringRecord pushes to Trilinos 'develop' for later analysis*Created by: bartlettroscoe*
**Next Action Status:**
Trilinos pushes are being logged to local machine crf450. Next: See 'tasks' below ...
**Description:**
In order to analyze who is pushing commits to the Trilinos GitHub 'dev...*Created by: bartlettroscoe*
**Next Action Status:**
Trilinos pushes are being logged to local machine crf450. Next: See 'tasks' below ...
**Description:**
In order to analyze who is pushing commits to the Trilinos GitHub 'develop' branch and what impact that has on the stability of the 'develop' branch, we need to a way to record who is pushing and when. Unfortunately, GitHub does not give you a way to do that. However, it is pretty easy to set up some simple scripts that continuously pull from the Trilinos GitHub 'develop' branch and then record the top commit when any new commits are discovered. What that data built up over a period of weeks and months, and comparing to the Trilinos post-push CI build (see #482), we can do the analysis that we need to do and determine how to best stabilize the 'develop' branch (which is very important for some customers of Trilinos like ATDM).
**Tasks:**
1) Get initial scripts up and running and logging pushes [Done]
2) Put under version control [Done]
3) Modify the script so that it prepends the top commit instead of putting it at the end (this will be slower but will be more readable) [Done]
4) Find a way to publish this online and link to this from Trilinos GitHub wiki ...
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1355Disable external repos for parameterized builds2017-05-23T17:09:04ZJames WillenbringDisable external repos for parameterized builds*Created by: bmpersc*
Based on a discussion regarding sundance failures on the clean build the Framework team decided it was best to just disable all of the packages that come from external repos for non-specialized builds.
Currently...*Created by: bmpersc*
Based on a discussion regarding sundance failures on the clean build the Framework team decided it was best to just disable all of the packages that come from external repos for non-specialized builds.
Currently there is an option in the configure "Trilinos_EXTRA_REPOSITORIES" that is set to the empty string, but this doesn't seem to be affecting what external repos are pulled in. This needs to be investigated on how to prevent the the external repos from being automatically pulled in.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1338Disable Fortran by default for Trilinos on Mac OSX machines as well?2017-05-18T19:27:07ZJames WillenbringDisable Fortran by default for Trilinos on Mac OSX machines as well?*Created by: bartlettroscoe*
**CC:** @trilinos/developers, @trilinos/framework
**Description:**
Given that most Mac OSX machines don't have a working Fortran compiler by default, should we change the CMake logic to disable Fortran...*Created by: bartlettroscoe*
**CC:** @trilinos/developers, @trilinos/framework
**Description:**
Given that most Mac OSX machines don't have a working Fortran compiler by default, should we change the CMake logic to disable Fortran by default on Mac OSX machines? That will technically break backward compatibility but given the you don't need Fortran to get a lot out of Trilinos, I am not sure how many users would notice.
I am asking this since I am modifying TriBITS to fix a defect in how it handles the default for `<Project>_ENABLE_Fortran` and I want to move all special platform-specific logic to the project itself. Since I will be updating Trilinos/CMakeLists.txt for this refactoring, I thought I would ask about since I could make this change at the same time.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1272Trilinos config problem in FiniteValue.cmake and GCC 5.4.02017-05-01T02:17:41ZJames WillenbringTrilinos config problem in FiniteValue.cmake and GCC 5.4.0*Created by: raovgarimella*
Trilinos 12.6.1 and 12.10.1 configuration fails with gcc 5.4.0 and cmake 3.5.1 because of an issue with trilinos/cmake/tribits/core/config_tests/FiniteValue.cmake. The complaint is that "```isnan was not dec...*Created by: raovgarimella*
Trilinos 12.6.1 and 12.10.1 configuration fails with gcc 5.4.0 and cmake 3.5.1 because of an issue with trilinos/cmake/tribits/core/config_tests/FiniteValue.cmake. The complaint is that "```isnan was not declared in this scope```".
Upon investigating further, it seems that FiniteValue.cmake tries to test for existence of '```isnan```' within the global namespace and the ```std::``` namespace but in both cases uses the ```<cmath>``` header.
According to the following post on StackOverflow, it seems however that one should include ```<math.h>``` when calling '```isnan```' and ```<cmath>``` when calling '```std::isnan```'
http://stackoverflow.com/questions/18128899/is-isnan-in-the-std-namespace-more-in-general-when-is-std-necessary-optio
Making this change allows the configuration to proceed. I checked and this problem persists in the HEAD version of the master as well.
Here is a trivial patch file for fixing the problem in 12.10.1 release
```
--- cmake/tribits/core/config_tests/FiniteValue.cmake 2016-11-22 15:43:07.000000000 -0700
+++ cmake/tribits/core/config_tests/FiniteValue.cmake.new 2017-04-26 22:27:08.016402800 -0600
@@ -58,7 +58,7 @@ INCLUDE(CheckCXXSourceCompiles)
SET(SOURCE_GLOBAL_ISNAN
"
-#include <cmath>
+#include <math.h>
int main()
{
double x = 1.0;
@@ -105,7 +105,7 @@ ENDIF()
SET(SOURCE_GLOBAL_ISINF
"
-#include <cmath>
+#include <math.h>
int main()
{
double x = 1.0;
```https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1293Document information concerning Clean, Nightly, and Specialized tracks2018-02-12T20:58:34ZJames WillenbringDocument information concerning Clean, Nightly, and Specialized tracks*Created by: jwillenbring*
@william76
I need to document the definition of, qualifications for, and process for moving between the 3 new tracks that we are dividing the Nightly track into for automated testing. Definition of done fo...*Created by: jwillenbring*
@william76
I need to document the definition of, qualifications for, and process for moving between the 3 new tracks that we are dividing the Nightly track into for automated testing. Definition of done for this story is:
Trilinos GitHub wiki page exists listing
--Three develop branch testing tracks - Clean, Nightly, and specialized, with a description of each track.
--Process for moving from one track to another.Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/1270Framework: links to subprojects on dashboard are incorrect2017-09-02T03:07:56ZJames WillenbringFramework: links to subprojects on dashboard are incorrect*Created by: jhux2*
@trilinos/framework
At the top of the MueLu testing [page](http://testing.sandia.gov/cdash/index.php?project=Trilinos&subproject=MueLu) are links to Subproject Dependencies. Those links have the form http://test...*Created by: jhux2*
@trilinos/framework
At the top of the MueLu testing [page](http://testing.sandia.gov/cdash/index.php?project=Trilinos&subproject=MueLu) are links to Subproject Dependencies. Those links have the form http://testing.sandia.gov/cdash/index.php?subproject=<some_package>&, but clicking on any of those links redirects to http://testing.sandia.gov/cdash/viewProjects.php.
I believe the correct form of those links should be http://testing.sandia.gov/cdash/index.php?project=Trilinos&subproject=<some_package>.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1255Add TPLs for Amesos2 in Nightly Builds2018-10-01T19:30:39ZJames WillenbringAdd TPLs for Amesos2 in Nightly Builds*Created by: srajama1*
We need to add SuperLU-Dist, SuperLU and UMFPACK as part of nightly tests.
@jwillenbring @krcb @MicheldeMessieres @trilinos/framework *Created by: srajama1*
We need to add SuperLU-Dist, SuperLU and UMFPACK as part of nightly tests.
@jwillenbring @krcb @MicheldeMessieres @trilinos/framework https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1233Create and publish an official Trilinos Change Management Policy2017-06-29T15:50:24ZJames WillenbringCreate and publish an official Trilinos Change Management Policy*Created by: maherou*
While the Trilinos project has a rigorous backward compatibility policy, other forms of change management are not well define. This issue is for creating a more comprehensive statement of how we manage changes. ...*Created by: maherou*
While the Trilinos project has a rigorous backward compatibility policy, other forms of change management are not well define. This issue is for creating a more comprehensive statement of how we manage changes. The policy should cover these things (and probably more):
- [ ] How we inform users of commits to the repository that could change numerical results.
- [ ] When these kinds of changes can be pushed into the repository and how.
- [ ] As we start to introduce non-deterministic algorithms, how do we indicate when a function may produce results that vary from run to run.
cc: @trilinos/framework Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/1176Analysis of configure and build failures due to KokkosKernels pushes on March...2017-03-23T17:54:16ZJames WillenbringAnalysis of configure and build failures due to KokkosKernels pushes on March 1-2 reported in #1099*Created by: bartlettroscoe*
**Description:**
This story is to analyze the KokkosKernels commits pushed on March 1-2, 2017 that broke the configure and build of Trilinos that was reported in #1099 and see if usage of the [checkin-tes...*Created by: bartlettroscoe*
**Description:**
This story is to analyze the KokkosKernels commits pushed on March 1-2, 2017 that broke the configure and build of Trilinos that was reported in #1099 and see if usage of the [checkin-test-sems.sh](https://github.com/trilinos/Trilinos/wiki/Policies-%7C-Safe-Checkin-Testing) script could have avoided the failures (and resulting consequences) if it had been used for the test and push (which would have stopped the push).
This started when a set of commits were pushed to the Trilinos 'develop' branch on March 1 with the top commit 97ed757 being:
```
97ed757 [Wed Mar 1 08:24:01 2017 -0700] <crtrott@sandia.gov>
Kokkos-Kernels: Adding Kokkos-Kernels as a stand-alone package
```
as shown by the CI build:
* http://testing.sandia.gov/cdash/viewConfigure.php?buildid=2766164
That version of Trilinos failed to configure as shown on that CI build iteration.
Later that day, issue #1099 was created by an important Trilinos customer and it resulted in 35 comments that involved 9 people in that issue before it was resolved.
An attempt to fix this problem was pushed later that day with the top commit de7ac5a being:
```
de7ac5a [Wed Mar 1 13:17:16 2017 -0700] <mhoemme@sandia.gov>
KokkosKernels: Fix #1099
```
as shown by the CI build:
* http://testing.sandia.gov/cdash/viewConfigure.php?buildid=2766462
That version passed the configure but resulted in many build failures.
The build was not finally fixed until March 2 as shown at:
* http://testing.sandia.gov/cdash/viewConfigure.php?buildid=2767860
Could the usage of the checkin-test-sems.sh script have caught these problems and stop the pushes that broke the configure and build of Trilinos over these two days?
**CC:** @trilinos/framework, @bathmatt, @crtrott, @mhoemmen
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1164Windows install capability test driver2017-04-19T18:11:35ZJames WillenbringWindows install capability test driver*Created by: jwillenbring*
@trilinos/framework
We need to develop a small test driver to demonstrate the functionality of the Windows install capability described in issue #1163.
This ticket is for tracking the development of tha...*Created by: jwillenbring*
@trilinos/framework
We need to develop a small test driver to demonstrate the functionality of the Windows install capability described in issue #1163.
This ticket is for tracking the development of that driver, as well as setting up nightly testing through Jenkins to protect that functionality.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1163Windows install capability2017-05-13T03:16:47ZJames WillenbringWindows install capability*Created by: jwillenbring*
@trilinos/framework
It needs to be possible to install Trilinos libraries on a Windows machine and have supporting infrastructure for calling those libraries from an application. This story is for tracking...*Created by: jwillenbring*
@trilinos/framework
It needs to be possible to install Trilinos libraries on a Windows machine and have supporting infrastructure for calling those libraries from an application. This story is for tracking the development of those features.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1160Set up release Trilinos Windows nightly build2017-09-13T17:01:42ZJames WillenbringSet up release Trilinos Windows nightly build*Created by: jwillenbring*
@trilinos/framework
This ticket is for setting up a nightly "release" build for Trilinos on Windows.
Done for this story includes
-having a nightly build reporting to CDash with a release configurati...*Created by: jwillenbring*
@trilinos/framework
This ticket is for setting up a nightly "release" build for Trilinos on Windows.
Done for this story includes
-having a nightly build reporting to CDash with a release configuration (with package options previously sent to Michael).
-the build should run on a Windows VM provided by the Trilinos team
-filing tickets for all errors found in executing the build. For all errors found, tickets should be filed in GitHub issues. If cause of error is known, a pull request could be offered to the package developers for package encountering the failure.
If necessary, another ticket will be filed for cleaning up all failures once the job is set up and running.
The initial work for setting up the build can be done anywhere, but getting the job running through Jenkins on the appropriate VM depends on tickets #1157 and #1158.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1159Set up debug Windows Trilinos nightly build2017-09-13T17:02:49ZJames WillenbringSet up debug Windows Trilinos nightly build*Created by: jwillenbring*
@trilinos/framework
This ticket is for setting up a nightly "debug" build for Trilinos on Windows.
Done for this story includes
-having a nightly build reporting to CDash with a debug configuration (...*Created by: jwillenbring*
@trilinos/framework
This ticket is for setting up a nightly "debug" build for Trilinos on Windows.
Done for this story includes
-having a nightly build reporting to CDash with a debug configuration (with package options previously sent to Michael).
-the build should run on a Windows VM provided by the Trilinos team
-filing tickets for all errors found in executing the build. For all errors found, tickets should be filed in GitHub issues. If cause of error is known, a pull request could be offered to the package developers for package encountering the failure.
If necessary, another ticket will be filed for cleaning up all failures once the job is set up and running.
The initial work for setting up the build can be done anywhere, but getting the job running through Jenkins on the appropriate VM depends on tickets #1157 and #1158.