Trilinos issueshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues2019-01-29T13:04:23Zhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/4289Zoltan2: Create testing for useDegreeAsWeight in Zoltan2_ImbalanceMetricsUtil...2019-01-29T13:04:23ZJames WillenbringZoltan2: Create testing for useDegreeAsWeight in Zoltan2_ImbalanceMetricsUtility.hpp*Created by: MicheldeMessieres*
@trilinos/zoltan2
## Current Behavior
None of the zoltan2 tests call the code in Zoltan2_ImbalanceMetricsUtility.hpp for the option useDegreeAsWeight.
## Motivation and Context
A bug was fixed i...*Created by: MicheldeMessieres*
@trilinos/zoltan2
## Current Behavior
None of the zoltan2 tests call the code in Zoltan2_ImbalanceMetricsUtility.hpp for the option useDegreeAsWeight.
## Motivation and Context
A bug was fixed in #4271 but this could have been caught earlier if we had test coverage.
## Definition of Done
A unit test is added which fails if there are problems with useDegreeAsWeight code in Zoltan2_ImbalanceMetricsUtility.hpp. We might extend some current testing in the metric test.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4284Tpetra: matrix market reader to return StaticProfile containers2019-03-28T18:18:33ZJames WillenbringTpetra: matrix market reader to return StaticProfile containers*Created by: tjfulle*
## What
Update Tpetra matrix market reader to return graphs and matrices with `StaticProfile`
## Why
`DynamicProfile` is the current default profile type for `Tpetra::CrsMatrix` and `Tpetra::CrsGraph` but ...*Created by: tjfulle*
## What
Update Tpetra matrix market reader to return graphs and matrices with `StaticProfile`
## Why
`DynamicProfile` is the current default profile type for `Tpetra::CrsMatrix` and `Tpetra::CrsGraph` but is being deprecated in favor of `StaticProfile`.
@trilinos/tpetra
## Related Issues
#4282, #4283Tpetra: Deprecate DynamicProfilehttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/4283Tpetra: update tests to StaticProfile (downstream packages)2019-02-08T22:46:34ZJames WillenbringTpetra: update tests to StaticProfile (downstream packages)*Created by: tjfulle*
## What
Update Tpetra's downstream tests to pass if default profile type is `StaticProfile`
## Why
`DynamicProfile` is the current default profile type for `Tpetra::CrsMatrix` and `Tpetra::CrsGraph` but is...*Created by: tjfulle*
## What
Update Tpetra's downstream tests to pass if default profile type is `StaticProfile`
## Why
`DynamicProfile` is the current default profile type for `Tpetra::CrsMatrix` and `Tpetra::CrsGraph` but is being deprecated in favor of `StaticProfile`
@trilinos/tpetra
## Related Issues
#4282 Tpetra: Deprecate DynamicProfilehttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/4282Tpetra: update tests to StaticProfile2019-03-28T18:14:39ZJames WillenbringTpetra: update tests to StaticProfile*Created by: tjfulle*
## What
Update Tpetra tests to pass if default profile type is `StaticProfile`
## Why
`DynamicProfile` is the current default profile type for `Tpetra::CrsMatrix` and `Tpetra::CrsGraph` but is being deprec...*Created by: tjfulle*
## What
Update Tpetra tests to pass if default profile type is `StaticProfile`
## Why
`DynamicProfile` is the current default profile type for `Tpetra::CrsMatrix` and `Tpetra::CrsGraph` but is being deprecated in favor of `StaticProfile`
@trilinos/tpetra
## Related Issues
#4278, #4279, #4280, #4281 Tpetra: Deprecate DynamicProfilehttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/4276ShyLU_DD/FROSch: Interface for each block is needed otherwise code stops.2019-01-28T13:21:17ZJames WillenbringShyLU_DD/FROSch: Interface for each block is needed otherwise code stops.*Created by: chochmuth*
@trilinos/shylu
With the introduction of the new graph interface entity structure, some new functions were implemented which do not account for "empty" blocks. Here, an empty block is either a block where no in...*Created by: chochmuth*
@trilinos/shylu
With the introduction of the new graph interface entity structure, some new functions were implemented which do not account for "empty" blocks. Here, an empty block is either a block where no interface was identified or a block which is not contributing to the corresponding coarse space (user choice). For example in `FROSch_GDSWCoarseOperator_def.hpp:345`
`for (UN i=0; i<interface->getEntity(0)->getNumNodes(); i++) {`
asserts to false for `getEntity(0)`, as `interface` might be empty.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4272The package Pliris needs to be elevated from ST to PT since it is being used ...2019-01-26T04:04:51ZJames WillenbringThe package Pliris needs to be elevated from ST to PT since it is being used by ATDM APP Gemma*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @trilinos/shylu, @srajama1 (Trilinos Linear Solvers Product Area Lead)
**Blocking:** #2597
## Description
The Gemma configuration of Trilinos currently enables the Tril...*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @trilinos/shylu, @srajama1 (Trilinos Linear Solvers Product Area Lead)
**Blocking:** #2597
## Description
The Gemma configuration of Trilinos currently enables the Trilinos package `Pliris` (see [TRIL-255](https://sems-atlassian-son.sandia.gov/jira/browse/TRIL-255)). However, the package `Pliris` is currently declared `ST` (Secondary Tested) and therefore is not included in any Trilinos PR builds.
Since an important internal Trilinos customer (i.e Gemma) is using `Pliris`, [by definition](http://trac.trilinos.org/wiki/TribitsLifecycleModelOverview#test_categories), it needs to be elevated from Secondary Tested (ST) to Primary Tested (PT). Otherwise, `Pliris` will not get enabled in Trilinos PR builds and therefore will not protect SPARC (see #2597).
## Proposed Solution
Update the line:
```
Pliris packages/pliris ST
```
to be
```
Pliris packages/pliris PR
```
in the file
* `Trilinos/PackagesList.cmake`
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4240Licensing of ML package is unclear2019-01-22T17:25:08ZJames WillenbringLicensing of ML package is unclear*Created by: Multimath*
Hi,
The licensing for the ML package is unclear. At the top of the COPYRIGHT file it claims to be licensed under the LGPL, but afterwards there is a section starting at:
https://github.com/trilinos/Trilinos...*Created by: Multimath*
Hi,
The licensing for the ML package is unclear. At the top of the COPYRIGHT file it claims to be licensed under the LGPL, but afterwards there is a section starting at:
https://github.com/trilinos/Trilinos/blob/4f15e6fb356295d8ba1e022e94d8b0bad732e082/packages/ml/COPYRIGHT#L82
which states: "Commercialization of this product is prohibited without notifying the
Department of Energy (DOE) or Sandia National Laboratory or Lawrence
Livermore National Laboratory (LLNL)."
Adding restrictions to the LGPL changes it to a weird chimeric not-really-open-source license (or maybe even not a license at all, see URL https://opensource.stackexchange.com/a/4985 ); if notification is important to you, I suggest that you change the prohibition to a request which explains the importance (if, for example, funding for the project development/maintenance is allocated based on the extent of such commercialization, I think that most users would comply with notification).https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4270TriKota: Build errors with Dakota 6.8 and newer2019-01-26T00:22:06ZJames WillenbringTriKota: Build errors with Dakota 6.8 and newer*Created by: briadam*
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
<!---
Note that an...*Created by: briadam*
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
<!---
Note that anything between these delimiters is a comment that will not appear
in the issue description once created. Click on the Preview tab to see what
everything will look like when you submit.
-->
<!---
Feel free to delete anything from this template that is not applicable to the
issue you are submitting.
-->
<!---
Replace <teamName> below with the appropriate Trilinos package/team name.
-->
@trilinos/trikota
<!---
Assignees: If you know anyone who should likely tackle this issue, select them
from the Assignees drop-down on the right.
-->
<!---
Lables: Choose any applicable package names from the Labels drop-down on the
right. Additionally, choose a label to indicate the type of issue, for
instance, bug, build, documentation, enhancement, etc.
-->
## Expectations
<!---
Tell us what you think should happen, how you think things should work, what
you would like to see in the documentation, etc.
-->
Trilinos should work when TriKota is enabled with Dakota 6.8 and newer.
## Current Behavior
Build fails due to Dakota not being able to find ROL headers. (Dakota now has an optional dependence on ROL)
## Motivation and Context
Trying to verify that recent changes in Dakota will not break TriKota users of Dakota.
## Definition of Done
<!---
Tell us what needs to happen. If necessary, give us a task list along the
lines of:
- [ ] First do this.
- [ ] Then do that.
- [ ] Also this other thing.
-->
Enabling TriKota should build and test with Dakota 6.8 or newer.
## Possible Solution
<!---
Not obligatory, but suggest a fix for the bug or documentation, or suggest
ideas on how to implement the addition or change.
-->
Ideally, want to allow TriKota/Dakota to use Trilinos ROL, however, this results in a circular dependency because ROL has an optional dependence on TriKota. For now, recommend workaround where Dakota's ROL is disabled when building under TriKota.
## Steps to Reproduce
<!---
Provide a link to a live example, or an unambiguous set of steps to reproduce
this issue. Include code to reproduce, if relevant.
1. Do this.
1. Do that.
1. Shake fist angrily at computer.
-->
Clone Trilinos, checkout devel, place Dakota in trilinos/packages/TriKota/Dakota. Configure Trilinos with TriKota enabled, get build error at make time.
## Your Environment
<!---
Include relevant details about your environment such that we can replicate this
issue.
-->
- **Relevant repo SHA1s:** Trilinos master at 4f15e6fb356295d8ba1e022e94d8b0bad732e082
- **Relevant configure flags or configure script:**
```
cmake \
-DCMAKE_BUILD_TYPE=RELEASE \
-DCMAKE_INSTALL_PREFIX=../install \
-DBUILD_SHARED_LIBS:BOOL=TRUE \
-DTrilinos_ENABLE_TESTS:BOOL=ON \
-DTrilinos_ENABLE_Teuchos:BOOL=ON \
-DTrilinos_ENABLE_ROL:BOOL=ON \
-DTrilinos_ENABLE_TriKota:BOOL=ON \
-DTrilinos_ENABLE_ALL_PACKAGES:BOOL=OFF \
-DTrilinos_ENABLE_ALL_FORWARD_DEP_PACKAGES:BOOL=OFF \
-DTrilinos_ENABLE_ALL_OPTIONAL_PACKAGES:BOOL=ON \
-DTrilinos_ENABLE_COMPLEX_DOUBLE:BOOL=ON \
../source
```
- **Operating system and version:** RHEL 7.6
- **Compiler and TPL versions:** Default RHEL7 toolchain (gcc-4.8.5) and TPLs
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4269Propose new Trilinos release model2019-03-03T18:38:58ZJames WillenbringPropose new Trilinos release model*Created by: mhoemmen*
@trilinos/framework @maherou @jwillenbring @bartlettroscoe
PR https://github.com/trilinos/Trilinos/pull/4259 led to a discussion about Trilinos versions, deprecation, and the Trilinos release model. I wanted ...*Created by: mhoemmen*
@trilinos/framework @maherou @jwillenbring @bartlettroscoe
PR https://github.com/trilinos/Trilinos/pull/4259 led to a discussion about Trilinos versions, deprecation, and the Trilinos release model. I wanted to summarize that here, and propose the following:
- Drop the official policy (which we haven't followed for years anyway)
- Embrace the current de facto policy (which I'll summarize below)
- Help users write code that works with multiple Trilinos package "versions"
# Official policy
Here is Trilinos' official policy:
1. Minor release every quarter
2. Major release every year
3. Backwards compatibility breaks only at major releases
4. If you want to break an interface, you must deprecate it the last minor release before a major release
When was the last time we did any of this? At least three years? We made a 12.14 release _tag_, but I wouldn't call that a "release" in any sense. @crtrott and I spent a ridiculous effort in Tpetra not to break backwards compatibility when we converted it to use Kokkos 2.0; the utter lack of interest in the release policy post 12.0 makes me feel like that was a waste of time.
# De facto policy
@ikalash, @rrdrake, @theguruat12, @micahahoward, @rppawlo, or @trilinos/framework may wish to chime in, but I would summarize the de facto "Trilinos versioning" policy for many internal applications as follows:
1. App either forks Trilinos, or picks a Trilinos "master" branch commit.
2. App defines its own acceptance testing for Trilinos.
3. When an app wants to update its Trilinos, it uses acceptance tests to decide when to merge / pull.
Many apps facilitate this by testing the app nightly against current master Trilinos.
4. Apps put pressure on Trilinos as needed to support their goals. Individual Trilinos developers use guidance from their managers to prioritize.
This implies that apps define their own "Trilinos versions." Apps actually get work done with this model. That, along with open access to Trilinos' repo on GitHub, likely explains the lack of enthusiasm for official Trilinos releases. I've gotten about as many complains about deprecation warnings ("hey, we can't build warning-free") as I've gotten about actual interface changes, so it's likely less effort just to break the build than it is to do an official deprecation (how long? who knows, since no official releases!).
# Help users write code that works with multiple Trilinos "versions"
What's missing from this model is a way for an app to work correctly with multiple Trilinos package versions at once. For example:
```c++
void my_app_function () {
#if PACKAGE_FOO_VERSION < SOME_MINIMUM
old_foo_function ();
#else
new_foo_function ();
#endif
}
```
A few packages have added this feature themselves. For example, Kokkos has a CMake option and macro to help manage deprecation. Tpetra just recently added this.
# Proposal
I propose the following:
1. Support the current de facto policy (see above).
2. Packages that have enough users to care, should define their own release cycle and policies.
3. Such packages should define macros to enable or disable deprecated code.
4. Such packages should define macros to test the version number in code. Version number can be whatever the package wants, as long as users can test when it increases.
The only packages that would need to opt in, are packages with external users who care about this policy, and whose interfaces change. Kokkos does all of these but (4), and (4) isn't hard (Kokkos has an outstanding issue to implement it).
# Summary
1. Embrace what we're doing now anyway.
2. Packages who care can add their own version macros.
What do y'all think?Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/4206cmake: RegularExpression::compile(): Error in compile.2019-01-16T22:12:05ZJames Willenbringcmake: RegularExpression::compile(): Error in compile.*Created by: hakonhagland*
I am trying to build trilinos on Ubuntu 18.10 (CMake version 3.12.1, GCC version 8.2.0)
```
git clone https://github.com/trilinos/Trilinos.git
cd Trilinos
mkdir build
cd build
sudo apt-get install libnet...*Created by: hakonhagland*
I am trying to build trilinos on Ubuntu 18.10 (CMake version 3.12.1, GCC version 8.2.0)
```
git clone https://github.com/trilinos/Trilinos.git
cd Trilinos
mkdir build
cd build
sudo apt-get install libnetcdf-dev libmatio-dev doxygen
pyenv local 2.7.15
cmake \
-DTPL_ENABLE_MPI=ON \
-DMPI_BASE_DIR=/usr/lib/x86_64-linux-gnu/openmpi \
-DTrilinos_ENABLE_ALL_PACKAGES=ON \
-DCMAKE_INSTALL_PREFIX=/opt/trilinos \
-D Trilinos_ENABLE_PyTrilinos:BOOL=ON \
-D BUILD_SHARED_LIBS:BOOL=ON \
.. # <path to Trilinos source>
```
This fails with
```
[...]
RegularExpression::compile(): Nested *?+.
RegularExpression::compile(): Error in compile.
CMake Error at cmake/tribits/core/package_arch/TribitsGlobalMacros.cmake:2760 (STRING):
STRING sub-command REGEX, mode MATCH failed to compile regex
"/home/hakon/Trilinos/packages/rol".
Call Stack (most recent call first):
cmake/tribits/core/package_arch/TribitsGlobalMacros.cmake:2803 (TRIBITS_EXCLUDE_FILES)
packages/rol/CMakeLists.txt:114 (TRIBITS_EXCLUDE_AUTOTOOLS_FILES)
[...]
RegularExpression::compile(): Nested *?+.
RegularExpression::compile(): Error in compile.
CMake Error at packages/PyTrilinos/cmake/UseSWIG.cmake:196 (IF):
if given arguments:
"/home/hakon/Trilinos/build/packages/PyTrilinos/src" "MATCHES" "^/home/hakon/Trilinos/packages/PyTrilinos/src"
Regular expression
"^/home/hakon/Trilinos/packages/PyTrilinos/src"
cannot compile
Call Stack (most recent call first):
packages/PyTrilinos/cmake/UseSWIG.cmake:302 (SWIG_ADD_SOURCE_TO_MODULE)
packages/PyTrilinos/src/CMakeLists.txt:330 (SWIG_ADD_MODULE)
-- Configuring incomplete, errors occurred!
```
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4258Remove deprecated inheritance of SerialDense matrices from Object2019-01-24T20:41:33ZJames WillenbringRemove deprecated inheritance of SerialDense matrices from Object*Created by: rhoope*
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
Teuchos: Mike Eldred i...*Created by: rhoope*
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
Teuchos: Mike Eldred is using SerialDenseMatrix objects for his work in Dakota and found relatively large memory bloat associated with inherited string data from the Object base class, eg labels. He also found side benefits associated with not inherting the Object operator<< method.
This is a follow on to Issue #4183 and essentially seeks to pull the trigger on the deprecation from 2014 in the Object class, cf Teuchos_Object.hpp:
> (mfh 23 Nov 2014) Pretty much just ignore the above
description of this class. Very few classes in Teuchos inherit
from Object. Such inheritance should be treated as deprecated
legacy behavior. It's not 1990 and C++ is not Java 1.0; we
don't need a common base class for everything.
<!---
Note that anything between these delimiters is a comment that will not appear
in the issue description once created. Click on the Preview tab to see what
everything will look like when you submit.
-->
<!---
Feel free to delete anything from this template that is not applicable to the
issue you are submitting.
-->
<!---
Replace <teamName> below with the appropriate Trilinos package/team name.
-->
@trilinos/teuchos
<!---
Assignees: If you know anyone who should likely tackle this issue, select them
from the Assignees drop-down on the right.
-->
<!---
Lables: Choose any applicable package names from the Labels drop-down on the
right. Additionally, choose a label to indicate the type of issue, for
instance, bug, build, documentation, enhancement, etc.
-->
Labels: performance
## Expectations
<!---
Tell us what you think should happen, how you think things should work, what
you would like to see in the documentation, etc.
-->
## Current Behavior
<!---
Tell us how the current behavior fails to meet your expectations in some way.
-->
## Motivation and Context
<!---
How has this expectation failure affected you? What are you trying to
accomplish? Why do we need to address this? What does it have to do with
anything? Providing context helps us come up with a solution that is most
useful in the real world.
-->
Here is Mike's summary:
> This patch removes Teuchos::Object from inheritance chains in all Teuchos::
SerialDense* classes. This has two primary effects:
> eliminates overhead from the Teuchos::Object data attributes, especially
the std::string label_.
> removes the operator<< (std::ostream& os, const Teuchos::Object& obj) that
has caused problems for us defining our own operators for Teuchos types.
*** Important note: the latter change may induce requirements on client code,
*** if they were reliant on this ostream operator. For Dakota, this is a good
*** thing as it provides the opportunity to replace an inconsistently formatted
*** operator (that has previously been in the way) with a tailored one.
## Definition of Done
<!---
Tell us what needs to happen. If necessary, give us a task list along the
lines of:
- [ ] First do this.
- [ ] Then do that.
- [ ] Also this other thing.
-->
The advertised deprecated inheritance of SerialDense matrices is removed.
## Possible Solution
<!---
Not obligatory, but suggest a fix for the bug or documentation, or suggest
ideas on how to implement the addition or change.
-->
## Steps to Reproduce
<!---
Provide a link to a live example, or an unambiguous set of steps to reproduce
this issue. Include code to reproduce, if relevant.
1. Do this.
1. Do that.
1. Shake fist angrily at computer.
-->
## Your Environment
<!---
Include relevant details about your environment such that we can replicate this
issue.
-->
- **Relevant repo SHA1s:**
- **Relevant configure flags or configure script:**
- **Operating system and version:**
- **Compiler and TPL versions:**
## Related Issues
<!---
If applicable, let us know how this bug is related to any other open issues:
-->
* Blocks
* Is blocked by
* Follows
* Precedes
* Related to
* Part of
* Composed of
## Additional Information
<!---
Anything else that might be helpful for us to know in addressing this issue:
* Configure log file:
* Build log file:
* Test log file:
* When was the last time everything worked (date/time; SHA1s; etc.)?
* What did you do that made the bug rear its ugly head?
* Have you tried turning it off and on again?
-->
I'm going to issue a pull request with at least two commits with the first containing changes needed to Teuchos proper followed by a second with the changes to client code throughout Trilinos identified using the GCC 4.8.4 PR testing setup reflected in cmake/std/PullRequestLinuxGCC4.8.4TestingSettings.cmake with Teuchos enabled and HDF5 disabled.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4254Teuchos errors in Werror build2019-02-01T22:24:19ZJames WillenbringTeuchos errors in Werror build*Created by: jwillenbring*
@trilinos/teuchos
@bartlettroscoe @hkthorn @mhoemmen
<!---
Assignees: If you know anyone who should likely tackle this issue, select them
from the Assignees drop-down on the right.
-->
<!---
Labl...*Created by: jwillenbring*
@trilinos/teuchos
@bartlettroscoe @hkthorn @mhoemmen
<!---
Assignees: If you know anyone who should likely tackle this issue, select them
from the Assignees drop-down on the right.
-->
<!---
Lables: Choose any applicable package names from the Labels drop-down on the
right. Additionally, choose a label to indicate the type of issue, for
instance, bug, build, documentation, enhancement, etc.
-->
## Expectations
Teuchos should build warning free as a matter of code quality, and because of important customer requirements. We are currently using the following cxxflags for this build:
`-Wall -ansi -pedantic -Werror -Wno-unknown-pragmas -Wno-narrowing -Wno-pragmas -Wno-delete-non-virtual-dtor`
## Current Behavior
<!---
Tell us how the current behavior fails to meet your expectations in some way.
-->
Currently Teuchos has a number of warnings that are promoted to errors in this build as seen [here](https://testing.sandia.gov/cdash/viewBuildError.php?buildid=4448361).
## Motivation and Context
<!---
How has this expectation failure affected you? What are you trying to
accomplish? Why do we need to address this? What does it have to do with
anything? Providing context helps us come up with a solution that is most
useful in the real world.
-->
We are working to set up dev->master and pull request builds that use these flags for GCC 7.2 to protect the code from the introduction of more warnings. We are starting with some low-level packages as some warnings from these packages have the potential to impact packages downstream in this build.
## Definition of Done
<!---
Tell us what needs to happen. If necessary, give us a task list along the
lines of:
- [ ] First do this.
- [ ] Then do that.
- [ ] Also this other thing.
-->
Teuchos builds warning free with the flags above for GCC 7.2.
## Steps to Reproduce
<!---
Provide a link to a live example, or an unambiguous set of steps to reproduce
this issue. Include code to reproduce, if relevant.
1. Do this.
1. Do that.
1. Shake fist angrily at computer.
-->
The GitHub Trilinos fork
jwillenbring/Trilinos
has a branch
jwillenbring-PR-Werror-2
that can be merged in to test via submitting a PR. If that is done, only the Teuchos changes should be merged for now (not the PR test definition changes). Alternatively, @jwillenbring can test any proposed solutions if you prefer.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4238Disable Fortran in one of the Trilinos PR builds2019-01-31T20:57:09ZJames WillenbringDisable Fortran in one of the Trilinos PR builds*Created by: bartlettroscoe*
CC: @trilinos/framework, @mhoemmen, @rppawlo, @bathmatt, @jmgate, @fryeguy52
There are several projects that disable Fortran when building Trilinos. Currently, the EMPIRE ATDM Trilinos configuration dis...*Created by: bartlettroscoe*
CC: @trilinos/framework, @mhoemmen, @rppawlo, @bathmatt, @jmgate, @fryeguy52
There are several projects that disable Fortran when building Trilinos. Currently, the EMPIRE ATDM Trilinos configuration disables Fortran. (But that will chance once we fully merge the SPARC and EMPIRE ATDM Trilinos configurations since the SPARC configuration enables Fortran.) The Drekar developers disable Fortran in their configurations (which is not likely to change). Also, many people who build on Macs disable Fortran (since Macs don't come with a Fortran compiler by default).
Therefore, it is important for Trilinos to support a Fortran-less configuration and build. Therefore, at least one of the Trilinos PR builds needs to set `Trilinos_ENABLE_Fortran=OFF`.
Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/4205Panzer: Cleanup of Workset interface2019-01-22T15:22:38ZJames WillenbringPanzer: Cleanup of Workset interface*Created by: seamill*
## Motivation and Context
Currently the workset is more or less a massive storage container for everything we require, and much of it is stored in structure form (direct access to class members). The goal of thi...*Created by: seamill*
## Motivation and Context
Currently the workset is more or less a massive storage container for everything we require, and much of it is stored in structure form (direct access to class members). The goal of this update is to add a function interface to access these calls, and to strip everything out of worksets that isn't required.
The main reason for doing so is to allow for on-demand allocation and filling of geometry/topological data arrays as required by the derived code. Currently the workset allocates and fills *everything* that could possibly be required by the user, which takes lots of memory, and a bit of compute time. By making these calls on-demand, the total allocations made will be greatly reduced for most applications.
Making the interface on-demand also cleans up the workset construction by not requiring the user to know what Basis/Cubature/Geometry/Topology is required by the derived FEM/FV/FD code during workset construction.
@trilinos/panzer
## What do we keep/remove/redesign
Ideally, worksets would be a simple container that would look like:
```c++
class Workset
{
public:
using Scalar = double;
using Index = int;
Index
numDimensions() const;
Index
subcellIndex() const;
Kokkos::View<const Scalar***>
cellVertices() const;
const std::string &
blockID() const;
Kokkos::View<const Index*>
localCellIndexes() const;
const panzer::SubcellConnectivity &
getSubcellConnectivity(const int subcell_dimension) const;
const panzer::IntegrationValues2<Scalar> &
getIntegrationValues(const panzer::IntegrationDescriptor & description) const;
const panzer::IntegrationRule &
getIntegrationRule(const panzer::IntegrationDescriptor & description) const;
panzer::BasisValues2<Scalar> &
getBasisValues(const panzer::BasisDescriptor & basis_description,
const panzer::IntegrationDescriptor & integration_description) const;
const panzer::BasisValues2<Scalar> &
getBasisValues(const panzer::BasisDescriptor & basis_description,
const panzer::IntegrationDescriptor & integration_description) const;
const panzer::BasisValues2<Scalar> &
getBasisValues(const panzer::BasisDescriptor & basis_description,
const panzer::PointDescriptor & point_description) const;
const panzer::PointValues2<Scalar> &
getPointValues(const panzer::PointDescriptor & point_description) const;
const panzer::PureBasis &
getBasis(const panzer::BasisDescriptor & description) const;
Index
numCells() const;
Index
numOwnedCells() const;
Index
numGhostCells() const;
Index
numVirtualCells() const;
std::ostream &
operator<<(std::ostream& os, const panzer::Workset& w);
protected:
...
};
```
Naturally, there are a few issues with this. Having 'const' everywhere is required since worksets are passed around as const, but it will make things tricky when adding an on-demand feature. For now we can get away with having a shared pointer to an underlying class that does all the mutable stuff... assuming this doesn't cause issues with CUDA.
It also leaves the question of what to do with the rest of the interface. As far as I can tell, the above is missing the following (most of which probably shouldn't be in the workset):
```c++
Teuchos::RCP< std::vector<std::string> > basis_names;
void setNumberOfCells(int o_cells,int g_cells,int v_cells);
void setIdentifier(std::size_t identifier) { identifier_ = identifier; }
std::size_t getIdentifier() const { return identifier_; }
double alpha;
double beta;
double time;
double step_size;
double stage_number;
std::vector<double> gather_seeds; // generic gather seeds
bool evaluate_transient_terms;
Teuchos::RCP<WorksetDetails> other;
class WorksetDetailsAccessor;
```
I also don't know why there are multiple 'WorksetDetails' available in a workset.
If @eric-c-cyr and @rppawlo could run me though the reasoning behind the additional workset stuff, I would be grateful.
## Definition of Done
The updates to workset are straightforward. Updating Drekar, Charon, and the various EMPIRE codes will be a bit tricky so we will break it into a set of phases. Updating Charon and Drekar may require some help from @jmgate. Updates to Empire will probably go smoother with @CamelliaDPG.
### Phase 1
Workset interface changes:
- [ ] Merge Workset and WorksetDetails into a single class.
- [ ] Clean up and minimize interface based after discussing things with Eric and Roger.
- [ ] Clean up workset construction interface (currently there are multiple conflicting ways to do this)
- [ ] Deprecate the old interface
- [ ] Deprecate old construction scheme
- [ ] Update Drekar
- [ ] Update Charon
- [ ] Update EMPIRE
### Phase 2
Workset on-demand changes:
- [ ] Modify workset so that requesting things using `Descriptors` will spawn new BasisValues/PointValues/IntegrationRules/etc.
- [ ] Remove 'old' deprecated interface
- [ ] Remove alternative construction schemes
Note that we will allow the worksets to be fully allocated/filled if the user requests this using the construction interface (i.e. WorksetNeeds is passed to the construction scheme).
### Phase 3
Update BasisValues2 class
- [ ] Split `BasisValues2` into two classes: `BasisValues` and `BasisIntegrationValues`
- [ ] Add function interface to new classes
- [ ] Implement on-demand calculations of various datasets
- [ ] Deprecate old interface
- [ ] Update Drekar
- [ ] Update Charon
- [ ] Update EMPIRE
### Phase 4
Update IntegrationValues2 class
- [ ] Rename to `IntegrationValues`
- [ ] Add function interface to new classes
- [ ] Implement on-demand calculations of various datasets
- [ ] Deprecate old interface
- [ ] Update Drekar
- [ ] Update Charon
- [ ] Update EMPIRE
### Phase 5
Update PointValues2 class
- [ ] Rename to `PointValues`
- [ ] Add function interface to new classes
- [ ] Implement on-demand calculations of various datasets
- [ ] Deprecate old interface
- [ ] Update Drekar
- [ ] Update Charon
- [ ] Update EMPIRE
### Phase 6
Update subcell connectivity interface
- [ ] Add node/edge/face subcell connectivity to topological mesh analysis in Panzer (lots of questions here)
- [ ] Add node/edge/face subcell connectivities to workset (on-demand)
- [ ] Deprecate old interface
- [ ] Update Drekar
- [ ] Update Charon
- [ ] Update EMPIRE
### Phase 7
Cleanup
- [ ] Once everyone stops yelling at me, we can go ahead and remove the deprecated interface
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4219Elevate ShyLU_Node from ST to PT since it is being used by SPARC?2019-01-26T04:05:03ZJames WillenbringElevate ShyLU_Node from ST to PT since it is being used by SPARC?*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @trilinos/shylu, @srajama1 (Trilinos Linear Solvers Product Area Lead)
**Blocking:** #2597
## Description
The current SPARC Trilinos configuration explicitly enables `S...*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @trilinos/shylu, @srajama1 (Trilinos Linear Solvers Product Area Lead)
**Blocking:** #2597
## Description
The current SPARC Trilinos configuration explicitly enables `ShyLU_Node` subpackage `ShyLU_NodeHTS` (see [here](https://sems-atlassian-son.sandia.gov/jira/browse/TRIL-212?focusedCommentId=25503&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-25503). Therefore, ATDM Trilinos builds supporting SPARC are enabling ShyLU_Node, for example, as shown [here](https://testing.sandia.gov/cdash-dev-view/viewConfigure.php?buildid=4427483) showing:
```
...
-- Setting Trilinos_ENABLE_ShyLU_NodeHTS=ON
-- Setting Trilinos_ENABLE_ShyLU_NodeTacho=ON
-- Setting Trilinos_ENABLE_ShyLU_Node=ON
...
Final set of enabled packages: ... ShyLU_Node ... 41
Final set of enabled SE packages: ... ShyLU_NodeHTS ShyLU_NodeTacho ShyLU_Node ... 112
```
So it looks like `ShyLU_NodeTacho` may be getting implicitly enabled by accident. (We will need to see if SPARC actually using `ShyLU_NodeTacho` or not.) But `ShyLU_NodeTacho` is already declared to be `PT` (Primary Tested) but `ShyLU_NodeHTS` is currently declared to be `ST` (Secondary Tested).
In any case, since an important internal Trilinos customer (i.e SPARC) is using `ShyLU_NodeHTS`, [by definition](http://trac.trilinos.org/wiki/TribitsLifecycleModelOverview#test_categories), it needs to be elevated from Secondary Tested (ST) to Primary Tested (PT). Otherwise, `ShyLU_NodeHTS` will not get enabled in Trilinos PR builds and therefore will not protect SPARC (see #2597).
## Proposed Solution
Update the line:
```
HTS hts ST OPTIONAL
```
to be
```
HTS hts PT OPTIONAL
```
in the file
* Trilinos/packages/shylu/shylu_node/cmake/Dependencies.cmake
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4160ShyLU/Tacho: Incorrectly gets disabled when all-caps version of RDC CMake opt...2019-01-11T17:20:33ZJames WillenbringShyLU/Tacho: Incorrectly gets disabled when all-caps version of RDC CMake option is used*Created by: theguruat12*
@trilinos/framework @mhoemmen
When we use the all-caps `KOKKOS_ENABLE_CUDA_RELOCATABLE_DEVICE_CODE:BOOL=ON` instead of the CamelCase `Kokkos_ENABLE_Cuda_Relocatable_Device_Code:BOOL=ON`, Tacho doesn't get d...*Created by: theguruat12*
@trilinos/framework @mhoemmen
When we use the all-caps `KOKKOS_ENABLE_CUDA_RELOCATABLE_DEVICE_CODE:BOOL=ON` instead of the CamelCase `Kokkos_ENABLE_Cuda_Relocatable_Device_Code:BOOL=ON`, Tacho doesn't get disabled, and CMake stops with the error that @bartlettroscoe set up in #2580.
## Possible Solution
Fix both `shylu/shylu_node/tacho/CMakeLists.txt` and `cmake/RepositoryDependenciesSetup.cmake` to use the following:
```
SET(SHYLUNODE_ENABLE_RDC OFF)
IF (DEFINED Kokkos_ENABLE_Cuda_Relocatable_Device_Code)
IF (DEFINED KOKKOS_ENABLE_CUDA_RELOCATABLE_DEVICE_CODE)
IF ((Kokkos_ENABLE_Cuda_Relocatable_Device_Code AND (NOT KOKKOS_ENABLE_CUDA_RELOCATABLE_DEVICE_CODE)) OR ((NOT Kokkos_ENABLE_Cuda_Relocatable_Device_Code) AND KOKKOS_ENABLE_CUDA_RELOCATABLE_DEVICE_CODE))
MESSAGE (FATAL_ERROR "You set two different capitalizations of the RDC flag with different values; this is a bad idea.")
ENDIF ()
ENDIF ()
ENDIF ()
IF (DEFINED Kokkos_ENABLE_Cuda_Relocatable_Device_Code AND Kokkos_ENABLE_Cuda_Relocatable_Device_Code)
SET(SHYLUNODE_ENABLE_RDC ON)
ENDIF()
IF (DEFINED KOKKOS_ENABLE_CUDA_RELOCATABLE_DEVICE_CODE AND KOKKOS_ENABLE_CUDA_RELOCATABLE_DEVICE_CODE)
SET(SHYLUNODE_ENABLE_RDC ON)
ENDIF()
IF (NOT SHYLUNODE_ENABLE_RDC)
MESSAGE(WARNING "ShyLu/Tacho requires CUDA relocatable device code to be enabled if CUDA is enabled. Set: KOKKOS_ENABLE_CUDA_RELOCATABLE_DEVICE_CODE=ON ")
ENDIF()
```
## Related Issues
* Related to #2580 https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4201Set Trilinos_ENABLE_DEBUG=ON for all 'debug' ATDM Trilinos bulds2019-01-16T17:41:12ZJames WillenbringSet Trilinos_ENABLE_DEBUG=ON for all 'debug' ATDM Trilinos bulds*Created by: bartlettroscoe*
CC: @fryeguy52, @rppawlo, @mhoemmen
In the current ATDM Trilinos 'debug' configurations, only the options `Kokkos_ENABLE_Debug_Bounds_Check=ON` and `KOKKOS_ENABLE_DEBUG=ON` are getting set. That leaves ...*Created by: bartlettroscoe*
CC: @fryeguy52, @rppawlo, @mhoemmen
In the current ATDM Trilinos 'debug' configurations, only the options `Kokkos_ENABLE_Debug_Bounds_Check=ON` and `KOKKOS_ENABLE_DEBUG=ON` are getting set. That leaves a lot of runtime debug-mode checking that is built into Trilinos turned off. It would be much better to set `Trilinos_ENABLE_DEBUG=ON`. That enables a lot of this extra runtime debug-mode checking that can help catch developer mistakes.
Given the PR #4198 that just got merged, hopefully we can finally set `Trilinos_ENABLE_DEBUG=ON` for ATDM Trilinos builds. Also, now that we know how to test SPARC and EMPIRE against the ATDM Trilinos build locally, we can check to see if this breaks anything in the ATDM APPs.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4196Trilinos no longer builds with Scalar=complex<float>2019-01-28T16:55:40ZJames WillenbringTrilinos no longer builds with Scalar=complex<float>*Created by: mhoemmen*
@trilinos/tpetra @trilinos/amesos2
I found this out when testing Amesos2. See e.g., #4194.
## Current Behavior
Tpetra and downstream classes do not build with `Scalar=complex<float>`. I get errors of th...*Created by: mhoemmen*
@trilinos/tpetra @trilinos/amesos2
I found this out when testing Amesos2. See e.g., #4194.
## Current Behavior
Tpetra and downstream classes do not build with `Scalar=complex<float>`. I get errors of the form discussed here: https://github.com/kokkos/kokkos/issues/1964 . The case `Scalar=Kokkos::complex<double>` still works, because it uses a different overload of these Kokkos functions that does not attempt to put the output type in a union with `unsigned long long int`.
## Motivation and Context
Sierra currently enables `complex<float>` in its Trilinos build. This error also showed up in #4194, since Amesos2 was incorrectly attempting to build with `Scalar=complex<float>`, even though it was not enabled in Tpetra.
## Possible Solution
I am working on a work-around, namely to overload `Kokkos::Impl::atomic_fetch_oper` and `Kokkos::Impl::atomic_oper_fetch` specifically for `Kokkos::complex<float>`.
## Steps to Reproduce
Set the CMake option `Trilinos_ENABLE_COMPLEX_FLOAT:BOOL=ON`.
## Related Issues
* Related to #4194 https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4193MueLu: add local values in regionalToComposite manually2019-03-06T08:25:51ZJames WillenbringMueLu: add local values in regionalToComposite manually*Created by: mayrmt*
@trilinos/muelu
## Expectations
Replace current use of `Epetra_CombineMode Epetra_AddLocalAlso` in the MueLu HHG driver by an implementation that performs the local adds manually when transforming a region matr...*Created by: mayrmt*
@trilinos/muelu
## Expectations
Replace current use of `Epetra_CombineMode Epetra_AddLocalAlso` in the MueLu HHG driver by an implementation that performs the local adds manually when transforming a region matrix back to a composite matrix.
## Current Behavior
In the HHG driver's routine `regionToComposite()`, we rely on the `Epetra_CombineMode Epetra_AddLocalAlso` to not only add values accross processes, but also to add process-local values.
## Motivation and Context
`Tpetra/Xpetra` does not support a `AddLocalAlso`-type CombineMode.
## Definition of Done
- [ ] Add manual add operation for processor-local values.
- [ ] Remove use of `Epetra_CombineMode Epetra_AddLocalAlso`.
## Possible Solution
This is already implemented for vector operations. We might follow a similar idea.
There's already some code that's trying to do that by perform inter-process add operations based on a `Xpetra::CombineMode Add`, but performs on-process operations separately. We just have to get it right.
## Related Issues
* Blocks #4084 https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4191Xpetra: CrsMatrix::isFillComplete() logic is wrong2019-01-15T05:29:44ZJames WillenbringXpetra: CrsMatrix::isFillComplete() logic is wrong*Created by: lucbv*
@trilinos/xpetra
## Expectations
`Xpetra::CrsMatrix` should behave as `Tpetra::CrsMatrix`.
## Current Behavior
When constructing an `Xpetra::CrsMatrix` with a fill completed `CrsGraph`, the matrix is automat...*Created by: lucbv*
@trilinos/xpetra
## Expectations
`Xpetra::CrsMatrix` should behave as `Tpetra::CrsMatrix`.
## Current Behavior
When constructing an `Xpetra::CrsMatrix` with a fill completed `CrsGraph`, the matrix is automatically fill completed.
## Motivation and Context
This discrepancy leads to unexpected behavior with the `Xpetra::CrsMatrix`
## Definition of Done
`Xpetra::CrsMatrix` and `Tpetra::CrsMatrix` behave the same
## Possible Solution
Change the logic in `Xpetra` to avoid having the `CrsMatrix` fill complete before it actually is.