Trilinos issueshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues2018-09-06T18:21:35Zhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/57Tpetra: Replace Node with Kokkos space2018-09-06T18:21:35ZJames WillenbringTpetra: Replace Node with Kokkos space*Created by: mhoemmen*
@trilinos/tpetra
This depends on #56 and #505.
Get rid of Node entirely. Replace with Kokkos space.
*Created by: mhoemmen*
@trilinos/tpetra
This depends on #56 and #505.
Get rid of Node entirely. Replace with Kokkos space.
Tpetra-backloghttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/182Implement Project-Wide Issue Management System2017-02-09T01:19:51ZJames WillenbringImplement Project-Wide Issue Management System*Created by: jwillenbring*
@maherou @bartlettroscoe @trilinos/framework
We need to implement a project-wide issue management system. It must work for both development-funded efforts, which are being required to apply more rigor to thei...*Created by: jwillenbring*
@maherou @bartlettroscoe @trilinos/framework
We need to implement a project-wide issue management system. It must work for both development-funded efforts, which are being required to apply more rigor to their issue tracking efforts, and for research-funded efforts, which will have more flexibility in use of the issue tracker. The system should have the following characteristics:
Usable: The system should not impose a heavy burden on Trilinos developers. Developers are familiar with a basic issue tracking system, and generally comfortable with using one. The extra requirements for the system should not require large additional time investments. For example, when filing or accepting a ticket, applying labels, estimating effort, assigning, etc shouldn't take more than a few extra minutes.
Well-defined: The process should be documented. Because of the traceability requirement listed below, it is important that certain parts of the process be followed carefully.
Traceable: A primary objective of the new issue management system is that customer requirements be traceable all the way to implementation and delivery. Requirements should be translated into specific issues in an epic-story-task hierarchy to support this traceability for large deliverables.
Visible: Current status should be easily visible for stakeholders, including customers, users, developers, and management.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/215Panzer: Clean up configure process2016-06-24T16:16:49ZJames WillenbringPanzer: Clean up configure process*Created by: bartlettroscoe*
When you try to configure Panzer under Trilinos, you must manually set several specialized options like:
```
-D Intrepid_ENABLE_DEBUG_INF_CHECK:BOOL=OFF \
-D IntrepidIntrepid2_ENABLE_DEBUG_INF_CHECK:BOO...*Created by: bartlettroscoe*
When you try to configure Panzer under Trilinos, you must manually set several specialized options like:
```
-D Intrepid_ENABLE_DEBUG_INF_CHECK:BOOL=OFF \
-D IntrepidIntrepid2_ENABLE_DEBUG_INF_CHECK:BOOL=OFF \
-D Teuchos_ENABLE_LONG_LONG_INT:BOOL=ON \
-D TPL_ENABLE_Boost:BOOL=ON \
-D TPL_ENABLE_BoostLib:BOOL=ON \
-D TPL_ENABLE_Netcdf:BOOL=ON \
```
These things should be enabled automatically when Panzer gets enabled (either implicitly or explicitly). This will simplify a lot of configure scripts involving Panzer (such as with Drekar and downstream projects).
**Tasks:**
1. Set `Intrepid2_ENABLE_DEBUG_INF_CHECK=OFF` automatically when Panzer is enabled (either explicitly or implicitly) ... The default will be set to OFF unconditionally ...
2. Gather up disables for common Panzer/Drekar usage into a CMake fragment file for reuse ...
3. Set up automated build of Panzer (with Drekar disables) on hansen for non-CUDA build and post to CDash ...
CC: @rppawlo, @bathmatt, @eric-c-cyr
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/560Ifpack2 SingletonFilter does not implement getGraph().2017-06-20T15:59:44ZJames WillenbringIfpack2 SingletonFilter does not implement getGraph().*Created by: kddevin*
@trilinos/ifpack2 @trilinos/muelu @trilinos/zoltan2
This issue blocks #244 , #547, #548.
Ifpack2 uses Zoltan2 for local ordering in Ifpack2_AdditiveSchwarz_def.hpp.
Zoltan2 works only with scalar_t={double, f...*Created by: kddevin*
@trilinos/ifpack2 @trilinos/muelu @trilinos/zoltan2
This issue blocks #244 , #547, #548.
Ifpack2 uses Zoltan2 for local ordering in Ifpack2_AdditiveSchwarz_def.hpp.
Zoltan2 works only with scalar_t={double, float, int}. To prevent compilation problems when scalar_t={std::complex, Sacado type} (issues #244, #547), we would like to use the RowGraph, obtained from RowMatrix::getGraph(), for ordering in Ifpack2.
We have implemented the use of RowGraph in Ifpack2 and Zoltan2 (see #548), and the compilation is fine now. But some MueLu tests fail with the following thrown error:
Ifpack2::SingletonFilter: does not support getGraph.
The failing tests are
72:MueLu_Helmholtz2DParallel_MPI_4
73:MueLu_Helmholtz3DParallel_MPI_4
74:MueLu_HelmholtzFEM2DParallel_MPI_4
75:MueLu_HelmholtzFEM3DParallel_MPI_4
@mhoemmen says many of the Filters in Ifpack2 don't correctly implement getGraph().
I do not know the best way to resolve this problem, as I do not know the purpose of the SingletonFilter, nor how to implement RowGraph for it. I am open to suggestions from @trilinos/ifpack2 or @trilinos/muelu .
Thank you!
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/634Fix warnings for dashboard builds2016-10-05T18:11:10ZJames WillenbringFix warnings for dashboard builds*Created by: MicheldeMessieres*
This effort will be to fix various warnings seen in dashboard builds.
Those errors are at:
http://my.cdash.org/index.php?project=Trilinos&parentid=1052339
Pull requests to fix the warnings will be made s...*Created by: MicheldeMessieres*
This effort will be to fix various warnings seen in dashboard builds.
Those errors are at:
http://my.cdash.org/index.php?project=Trilinos&parentid=1052339
Pull requests to fix the warnings will be made separately for each package.
The current list of packages with issues (from Jim's e-mail):
ROL
Stokhos - probably fixed already
Pamgen
ShyLU
Piro
Kokkos
Rythmos
Mesquite
Panzer
ML (will skip for this round because previous pull request is outstanding)
Pliris (will skip for this round because previous pull request is outstanding)
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/795Add Hessian support to Thyra Model Evaluator2017-01-13T12:34:20ZJames WillenbringAdd Hessian support to Thyra Model Evaluator*Created by: mperego*
Add Hessian support to Thyra Model Evaluator.
Details are provided here:
https://docs.google.com/document/d/14oek8UQdDmAn_V0s-zbWR-IsW9WBRKEIgh0Y5gsxiOY/edit#heading=h.ggzv0sz6p2bt*Created by: mperego*
Add Hessian support to Thyra Model Evaluator.
Details are provided here:
https://docs.google.com/document/d/14oek8UQdDmAn_V0s-zbWR-IsW9WBRKEIgh0Y5gsxiOY/edit#heading=h.ggzv0sz6p2bthttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/864Panzer: Refactor Point evaluation (ResponseScatterEvaluator_Probe) routines2017-07-27T15:23:25ZJames WillenbringPanzer: Refactor Point evaluation (ResponseScatterEvaluator_Probe) routines*Created by: rppawlo*
As part of #274, the ResponseScatterEvaluator_Probe functionality has been temporarily disabled. We will need to recover for application builds. Additionally, it turns out that there is no unit test for this evalua...*Created by: rppawlo*
As part of #274, the ResponseScatterEvaluator_Probe functionality has been temporarily disabled. We will need to recover for application builds. Additionally, it turns out that there is no unit test for this evaluator.
Definition of done:
1. Recover capability for applications using this test
2. Add a unit test to panzer to protect this capability in the future.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/891Set up automated Nightly testing for PyTrilinos2018-04-11T15:58:48ZJames WillenbringSet up automated Nightly testing for PyTrilinos*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @wfspotz
**Description:**
Currently PyTrilinos is not under any automated testing that gets posted up to the Trilinos CDash site:
* testing.sandia.gov/cdash/
See the...*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @wfspotz
**Description:**
Currently PyTrilinos is not under any automated testing that gets posted up to the Trilinos CDash site:
* testing.sandia.gov/cdash/
See the below email chain.
----
From: Bartlett, Roscoe A
Sent: Tuesday, November 29, 2016 4:10 PM
To: Spotz, William F
Cc: Willenbring, James M; Perschbacher, Brent M
Subject: RE: [Pytrilinos-regression] FAILED (c=1): Trilinos/PyTrilinos - Linux-GCC-4.7.2-MPI_RELEASE_DEBUG_SHARED_PT_CI - Continuous
Bill,
PyTrilinos was enabled by accident. See:
* https://github.com/trilinos/Trilinos/issues/482#issuecomment-263575023
* https://github.com/trilinos/Trilinos/commit/1b14dadb154a2f49e1097c91a0340d66c39306b6
It is not enabled in the correct PT CI build as shown here:
* http://testing.sandia.gov/cdash/index.php?project=Trilinos&parentid=2634468
Some work is going to need to be done before PyTrilinos can be built using the SEMS env and include in any automated testing. For example, currently, PyTrilinos is not tested in any automated Trilinos build uploaded to CDash:
* http://testing.sandia.gov/cdash/index.php?subproject=PyTrilinos&project=Trilinos&date=2016-11-28
Getting things set up to test PyTrilinos is something that you are going to need to take up with the Trilinos Framework team (i.e. Jim and Brent) and the SEMS team.
But at the very minimum, you should set up PyTrilinos testing on one of your machines where you have this working.
-Ross
----
From: Spotz, William F
Sent: Tuesday, November 29, 2016 4:04 PM
To: Bartlett, Roscoe A
Subject: Fwd: [Pytrilinos-regression] FAILED (c=1): Trilinos/PyTrilinos - Linux-GCC-4.7.2-MPI_RELEASE_DEBUG_SHARED_PT_CI - Continuous
Hi Ross,
So does “Pytrilinos-regression” include both of us?
If not, the configure errors were that
1) No python numpy module was found
2) The SWIG version, 1.3.40, was too old — required is 3.0.0
-Bill
----
From: CDash <trilinos-regression@sandia.gov>
Subject: [Pytrilinos-regression] FAILED (c=1): Trilinos/PyTrilinos - Linux-GCC-4.7.2-MPI_RELEASE_DEBUG_SHARED_PT_CI - Continuous
Date: November 29, 2016 at 1:13:33 AM MST
To: <pytrilinos-regression@software.sandia.gov>
Reply-To: <noreply@sandia.gov>
A submission to CDash for the project Trilinos has configure errors.
You have been identified as one of the authors who have checked in changes that are part of this submission or you are listed in the default contact list.
Details on the submission can be found at http://testing.sandia.gov/cdash/buildSummary.php?buildid=2633954
Project: Trilinos
SubProject: PyTrilinos
Site: crf450.srn.sandia.gov
Build Name: Linux-GCC-4.7.2-MPI_RELEASE_DEBUG_SHARED_PT_CI
Build Time: 2016-11-29T08:13:32 UTC
Type: Continuous
Configure errors: 1
*Configure*
Status: 1 (http://testing.sandia.gov/cdash/viewConfigure.php?buildid=2633954)
Output:
Configuring Trilinos build directory
-- PROJECT_SOURCE_DIR='/ascldap/users/rabartl/Trilinos.base/SEMSCIBuild/Trilinos'
-- PROJECT_BINARY_DIR='/home/rabartl/Trilinos.base/SEMSCIBuild/BUILD'
-- Trilinos_TRIBITS_DIR='/ascldap/users/rabartl/Trilinos.base/SE
-CDash on testing.sandia.gov
_______________________________________________
Pytrilinos-regression mailing list
Pytrilinos-regression@software.sandia.gov
https://software.sandia.gov/mailman/listinfo/pytrilinos-regression
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/932Expose Belos' fixed solver through Stratimikos2017-09-21T01:41:38ZJames WillenbringExpose Belos' fixed solver through Stratimikos*Created by: aprokop*
@trilinos/stratimikos @trilinos/belos
I have a code that uses Stratimikos/Thyra to run a preconditioned solve for a linear problem. I'd like to try out a preconditioner in a Richardson/fixed point iteration. Th...*Created by: aprokop*
@trilinos/stratimikos @trilinos/belos
I have a code that uses Stratimikos/Thyra to run a preconditioned solve for a linear problem. I'd like to try out a preconditioner in a Richardson/fixed point iteration. The easiest thing would be to try out the Belos' fixed point iteration (@mhoemmen @csiefer2 is it used/correct/recently tested?)
Unfortunately, it does not seem to be exposed through Stratimikos. I will probably have to fix this.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1169Tpetra: Add nonblocking MPI-global GEMV2017-10-26T20:53:11ZJames WillenbringTpetra: Add nonblocking MPI-global GEMV*Created by: mhoemmen*
@trilinos/tpetra
A collaborator would like to implement Pipelined GMRES (see #748 for comparison). This calls for a nonblocking MPI-global GEMV in order to implement the classical Gram-Schmidt projection step...*Created by: mhoemmen*
@trilinos/tpetra
A collaborator would like to implement Pipelined GMRES (see #748 for comparison). This calls for a nonblocking MPI-global GEMV in order to implement the classical Gram-Schmidt projection step. The implementation of Tpetra::idot (see #1013) currently supports this use case, but does not optimize the intraprocess dense matrix-vector product (GEMV). There are two issues:
1. Tpetra::idot does not call KokkosBlas::gemv for that case. Instead, it rolls its own kernel. This is likely to be slow for multivectors with many columns, and it may even run out of scratch memory on the GPU (which uses scratch for intermediate reduction results).
2. ( https://github.com/kokkos/kokkos-kernels/issues/16 ) KokkosBlas::gemv does not call the BLAS or cuBLAS (if appropriate). Instead, it rolls its own kernel, which has the same issues as the kernel that Tpetra::idot uses.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1312Zoltan2 partitioning metrics return scalar_t; should return double2019-01-21T23:08:51ZJames WillenbringZoltan2 partitioning metrics return scalar_t; should return double*Created by: kddevin*
Zoltan2's partitioning metrics class EvaluatePartition returns, among other things, imbalance values. Imbalance is inherently a float or double. While scalar_t is often float or double, it could be int. When sca...*Created by: kddevin*
Zoltan2's partitioning metrics class EvaluatePartition returns, among other things, imbalance values. Imbalance is inherently a float or double. While scalar_t is often float or double, it could be int. When scalar_t is int, returning imbalance as an int is inaccurate.
It appears that currently, all metrics are stored as scalar_t. We could store them as double instead.
@trilinos/zoltan2 https://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/1400Get CMake build system to take advantage of kokkos/Makefile.kokkos in setting...2017-12-15T18:13:23ZJames WillenbringGet CMake build system to take advantage of kokkos/Makefile.kokkos in setting compilers, compiler options etc.*Created by: bartlettroscoe*
**CC:** @kruger, @crtrott, @nmhamster, @dsunder, @ibaned
**Next Action Status:**
A new plan was discussed in detail on 8/1/2017. Next:@kruger will write up the detailed plan in kokkos/kokkos#878 and ...*Created by: bartlettroscoe*
**CC:** @kruger, @crtrott, @nmhamster, @dsunder, @ibaned
**Next Action Status:**
A new plan was discussed in detail on 8/1/2017. Next:@kruger will write up the detailed plan in kokkos/kokkos#878 and then track work there ...
**Description:**
The native Kokkos Makefile system takes advantage of fairly sophisticated makefile logic to define compilers, compiler options, and libraries given the input variables:
* `KOKKOS_ARCH`
* `KOKKOS_DEBUG`
* `KOKKS_CXX_STANDARD`
* etc. (could be more)
All of this logic is contain in the file kokkos/Makefile.kokkos shown at:
* https://github.com/kokkos/kokkos/blob/master/Makefile.kokkos
and this is in the Trilinos snapshot of kokkos shown here:
* https://github.com/trilinos/Trilinos/blob/develop/packages/kokkos/Makefile.kokkos
The goal is to leverage kokkos/Makefile.kokkos as much as possible in the CMake build system for Kokkos under Trilinos. We want the Trilinos CMake build of kokkos to produce, as much as possible, to create identical build lines to what the native Kokkos makefile system does.
The process might be to to:
1. Define CMake cache `Trilinos_ARCH` (and other already-defined Trilinos CMake vars) and then set the Kokkos input vars shown above.
2. Execute a dummy makefile pulling in Makefile.kokkos and extracting the out `KOKKOS_CXXFLAGS`, `KOKKOS_LDFLAGS`, etc., and the generated file KokkosCore_config.h file (and use it for the Kokkos_config.h file).
3. Set `CMAKE_CXX_FLAGS`, etc. using these outputs.
I think this needs to be done at the global level during the env probing (so it might need a new TriBITS callback function). But we will have to see.
**Repos, Issues, PRs, and Branches:**
The ATDM Tools & Dev Env issue tracking this work is:
* https://software-srn.sandia.gov/jira/browse/ATDV-90
The three GitHub repos, Issues, PRs, and branches involved are:
* Trilinos: git@github.com:trilinos/Trilinos.git
* Issue: https://github.com/trilinos/Trilinos/pull/1400
* PR: https://github.com/trilinos/Trilinos/pull/1884
* Branch: https://github.com/Tech-XCorp/Trilinos/tree/trilinos-kokkos-1400 (fork of trilinos/Trilinos) (Currently the branch `trilinos-kokkos-1400` is merged into the branch https://github.com/trilinos/Trilinos/tree/kokkos-promotion and will be merged to `develop` as part of merging `kokkos-promotion`).
* TriBITS: git@github.com:TriBITSPub/TriBITS.git
* Issue: https://github.com/TriBITSPub/TriBITS/issues/207 **[Closed]**
* PR: https://github.com/TriBITSPub/TriBITS/pull/233 **[Merged]**
* Branch: https://github.com/TriBITSPub/TriBITS/tree/kokkos-config-207 **[Merged]**
* kokkos: git@github.com:kokkos/kokkos.git
* Issue: https://github.com/kokkos/kokkos/issues/878 **[Closed]**
* PR: https://github.com/kokkos/kokkos/pull/1106 **[Merged]**
* Branch: https://github.com/Tech-XCorp/kokkos/tree/issue-878 (fork of kokkos/kokkos) **[Merged]**
To setup the repos and branches from scratch, do:
```
$ git clone git@github.com:trilinos/Trilinos.git
$ cd Trilinos/
$ git remote add tech-xcorp git@github.com:Tech-XCorp/Trilinos.git
$ git fetch tech-xcorp
$ git checkout --track tech-xcorp/trilinos-kokkos-1400
$ git clone git@github.com:TriBITSPub/TriBITS.git
$ cd TriBITS/
$ git checkout --track origin/kokkos-config-207
$ cd ..
$ git clone git@github.com:kokkos/kokkos.git
$ cd kokkos/
$ git remote add tech-xcorp git@github.com:Tech-XCorp/kokkos.git
$ git fetch tech-xcorp
$ git checkout --track tech-xcorp/issue-878
$ cd ..
```
With that setup, you should see:
```
$ ./cmake/tribits/python_utils/gitdist --dist-repos=.,TriBITS,kokkos dist-repo-status
---------------------------------------------------------------------------------------------
| ID | Repo Dir | Branch | Tracking Branch | C | M | ? |
|----|-----------------|----------------------|---------------------------------|---|---|---|
| 0 | Trilinos (Base) | trilinos-kokkos-1400 | tech-xcorp/trilinos-kokkos-1400 | | | |
| 1 | TriBITS | kokkos-config-207 | orign/kokkos-config-207 | | | |
| 2 | kokkos | issue-878 | tech-xcorp/issue-878 | | | |
---------------------------------------------------------------------------------------------
```
With that, one can configure and bulid Trilinos using the version of TriBITS and kokkos in those branches by adding the cmake configure options:
```
$ cmake \
-DTrilinos_TRIBITS_DIR:STRING=TriBITS/tribits \
-DKokkos_SOURCE_DIR_OVERRIDE:STRING=kokkos \
[option options] \
${TRILINOS_SRC_DIR}
```
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1403Panzer: Simplify response support2017-06-07T00:47:07ZJames WillenbringPanzer: Simplify response support*Created by: rppawlo*
This issue is to simplify the requirements for adding new response functions to panzer.
1. Naming of objects
2. work to eliminate the builder and factory as separate classes
3. Build simplified derived classes fro...*Created by: rppawlo*
This issue is to simplify the requirements for adding new response functions to panzer.
1. Naming of objects
2. work to eliminate the builder and factory as separate classes
3. Build simplified derived classes from decision tree
4. Implement point values evaluator as an examplehttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/1473Collect items for major refactoring of Thyra to make simpler and more sustain...2017-08-07T15:30:33ZJames WillenbringCollect items for major refactoring of Thyra to make simpler and more sustainable*Created by: bartlettroscoe*
**CC:** @trilinos/thyra, @rppawlo, @atoth1
**Description:**
Thyra is a feature-full but complex set of software supporting the development of abstract numerical algorithms (ANAs). Over the years since...*Created by: bartlettroscoe*
**CC:** @trilinos/thyra, @rppawlo, @atoth1
**Description:**
Thyra is a feature-full but complex set of software supporting the development of abstract numerical algorithms (ANAs). Over the years since Thyra has been in use, many potential developers have been scared off or intimidated by the complexity of Thyra.
This story is to collect a set of ideas on how we can refactor Thyra to make it simpler to understand, use, and extend, without destroying the OO design features and functionality.
To help collect these ideas, I have created the Google Doc "Simplifying Thyra":
* https://docs.google.com/document/d/1oHZzTHwl9D2lZ_on8HSg0zmAuB6wmToDtq2SOPzxmQs
For now we are just going to collect ideas in that document.
ToDo: Define full scope for this story and a clear definition of done.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1575Panzer: CONTRIBUTES-Style Evaluators2018-10-24T15:19:43ZJames WillenbringPanzer: CONTRIBUTES-Style Evaluators*Created by: jmgate*
`panzer::Integrator_BasisTimesScalar` and `Integrator_GradBasisDotVector` were refactored in fe8070f to have new constructors that allow a user to create the `Evaluator` in either an `EVALUATES` style (which is what...*Created by: jmgate*
`panzer::Integrator_BasisTimesScalar` and `Integrator_GradBasisDotVector` were refactored in fe8070f to have new constructors that allow a user to create the `Evaluator` in either an `EVALUATES` style (which is what has been done up to this point) or a `CONTRIBUTES` style. When using the latter, no memory is created to store the result of the `evaluateFields()` call; instead the result is simply contributed to some other `Evaluator`. This has great potential for memory savings. Additionally, these new constructors are compile-time checked, as opposed to the old `ParameterList` interface.
We need to begin refactoring the rest of the Panzer `Evaluator`s in a similar fashion. This issue is to be an over-arching issue that will link to smaller issues to tackle the `Evaluator`s themselves.
@trilinos/panzer
**Sub-issues:**
| Class | Issue | Status |
|:----- | ----- | ------ |
| `Integrator_BasisTimesVector` | #1624 | Closed |
| `Integrator_CurlBasisDotVector` | #1890 | Closed |
| `Integrator_DivBasisTimesScalar` | #1891 | Closed |
| `Integrator_GradBasisCrossVector` | #1892 | Closed |
| `Integrator_GradBasisTimesScalar` | #1893 | Open |
| `Integrator_Scalar` | #1894 | Open |
| `Integrator_TransientBasisTimesScalar` | #1895 | Open |https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1751Discuss and document workflow for directly snapshotting SEACAS into Trilinos ...2018-06-26T12:49:47ZJames WillenbringDiscuss and document workflow for directly snapshotting SEACAS into Trilinos to better serve ATDM*Created by: bartlettroscoe*
**Next Action Status:**
@gdsjaar to implement agreed to workflow on SEACAS github site then start doing new workflow ...
**CC:** @trilinos/framework, @gsjaardema
**Description:**
This story is t...*Created by: bartlettroscoe*
**Next Action Status:**
@gdsjaar to implement agreed to workflow on SEACAS github site then start doing new workflow ...
**CC:** @trilinos/framework, @gsjaardema
**Description:**
This story is to document a discussion and the final workflow for allowing @gsjaardema to directly SEACAS directly into Trilinos/packages/seacas/ in addition to shapshotting SEACAS into Sierra.base/seacas/ and then having that snapshotted from ther into Trilinos/packages/seacas/. The nature of the snapshotting process (i.e. never a merge) eliminates the potential for merge conflicts that might make the snapshotting from Sierra.base/seacas/ to Trilinos/packages/seacas/ more difficult. And this would allow @gsjaardema control to address issues for ATDM customers very quickly and simplify the version control and configuration of Trilinos for ATDM customers. For more background and discussion, see:
* https://software-srn.sandia.gov/jira/browse/SPAR-277
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1833Phalanx: explore DAG evaluation performance from single parallel_for launch2017-10-16T22:50:51ZJames WillenbringPhalanx: explore DAG evaluation performance from single parallel_for launch*Created by: rppawlo*
*Created by: rppawlo*
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1903Panzer: issues with pthread/multiple execution spaces2017-10-26T15:25:24ZJames WillenbringPanzer: issues with pthread/multiple execution spaces*Created by: rppawlo*
Reported in kokkos:
https://github.com/kokkos/kokkos/issues/1186*Created by: rppawlo*
Reported in kokkos:
https://github.com/kokkos/kokkos/issues/1186