Trilinos issueshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues2018-10-11T14:04:09Zhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/453Send out summary email of failing Trilinos Nightly builds and tests at end of...2018-10-11T14:04:09ZJames WillenbringSend out summary email of failing Trilinos Nightly builds and tests at end of each testing day*Created by: bartlettroscoe*
**CC:** @trilinos/framework
**Related to:** #380
**Description:**
At a meeting last week between Jim W. (@jwillenbring), Brent P. (@bmpersc), Erik S. and myself (@bartlettroscoe), Erik mentioned that one ...*Created by: bartlettroscoe*
**CC:** @trilinos/framework
**Related to:** #380
**Description:**
At a meeting last week between Jim W. (@jwillenbring), Brent P. (@bmpersc), Erik S. and myself (@bartlettroscoe), Erik mentioned that one of the internal projects had/has a process where they send out a summary email at the end of each testing day that summarizes the failing tests. This email is seen by every developer on the project, the project lead, and the manager. If these tests are allowed to fail day after day, then the project lead (and then the managers) will step in and provide motivation and encouragement for the development team to help address the issues.
With the current CDash setup that is used by Trilinos, a targeted email goes out for every configure, build, or test failure for a package as soon as the results are uploaded and processed by the CDash. This email is targeted to the email list that is attached to a given Trilinos package. This gives that package team a heads up about the failure as soon as it is known. While this is good because it alerts the targeted people as soon as possible, one can't see the fully set of failures at the end of a testing day without going directly to CDash and looking.
This Story is to implement a process where a single email would be send out at the end of each testing day (e.g. at 1 am after the last testing day ended at 12 pm) to all of the Trilinos developers, project leads, and responsible managers with the full list of failing tests for the Nightly Trilinos builds. As described for the other internal SNL project described above, having this feature would help to elevate the importance of keeping the Nightly builds clean and therefore would support beefing up the testing to promote from the 'develop' branch to the 'master' branch.
There are several ways to implement this:
1) Add this as an official feature to CDash and pay Kitware to add it.
2) Implement this as a python script that reads from CDash using the new CDash API.
In my opinion, it would be pretty easy to implement option-2 above given the new CDash API that returns a JSON file for any CDash PHP page. This would be very similar to the script `send_kanban_wip_reminder_emails.py` which I (Ross) wrote for CASL PHI that queries the Trac DB and then creates a customized HTML-formatted email with a nice formatted table. My guess is that writing a script like this could be done in about 4 hours, including some unit tests to define and protect this functionality. You would then set up a cron job to run this script at the same time at the end of each testing day.
Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/463Setup initial testing on Common Jenkins2016-08-23T18:08:50ZJames WillenbringSetup initial testing on Common Jenkins*Created by: bmpersc*
**Next Action Status:**
???
**CC:** @trilinos/framework
**Description:**
Need to get prototype floating test jobs working on the common jenkins farm.
Currently there is a blocker of authentication for the ent...*Created by: bmpersc*
**Next Action Status:**
???
**CC:** @trilinos/framework
**Description:**
Need to get prototype floating test jobs working on the common jenkins farm.
Currently there is a blocker of authentication for the entity account. It has been suggested to use an sshkey for authentication.
Testing revamphttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/468Fails to use then supplied openmpi path2016-06-27T20:01:43ZJames WillenbringFails to use then supplied openmpi path*Created by: yurivict*
On FreeBSD OpenMPI headers are in /usr/local/mpi/openmpi/include. During configure and build stages CXXFLAGS has -L flag with this folder.
cmake has these arguments:
```
-DTrilinos_ENABLE_OpenMP:BOOL=ON
-DTPL_EN...*Created by: yurivict*
On FreeBSD OpenMPI headers are in /usr/local/mpi/openmpi/include. During configure and build stages CXXFLAGS has -L flag with this folder.
cmake has these arguments:
```
-DTrilinos_ENABLE_OpenMP:BOOL=ON
-DTPL_ENABLE_MPI:BOOL=ON
-DMPI_BASE_DIR:PATH="/usr/local/mpi/openmpi"
-DMPI_BIN_DIR:PATH="/usr/local/mpi/openmpi/bin"
```
Yet build still breaks with this error:
```
/usr/ports/math/trilinos/work/Trilinos-trilinos-release-12-6-2/packages/zoltan/src/include/zoltan.h:50:17: fatal error: mpi.h: No such file or directory
#include <mpi.h>
```
System calls trace shows that the "openmpi" folder is never looked at for mpi.h.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/471Cdash is not showing results2016-06-29T14:14:48ZJames WillenbringCdash is not showing results*Created by: bmpersc*
Cdash doesn't seem to be showing its results. However, the checking I've done indicates that the submissions have been received and are not backed up. It is unclear why they are not showing on the dashboard. I will...*Created by: bmpersc*
Cdash doesn't seem to be showing its results. However, the checking I've done indicates that the submissions have been received and are not backed up. It is unclear why they are not showing on the dashboard. I will need to dig into this more
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/472release 12.6.4 bug fix tarball2016-07-22T22:14:36ZJames Willenbringrelease 12.6.4 bug fix tarball*Created by: bmpersc*
There are a number of patches to 12.6 that need to be released including one fix that is needed for issue #469.
*Created by: bmpersc*
There are a number of patches to 12.6 that need to be released including one fix that is needed for issue #469.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/473Migrate checklists to GitHub Trilinos Developer site2016-06-30T15:13:17ZJames WillenbringMigrate checklists to GitHub Trilinos Developer site*Created by: jwillenbring*
**Next Action Status:**
Updating the new developer checklist ...
**CC:** @trilinos/framework
**Description:**
The process checklists need to be moved from the old developer website to the new Trilinos Dev...*Created by: jwillenbring*
**Next Action Status:**
Updating the new developer checklist ...
**CC:** @trilinos/framework
**Description:**
The process checklists need to be moved from the old developer website to the new Trilinos Developer GitHub wiki.
**Tasks:**
1. Update the new-developer checklist ... IN PROGRESS..
2. ???
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/479Domi web presence missing2016-07-01T13:56:34ZJames WillenbringDomi web presence missing*Created by: bmpersc*
The Domi package doesn't have any pages on the Trilinos.org site currently. Bill Spotz sent the following email regarding Domi's web presence.
Jim, Brent,
I assume this just got buried in the normal course of thi...*Created by: bmpersc*
The Domi package doesn't have any pages on the Trilinos.org site currently. Bill Spotz sent the following email regarding Domi's web presence.
Jim, Brent,
I assume this just got buried in the normal course of things, so I am going to nag again. Domi is not a listed package on the trilinos.org site, but it is officially released, so it should be. I don't really read perl, so it isn't obvious to me if I/we modify doc/build_docs.pl or some other database-type file to do this. Domi has a doc/build_docs script, but that doesn't seem to be sufficient. What else needs to be done?
Thanks,
Bill
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/482Set up robust portable pre-push and post-push CI tools and process based on t...2017-09-14T20:30:50ZJames WillenbringSet up robust portable pre-push and post-push CI tools and process based on the SEMS Dev Env*Created by: bartlettroscoe*
**Next Action Status:**
New CI build is pushed to 'develop', new post-push CI server is running, and new checkin-test-sem.sh script ready for more testing and review ... Note going to pursue other extensi...*Created by: bartlettroscoe*
**Next Action Status:**
New CI build is pushed to 'develop', new post-push CI server is running, and new checkin-test-sem.sh script ready for more testing and review ... Note going to pursue other extensions (e.g. mac OSX, tcsh, etc.). See https://github.com/trilinos/Trilinos/issues/482#issuecomment-266124179. Next: Leave in review til 1/1/2017 then close.
**Blocked By:** #158, #410, #362
**Blocking:** #380
**Related To:** #370, #475, #476
**CC:** @trilinos/framework
**Description:**
Trilinos has not had an effective pre-push CI development process for many years. When the checkin-test.py script was first created (back in 2008 or so), the primary stack of packages was based on Epetra and the main external dependencies were C/C++/Fortran compilers and BLAS and LAPACK. Those dependencies and the major Trilinos customers at the time were used to select the initial set of Primary Tested (initially called Primary Stable) packages that is being used to this day. However, since that time, many new Trilinos packages have been added and important Trilinos customers are relying on many of these newer packages (e.g. SEACAS, STK, Tpetra, Phalanx, Panzer, etc.). In addition, these new Trilinos packages require more dependencies than just BLAS and LAPACK and now TPLs like Boost, HDF5, NetCDF, ParMETIS, SuperLU and others used by Trilinos are also very important to many Trilinos customers.
Another problem with the current pre-push CI testing processes with Trilinos is that Trilinos developers have a variety of different types of machines, OSs, versions of compilers, TPL implementations, etc. that they use to develop on and push changes for Trilinos. This has resulted in people who tried to use the checkin-test.py script to suffer failed pushes due to failing tests on their machine not triggered by their changes. In contract, projects that have a uniform pre-push CI testing env don't experience these types of problems. One example of such a project is CASL VERA that uses TriBITS and the checkin-test.py script and has a set of uniform development machines where developers almost never see tests that fail in their build of the code that passed on another developer's build. Therefore, the only failed builds and tests are due to their own local changes. In that project, there is no trepidation to running the checkin-test.py script and everyone uses it uniformly for nearly every push.
Another problem with the current CI testing process for Trilinos is that the post-push CI server that posts to CDash enables a different set of packages and TPLs from what the pre-push CI build does (and of course uses different compilers, MPI, etc.). Therefore, a CI build/test failure seen on CDash may not be seen with the checkin-test.py script locally and visa vera. This makes it difficult for developers to determine if the failures they are seeing on their own machine are due to their local changes or due differences with the env on their machine compared to the machine running the CI build posting to CDash, if it is due to a different set of enabled packages and TPL or something else.
As a result, the stability of the main Trilinos development branch (now the 'develop' branch, see #370) has degraded from what it was 5+ years ago. This is a problem because Trilinos needs to have a more stable 'develop' branch in order to more frequently update from the 'develop' branch to the 'master' branch (see #370).
This story is to address all of these shortcomings of the current Trilinos CI testing process. The new SEMS Dev Env (#158) provides an opportunity to create a fairly portable (at least for SNL staff members) uniform pre-push and post-push CI testing environment for the first time.
Here is the plan for setting up a more effective CI process based on the SEMS Dev Env, the checkin-test.py script, and CTest/CDash:
1. **Select a standard pre-push CI build env based on the SEMS Dev Env:** Currently, GCC 4.7.2 and OpenMPI 1.6.5 are being used for the post-push CI build that posts to CDash. These selections should be reexamined and potentially changed. This will be used to create a standard `load_ci_sems_dev_env.sh` script, which just calls the `local_sems_dev_env.sh` script with the selections.
2. **Select an expanded/revised set of Primary Tested (PT) packages and TPLs:** This revised set should be based on the most important packages and TPLs to current Trilinos customers. Any important TPL not already supported by the SEMS Dev Env may need to be added (i.e. to the Trilinos space under the /projects/ NFS mount). Revising the set of PT packages and TPLs is being addressed in #410.
3. **Set up a standard checkin-test-sems.sh script that all Trilinos developers can use to push changes to the Trilinos 'develop' branch:** This should automatically load the correct standard SEMS Dev Env by sourcing `load_ci_sems_dev_env.sh`. This should likely only run a single build of Trilinos to speed up the testing/push process. (If there is a single build is would likely include `-DTPL_ENABLE_MPI=ON -DCMAKE_BULD_TYPE=RELEASE -DTriinos_ENABLE_DEBUG=ON -DBUILD_SHARED_LIBS=ON -DTrilinos_ENABLE_EXPLICIT_INSTANTIATION=ON -DTrilinos_ENABLE_FLOAT=OFF -DTrilinos_ENABLE_COMPLEX=OFF`. See #362 about turning off float and complex gy default.)
4. **Change the main post-push CI server that posts to CDash to use the exact same build as the default builds for the checkin-test-sems.sh script:** This is needed to catch the violations of the [additive test assumption of branches](https://docs.google.com/document/d/1uVQYI2cmNx09fDkHDA136yqDTqayhxqfvjFiuUue7wo/edit#bookmark=id.d1jneh8ubsyn). This can also be used to alert Trilinos developers when there are failures in the standard CI build or to verify that failures they are seeing are not their doing. If other post-push CI builds are desired, like non-MPI serial and full release builds, then those can be added as extra CI builds (we just need extra machines for that).
After this Story is complete, then we can create new Stories to get Trilinos developers to use the checkin-test-sems.sh script and to commit to keeping the CI build(s) 100% all the time with "Stop the Line" urgency to fix.
**Definition of Done:**
- An initial implementation for `load_ci_sems_dev_env.sh` and `checkin-test-sems.sh` that provides a viable CI build based on the SEMS Dev Env.
- Documentation for `load_ci_sems_dev_env.sh` and `checkin-test-sems.sh` has been written and has been reviewed by a few Trilinos developers.
- The post-push CI build of Trilinos uses the same `load_ci_sems_dev_env.sh` env and the same default build(s) as defined in the `checkin-test-sems.sh` script.
- Review the setup and documentation for the `checkin-test.py` script itself to determine what improvements that might help with usability and adoption.
**Decisions that need to be made:**
- What default timeout should be selected for pre-push tests (e.g. 3 minutes)?
- Should there just be an MPI_RELEASE_DEBUG_SHARED default build or also some serial build listed in --default-builds?
- What version of GCC and OpenMPI should be used?
- What other set of TPLs really should be added beyond what is provided in the SEMS Dev Env (e.g. a 64-bit build of Scotch without pthreads enabled, see [this comment in #476](https://github.com/trilinos/Trilinos/issues/476#issuecomment-230135162)).
- ???
**Tasks:**
1. Create drafts for `load_ci_sems_dev_env.sh` and `checkin-test-sems.sh` [Done]
2. Discuss this Story at a Trilinos Leaders Meeting Done]
3. Work #410 to select the updated set of PT packages and TPLs [Done]
4. Work #362 to disable float and complex by default [Done]
5. Select the new set (or just one) `--default-builds` for the `checkin-test.py` and therefore the `checkin-test-sems.sh` script" [Done]
- Make updates to Trilinos and checkin-test.py script on branch `better-ci-build-482` ... IN PROGRESS ...
- Get proposed changes reviewed (quickly) [Done]
- Create wiki documentation for usage `checkin-test-sems.sh` [Done]
- Commit changes to 'develop' branch [Done]
6. Create a new post-push CI build on crf450 that uses the identical CI build as `checkint-test-sems.py --local-do-all` [Done]
- Set up cron job or Jenkins job to run the build [Done]
- Run the CI build for several days and have people review it [Done]
8. Have updated CI process and documentation reviewed ... In Progress ...
9. Update the existing Jenkins CI build to use the new CI build and then remove the CI build on crf450 ...
Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/483Cdash is backed up again2016-07-26T19:38:04ZJames WillenbringCdash is backed up again*Created by: bmpersc*
our cdash installation is backed up by about a day again. It looks like this started saturday night. I'm working on getting it processing again.
*Created by: bmpersc*
our cdash installation is backed up by about a day again. It looks like this started saturday night. I'm working on getting it processing again.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/485OpenMP Detection Assumes GNU-Style Preprocessor Directive for Fortran (Incomp...2017-07-13T16:51:19ZJames WillenbringOpenMP Detection Assumes GNU-Style Preprocessor Directive for Fortran (Incompatible with IBM XLF)*Created by: nmhamster*
Trilinos OpenMP detection of flags for Fortran compiler does not work correctly with IBM XLF compiler on POWER8 platform. The detection assumes that the `-D` flag works for passing preprocessor defines through to...*Created by: nmhamster*
Trilinos OpenMP detection of flags for Fortran compiler does not work correctly with IBM XLF compiler on POWER8 platform. The detection assumes that the `-D` flag works for passing preprocessor defines through to the compiler. This is not the case for the IBM `xlf`and `xlf90` compilers where `-WF,-D` needs to be used if we expect the C preprocessor to be called. The correct check should be for `-qsmp=omp` to be found although its not clear this is correctly tested for (possible I have missed it in the error output).
```
/home/projects/pwr8-rhel72/ibm/xl/xlf/15.1.3/bin/xlf -O3 -g -qsmp=omp -qsimd=auto -L/home/projects/pwr8-rhel72/ibm/xl/xlf/15.1.3/lib -L/home/projects/pwr8-rhel72/ibm/xl/xlC/13.1.3/lib -lopen-pal -lxl -lxlopt -lxlf90 -lxlfmath -lm -libmc++ -lstdc++ -L/home/projects/pwr8-rhel72/openmpi/1.10.2/xl/13.1.3/cuda/7.5.7/lib -lmpi -O3 -g -qsmp=omp -qsimd=auto -L/home/projects/pwr8-rhel72/ibm/xl/xlf/15.1.3/lib -L/home/projects/pwr8-rhel72/ibm/xl/xlC/13.1.3/lib -lxlf90 -DOpenMP_FLAG_DETECTED -mp CMakeFiles/cmTC_48a9b.dir/src.F.o -o cmTC_48a9b -Wl,-export-dynamic
```
Yields (incorrect behavior) error of:
```
ld: warning: cannot find entry symbol nMP_FLAG_DETECTED; defaulting to 0000000010000860
```
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/489Remove redundant TriBITS includes in CMakeLists.txt files2016-12-01T14:24:56ZJames WillenbringRemove redundant TriBITS includes in CMakeLists.txt files*Created by: bartlettroscoe*
**Next Action Status:**
Changes accepted for SEACAS github repo. Changes for native Trilinos packages pushed. Next: Wait for STK to make changes in native repo and Kokkos to accept PR ...
**CC:** @trilin...*Created by: bartlettroscoe*
**Next Action Status:**
Changes accepted for SEACAS github repo. Changes for native Trilinos packages pushed. Next: Wait for STK to make changes in native repo and Kokkos to accept PR ...
**CC:** @trilinos/framework
**Description**
A long time ago, TriBITS added all the includes needed to process project, repository, and package files to the TriBITS.cmake file. This avoids the need to include the same files over and over again in user `*.cmake` and `CMakeLists.txt` files. This removes clutter and speeds up configures.
There is a single script in TriBITS that automatically does this upgrade:
TriBITS/refactoring/remove_std_tribits_includes_r.sh
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/491create 12.8 release2016-09-27T17:03:07ZJames Willenbringcreate 12.8 release*Created by: bmpersc*
Following checklist below and updating as needed:
```
rev 2016/01
```
Creating a New Trilinos (Release) Branch with GIT
A GIT branch can be used to maintai...*Created by: bmpersc*
Following checklist below and updating as needed:
```
rev 2016/01
```
Creating a New Trilinos (Release) Branch with GIT
A GIT branch can be used to maintain a version of the code that is different
than the primary development branch. This process describes how to create a
Trilinos release branch, but the steps can easily be generalized to apply to
other types of branches. There are eight steps in creating a Trilinos release
branch:
1. Clone Trilinos
You need to be in a clean state in order to branch Trilinos. It is best if you
start from a fresh clone, but any repository that is up-to-date and in a clean
state (no modified/untracked/etc files) can be used. This does mean that you can
not make changes and have them apply to the branch unless you have commited them
first. You will also need to clone each of the external repos that we release.
These repos will need to be cloned into the packages directory.
The list of external projects as of 1/12/2016 is:
CTrilinos
ForTrilinos
mesquite
moocho
optika
Sundance
To clone a copy of Trilinos type:
Command: git clone git@github.com:trilinos/Trilinos
cd Trilinos/packages
git clone git@github.com:trilinos/CTrilinos
git clone git@github.com:trilinos/ForTrilinos
git clone git@github.com:trilinos/mesquite
git clone git@github.com:trilinos/moocho
git clone git@github.com:trilinos/optika
git clone git@github.com:trilinos/sundance
1. Tag the working copy
The existing branch is now tagged to mark the point where the new branch will
diverge. This will need to be done for every external repository as well as the
Trilinos repository. To do this, from anywhere in your clone type
Command: git tag -a -m "<short message about tag>" <tag name>
For a release branch, tag name should be root-of-trilinos-release-XYZ-branch,
where XYZ is the release number with the component numbers separated by hyphens
instead of periods. For example for release 3.1.13, XYZ should be 3-1-13.
1. Create a branch
To create a branch, from anywhere in your clone type
Command: git branch <branch name>
For the Trilinos release version XYZ mentioned above, the branch name should be
trilinos-release-XYZ-branch.
1. Update to convert the working copy to the new branch
The act of creating a new branch does not change the existing working copy to
a that branch. To make this switch type
Command: git checkout <branch name>
To verify that the preceding command was successful, type
Command: git branch
The branch you are on will have a '*' infront of it.
1. Updates to make to the code when branching
When creating a new Trilinos release branch, the Trilinos version number needs
to be updated in the Trilinos/Version.cmake file. The values for
Trilinos_MAJOR_VERSION, Trilinos_MAJOR_MINOR_VERSION, Trilinos_VERSION_STRING,
and Trilinos_VERSION need to be updated. Also the Trilinos_REPOSITORY_BRANCH
will need to be set to the correct branch name and Trilinos_TESTING_TRACK will
need to be set to the correct cdash track. As well as
${PROJECT_NAME}_ENABLE_DEVELOPMENT_MODE will need to be set to OFF. This file
also needs to be updated on the master branch, However only the version numbers
should be changed to reflect the new development version.
After making these changes you will want to configure in a directory outside of
the repository you are working in. This is to update the files that are
dependent on the Version.cmake file as well as any other updates that
may have been made.
Finally, git commit the changes. In the commit message, note that branch name
is listed.
1. Tag the new branch
It is a good idea to tag the branch at this point so that the initial state of
the branch is easily retrievable. To perform this step, type
Command: git tag -a -m "<short message about tag>" <initial tag name>
For the Trilinos release version XYZ mentioned above, the initial tag name
should be initial-trilinos-release-XYZ-branch.
1. Make the branch and tags public
At this point none of these changes, tags or the branch will be publicly
available we need to push them to the public repository, which should be origin.
There is a special way that you have to push branches to the public repository.
To push the branch type
Command: git push origin <local branch name>:<public branch name>
This will push the branch named <local branch name> and the new commits on it
from your clone to origin with the name <public branch name>. Note that you can
rename the branch by giving a different name for <public branch name>, but
recommend not doing this unless you need to fix the name of the branch for some
reason.
Tags are easier to push, you can push them one at a time like the branch, but it
is easier to push all of them at once. To push the tags type
Command: git push --tags
1. Test the new branch
It is a good idea to test the new branch to help make sure that the above
process has been completed properly. As a part of the general release process,
many tests need to be run. This step simply refers to running a few simple
sanity checks (for example, build a few Trilinos packages and run ctest for
those packages) to work out any obvious problems before the branch is subjected
to the more complete test suite.
---
Reference on related git commands:
When you clone Trilinos you get a copy of every branch and tag that is on the
public repository. However, you do not have a local copy of the branch (unless
you used eg to clone) until you set it up. To checkout a different branch of
Trilinos, from the repository you just cloned type
Command: git checkout --track origin/<name of branch>
This will create a local branch for the given branch and check it out for you.
In addition any changes made to this branch will be pushed back to the correct
branch on origin when you push. This is what is called a tracking branch. Once
you have created a local tracking copy of a branch you won't have to do it again
in the same clone. Instead if you want to go to a different branch, back to
master for instance, and want to checkout the branch again you only need to type
command: git checkout <name of branch>
Tags, like branches, are all copied to your local repository when you clone.
Checking out a tag is similar to checking out a branch, but since tags only
point to a specific commit you do not need to create a local copy of the tag,
you only need to type
command: git checkout <name of tag>
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/492Anasazi: BSD license?2017-03-30T20:46:15ZJames WillenbringAnasazi: BSD license?*Created by: mhoemmen*
@csiefer2 asked me to post this issue since he's having trouble logging into Github.
Customer requests BSD license for Anasazi, which reportedly has an LGPL license.
*Created by: mhoemmen*
@csiefer2 asked me to post this issue since he's having trouble logging into Github.
Customer requests BSD license for Anasazi, which reportedly has an LGPL license.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/493Anasazi: BSD license?2016-07-12T17:56:47ZJames WillenbringAnasazi: BSD license?*Created by: mhoemmen*
@csiefer2 requested that I post the following issue, since he's having troubles logging into Github.
Anasazi reportedly still has an LGPL license. A customer requested a BSD license for Anasazi.
*Created by: mhoemmen*
@csiefer2 requested that I post the following issue, since he's having troubles logging into Github.
Anasazi reportedly still has an LGPL license. A customer requested a BSD license for Anasazi.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/494Trilinos_ENABLE_FORTRAN=OFF still complains that it can't find Fortran compiler2016-07-13T13:36:28ZJames WillenbringTrilinos_ENABLE_FORTRAN=OFF still complains that it can't find Fortran compiler*Created by: leonavery*
I'm trying to build trilinos on a Mac, thus without Fortran. I thought this would be straightforward. I start with `cmake -D Trilinos_ENABLE_FORTRAN=OFF trilinos-12.6.3-Source`, which creates a bunch of output th...*Created by: leonavery*
I'm trying to build trilinos on a Mac, thus without Fortran. I thought this would be straightforward. I start with `cmake -D Trilinos_ENABLE_FORTRAN=OFF trilinos-12.6.3-Source`, which creates a bunch of output that I attach below. The key point, though, is that it ends with
```
CMake Error at cmake/tribits/core/package_arch/TribitsGlobalMacros.cmake:1669 (ENABLE_LANGUAGE):
No CMAKE_Fortran_COMPILER could be found.
Tell CMake where to find the compiler by setting either the environment
variable "FC" or the CMake cache entry CMAKE_Fortran_COMPILER to the full
path to the compiler, or to the compiler name if it is in the PATH.
Call Stack (most recent call first):
cmake/tribits/core/package_arch/TribitsProjectImpl.cmake:188 (TRIBITS_SETUP_ENV)
cmake/tribits/core/package_arch/TribitsProject.cmake:93 (TRIBITS_PROJECT_IMPL)
CMakeLists.txt:90 (TRIBITS_PROJECT)
-- Configuring incomplete, errors occurred!
See also "/Users/lavery/Documents/OneDrive/fenics/CMakeFiles/CMakeOutput.log".
See also "/Users/lavery/Documents/OneDrive/fenics/CMakeFiles/CMakeError.log".
```
I also tried to fool it with CMAKE_Fortran_COMPILER=/usr/bin/true, but it's too smart for that.
So how do I build without Fortran? I assume the existence of the Trilinos_ENABLE_FORTRAN=OFF option means this is supposed to be possible -- what am I doing wrong?
Thanks.
[trilinos_cmake.TXT](https://github.com/trilinos/Trilinos/files/360057/trilinos_cmake.TXT)
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/501Develop and use git commit template for Trilinos repo2017-05-15T12:56:09ZJames WillenbringDevelop and use git commit template for Trilinos repo*Created by: bartlettroscoe*
**CC:** @trilinos/framework
**Description:**
Using a commit template has been shown on other projects to help make commit messages more consistent and contain the proper information.
This story is to cre...*Created by: bartlettroscoe*
**CC:** @trilinos/framework
**Description:**
Using a commit template has been shown on other projects to help make commit messages more consistent and contain the proper information.
This story is to create a git commit template that will be used by default for all Trilinos commits.
**Definition of Done:**
Git commit template is installed and presented for all Trilinos commits (but the commit author can modify the commit in the editor before the commit is created).
**Tasks:**
1. Learn and document how a git commit template works (see [here](https://github.com/TriBITSPub/TriBITS/issues/138#issuecomment-233959791)) [Done]
2. Develop template for a Trilinos commits (i.e. on a Google Doc) (see [below](https://github.com/trilinos/Trilinos/issues/501#issuecomment-233965160)) ... IN PROGRESS ...
3. Develop automated process for installing git commit hooks (e.g. as a side-effect of running the CMake configure) (see [here](https://github.com/TriBITSPub/TriBITS/issues/138#issuecomment-233962167)) ... Waiting to be worked ...
Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/536Setup testing for intel 162016-08-30T16:25:46ZJames WillenbringSetup testing for intel 16*Created by: bmpersc*
Need to setup testing using intel 16 compilers to support KNL platforms.
*Created by: bmpersc*
Need to setup testing using intel 16 compilers to support KNL platforms.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/541Many automated tests are not appearing on the dashboard2016-08-15T17:04:38ZJames WillenbringMany automated tests are not appearing on the dashboard*Created by: jhux2*
@tawiesn @aprokop @bartlettroscoe The MueLu nightly dashboard is no longer reporting tests from our two main test machines, geminga and enigma. The tests from those two machines last appeared on August 1st. I don't...*Created by: jhux2*
@tawiesn @aprokop @bartlettroscoe The MueLu nightly dashboard is no longer reporting tests from our two main test machines, geminga and enigma. The tests from those two machines last appeared on August 1st. I don't know if it's related, but there was an automated tribits snapshot into Trilinos on that same day. Below is an error reported from tribits on geminga that appears to be related this issue.
```
Traceback (most recent call last):
File
"/home/aprokop/code/trilinos-test/trilinos/cmake/ctest/drivers/geminga/../cron_driver.py",
line 23, in <module>
tdd_driver.run_driver(this_path, repo_path)
File
"/data/code/trilinos-test/trilinos/cmake/tribits/dashboard_driver/tdd_driver.py",
line 271, in run_driver
"CTEST_BINARY_DIRECTORY" : tddDashboardRootDir+"/TDD_BUILD",
File
"/data/code/trilinos-test/trilinos/cmake/tribits/dashboard_driver/tdd_driver.py",
line 182, in invoke_ctest
extraEnv = environment
File
"/data/code/trilinos-test/trilinos/cmake/tribits/dashboard_driver/../python_utils/GeneralScriptSupport.py",
line 469, in echoRunSysCmnd
print(" Appending environment:" + extraEnv + "\n")
TypeError: cannot concatenate 'str' and 'dict' objects
Ending nightly Trilinos development testing on geminga: Fri Aug 5
03:00:02 MDT 2016
```
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/545PyTrilinos library being exported when it shouldn't be2016-12-13T03:33:26ZJames WillenbringPyTrilinos library being exported when it shouldn't be*Created by: bmpersc*
Bill Spotz reported that the export system for Trilinos is exporting the PyTrilinos library which is a problem since it depends on the python library. This causes linking errors when people use find_package(Trilino...*Created by: bmpersc*
Bill Spotz reported that the export system for Trilinos is exporting the PyTrilinos library which is a problem since it depends on the python library. This causes linking errors when people use find_package(Trilinos) to get all the necessary information for Trilinos. The PyTrilinos library is in the list of Trilinos libraries, but it won't ever link. The sticking point here is that this library needs to be installed to work properly, but should not be in the export files.
I'm not sure of the right way to solve this. Should this be a special option passed in to the tribits_add_library? would doing that have impact on linking other things that are currently working? Maybe this should be a post processing step stripping it out for only the export. We'll need to look into the right way to do this.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/546Make Trilinos' use of ETI consistent2017-06-02T21:07:25ZJames WillenbringMake Trilinos' use of ETI consistent*Created by: bmpersc*
Trilinos wants to move to ETI to be enabled by default. This requires that all packages use the same ETI system. Currently there are 3, maybe more in Tpetra, Muelu and ifpack2. The goal is to make sure that turning...*Created by: bmpersc*
Trilinos wants to move to ETI to be enabled by default. This requires that all packages use the same ETI system. Currently there are 3, maybe more in Tpetra, Muelu and ifpack2. The goal is to make sure that turning on ETI will not make obscure builds fail due to combining packages that aren't normally during our testing.
Reduce build times for Trilinos