Trilinos issueshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues2019-03-26T17:28:55Zhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/4726Teuchos::ScalarTraits has no specialization for Kokkos:complex<T>2019-03-26T17:28:55ZJames WillenbringTeuchos::ScalarTraits has no specialization for Kokkos:complex<T>*Created by: csiefer2*
We should probably fix this at some point.*Created by: csiefer2*
We should probably fix this at some point.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4623Teuchos: Can we just always build with Complex?2019-03-15T00:03:45ZJames WillenbringTeuchos: Can we just always build with Complex?*Created by: csiefer2*
Because if it doesn't work, your blas is broken...
Thoughts?*Created by: csiefer2*
Because if it doesn't work, your blas is broken...
Thoughts?https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4430Try 2: Remove deprecated inheritance of SerialDense matrices from Object2019-02-25T16:36:43ZJames WillenbringTry 2: Remove 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: ".
-->
This is a new issue fo...*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: ".
-->
This is a new issue for the idea captured in Issue #4258 but using an approach that doesn't break backward compatibility (cf Issue #4330) and attempts to align with current guidance for deprecating code as in Issue #4269).
<!---
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.
-->
## 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.
-->
Details are provided in Issue #4258.
## 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.
-->
## 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 Issues #4258 and #4330
* Part of
* Composed of Issue #4258
## 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?
-->
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/4183Need a shallow swap method for Teuchos Serial Dense Vector2019-01-14T20:40:54ZJames WillenbringNeed a shallow swap method for Teuchos Serial Dense Vector*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 h...*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 has need of a shallow swap method for performance related to Dakota multilevel algorithms. He also identified some additional performance gains by not tallying flop metrics when these are not used.
<!---
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.
-->
enhancement
## Expectations
<!---
Tell us what you think should happen, how you think things should work, what
you would like to see in the documentation, etc.
-->
I will submit a pull request for candidate changes to address this issue.
## 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.
-->
## 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.
-->
Done is when a shallow swap method is available in the master branch of trilinos.
## Possible Solution
<!---
Not obligatory, but suggest a fix for the bug or documentation, or suggest
ideas on how to implement the addition or change.
-->
A pull request is forthcoming.
## 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?
-->
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4142Teuchos::GlobalMPISession destructor finalizes Kokkos, but constructor does n...2019-01-11T00:16:06ZJames WillenbringTeuchos::GlobalMPISession destructor finalizes Kokkos, but constructor does not initialize Kokkos*Created by: mhoemmen*
@trilinos/teuchos
`Teuchos::GlobalMPISession`'s constructor does not call `Kokkos::initialize`, but GlobalMPISession's destructor calls `Kokkos::finalize_all`. Teuchos should either do both, or do neither.
...*Created by: mhoemmen*
@trilinos/teuchos
`Teuchos::GlobalMPISession`'s constructor does not call `Kokkos::initialize`, but GlobalMPISession's destructor calls `Kokkos::finalize_all`. Teuchos should either do both, or do neither.
https://github.com/trilinos/Trilinos/blob/5487fdcebedeb081477ec09dd3ad9efa9192948d/packages/teuchos/core/src/Teuchos_GlobalMPISession.cpp#L192https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3937Teuchos: Stacked timer should build by default, & be enable-able via run-time...2018-11-28T03:53:00ZJames WillenbringTeuchos: Stacked timer should build by default, & be enable-able via run-time option*Created by: mhoemmen*
@trilinos/teuchos @rppawlo @micahahoward
## Motivation and Context
- Stacked timer does not build by default.
- @jjellio found that it would be super useful for ATDM work.
- Combinatorial explosion...*Created by: mhoemmen*
@trilinos/teuchos @rppawlo @micahahoward
## Motivation and Context
- Stacked timer does not build by default.
- @jjellio found that it would be super useful for ATDM work.
- Combinatorial explosion of build options is bad. See e.g., [Jed Brown's essay](https://arxiv.org/pdf/1407.2905.pdf).
- Run-time option to enable this could still be off by default, for backwards compatibility. (Users may depend on timer output format.)
## Related Issues
* Related to #2727 https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3695Teuchos: Line Returns in Flow Mappings and Sequences2018-10-22T17:14:58ZJames WillenbringTeuchos: Line Returns in Flow Mappings and Sequences*Created by: danielsjensen1*
<!---
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: ".
-->
Many YAML inpu...*Created by: danielsjensen1*
<!---
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: ".
-->
Many YAML input files have long lists of variables such as the following
```
Nodal Quantities: >
Ex, Ey, Ez,
Bx, By, Bz,
ion_px, ion_py, ion_pz, ion_rho, ion_rho_E,
ion_ux, ion_uy, ion_uz, ion_n, ion_P,
```
Internally, we have been converting these strings to arrays but it would be fantastic if we could just use flow sequences with line returns as follows
```
Nodal Quantities: [
Ex, Ey, Ez,
Bx, By, Bz,
ion_px, ion_py, ion_pz, ion_rho, ion_rho_E,
ion_ux, ion_uy, ion_uz, ion_n, ion_P]
```
Flow sequences and flow maps currently work if they are on one line only such as `foo: [a b]` and `foo: {a: 1, b:2}` but they fail if there are any line returns as in the `Nodal Quantities` example above.
@trilinos/Teuchos
enhancement
<!---
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.
-->
## Expectations
<!---
Tell us what you think should happen, how you think things should work, what
you would like to see in the documentation, etc.
-->
The following input
```
FooPL:
sequence: [1, 2,
3]
map: {a: 1, b: 2,
c: 3}
```
should be equivalent to
```
FooPL:
sequence: [1, 2, 3]
map: {a: 1, b: 2, c: 3}
```
## Current Behavior
<!---
Tell us how the current behavior fails to meet your expectations in some way.
-->
The input above produces the following error message
```
Teuchos in Trilinos 12.13 (Dev)
terminate called after throwing an instance of 'Teuchos::ParserFail'
what(): error: Parser failure at line 3 column 14 of foo.yaml
3]
^
Expected one of {!, ", ', -, ., OTHERCHAR, WS, [, {}
Got: NEWLINE
Lexer text: "
"
Parser was in state 169
```
## 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.
-->
Users familiar with YAML files expect flow mappings and sequences to work properly even if there are line returns present. Input files become unnecessarily long either in width or height when line returns aren't allowed in flow mappings and sequences.
## 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 examples given above could be used in creating unit tests.
## 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?
-->
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3666Teuchos: strange warning under CUDA2018-10-19T17:24:24ZJames WillenbringTeuchos: strange warning under CUDA*Created by: jhux2*
Here is the warning:
```
246/442] Building CXX object packages/tpetra/core/src.../tpetra.dir/Tpetra_CrsMatrix_DOUBLE_INT_INT_CUDA.cpp.o
/home/jhu/software/trilinos/Trilinos/packages/teuchos/numerics/src/Teuchos_Se...*Created by: jhux2*
Here is the warning:
```
246/442] Building CXX object packages/tpetra/core/src.../tpetra.dir/Tpetra_CrsMatrix_DOUBLE_INT_INT_CUDA.cpp.o
/home/jhu/software/trilinos/Trilinos/packages/teuchos/numerics/src/Teuchos_SerialDenseMatrix.hpp: In instantiation of ‘Teuchos::SerialDenseMatrix<OrdinalType, ScalarType>& Teuchos::SerialDenseMatrix<OrdinalType, ScalarType>::operator=(const Teuchos::SerialDenseMatrix<OrdinalType, ScalarType>&) [with OrdinalType = int; ScalarType = double]’:
/home/jhu/software/trilinos/Trilinos/packages/teuchos/numerics/src/Teuchos_SerialDenseSolver.hpp:690:11: required from ‘int Teuchos::SerialDenseSolver<OrdinalType, ScalarType>::solve() [with OrdinalType = int; ScalarType = double]’
/home/jhu/software/trilinos/Trilinos/packages/muelu/src/Transfers/BlackBox/MueLu_BlackBoxPFactory_def.hpp:1637:1: required from ‘void MueLu::BlackBoxPFactory<Scalar, LocalOrdinal, GlobalOrdinal, Node>::ComputeLocalEntries(const Teuchos::RCP<const Xpetra::Matrix<Scalar, LocalOrdinal, GlobalOrdinal, Node> >&, Teuchos::Array<T>, Teuchos::Array<T>, LocalOrdinal, Teuchos::Array<T>, Teuchos::Array<T>, LocalOrdinal, Teuchos::Array<T>, Teuchos::Array<GlobalOrdinal>, Teuchos::Array<GlobalOrdinal>, Teuchos::Array<T>, Teuchos::Array<bool>, Teuchos::Array<int>, std::__cxx11::string, std::__cxx11::string, Teuchos::Array<T>, LocalOrdinal, Teuchos::Array<GlobalOrdinal>, Teuchos::SerialDenseMatrix<LocalOrdinal, Scalar>&, Teuchos::SerialDenseMatrix<LocalOrdinal, Scalar>&, Teuchos::SerialDenseMatrix<LocalOrdinal, Scalar>&, Teuchos::Array<T>&, Teuchos::Array<T>&) const [with Scalar = double; LocalOrdinal = int; GlobalOrdinal = int; Node = Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::Serial>; std::__cxx11::string = std::__cxx11::basic_string<char>]’
/home/jhu/software/trilinos/Trilinos/packages/muelu/src/Utils/MueLu_ETI_4arg.hpp:42:23: required from here
/home/jhu/software/trilinos/Trilinos/packages/teuchos/numerics/src/Teuchos_SerialDenseMatrix.hpp:659:14: warning: non-constant array new length must be specified without parentheses around the type-id [-Wvla]
values_ = new ScalarType[newsize];
~^~~~~~~~~~~~~~~~~~~~~~~~~~~
```
but as you can see, there are no parentheses.
@trilinos/teuchos https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3622Trilinos::Details::LinearSolver: Add ability to get final residual norm/vecto...2018-10-15T05:01:39ZJames WillenbringTrilinos::Details::LinearSolver: Add ability to get final residual norm/vector on request*Created by: mhoemmen*
@trilinos/teuchos @trilinos/tpetra @vbrunini
This makes sense if the solver already computes the final residual norm/vector, as it would avoid users needing to recompute it.*Created by: mhoemmen*
@trilinos/teuchos @trilinos/tpetra @vbrunini
This makes sense if the solver already computes the final residual norm/vector, as it would avoid users needing to recompute it.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3456PyTrilinos: Conflicting types in Teuchos_BLAS_wrapper.hpp2018-10-25T16:48:26ZJames WillenbringPyTrilinos: Conflicting types in Teuchos_BLAS_wrapper.hpp*Created by: wfspotz*
@trilinos/pytrilinos
@trilinos/teuchos
@trilinos/kokkos-kernels
## Expectations
I expect to build PyTrilinos without compilation errors
## Current Behavior
I have a wrapper file that `#include`s the he...*Created by: wfspotz*
@trilinos/pytrilinos
@trilinos/teuchos
@trilinos/kokkos-kernels
## Expectations
I expect to build PyTrilinos without compilation errors
## Current Behavior
I have a wrapper file that `#include`s the header `MLAPI_MultiVector.h` which gives the compilation error
/Development/Trilinos/packages/teuchos/numerics/src/Teuchos_BLAS_wrappers.hpp:173:13: error: conflicting types for 'daxpy_'
void PREFIX DAXPY_F77(const int* n, const double* alpha, const double x[], const int* incx, double y[], const int* incy);
^
/Development/Trilinos/packages/teuchos/numerics/src/Teuchos_BLAS_wrappers.hpp:78:21: note: expanded from macro 'DAXPY_F77'
#define DAXPY_F77 F77_BLAS_MANGLE(daxpy,DAXPY)
^
/Development/Trilinos/MPI/packages/teuchos/core/src/Teuchos_config.h:10:37: note: expanded from macro 'F77_BLAS_MANGLE'
#define F77_BLAS_MANGLE(name,NAME) name ## _
^
<scratch space>:23:1: note: expanded from here
daxpy_
^
/Development/Trilinos/packages/kokkos-kernels/src/impl/tpls/KokkosBlas1_axpby_tpl_spec_decl.hpp:49:17: note: previous declaration is here
extern "C" void daxpy_( const int* N, const double* alpha,
## Definition of Done
I can get the PyTrilinos package to build and all of the PyTrilinos tests to pass.
## Possible Solution
I'm not sure why this conflicting type declaration is occurring, but it is clearly related to macro expansion. Based on `git blame` of `Teuchos_BLAS_wrapper.h` I'm hoping either @jwillenbring or @hkthorn might have some idea what the problem could be. PyTrilinos can present some unique configuration issues.
## Steps to Reproduce
If it gets to this, I can help someone set up their environment to build PyTrilinos.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3130Teuchos: Dynamic Cast Errors from XML-read Array<string>2018-07-17T23:27:59ZJames WillenbringTeuchos: Dynamic Cast Errors from XML-read Array<string>*Created by: csiefer2*
A Trilinos test. I have an XML file with lines like this:
```
<Parameter name="avatar: decision tree files" type="Array(string)" value="{'avatar.trees'}"/>
```
I rely on the Teuchos XML reader to read that....*Created by: csiefer2*
A Trilinos test. I have an XML file with lines like this:
```
<Parameter name="avatar: decision tree files" type="Array(string)" value="{'avatar.trees'}"/>
```
I rely on the Teuchos XML reader to read that.
I do this:
```c++
const Teuchos::Array<std::string> & tf = params_.get<const Teuchos::Array<std::string> >(paramName);
```
I get this error:
> p=0: *** Caught standard std::exception of type 'std::logic_error' :
>
> /ascldap/users/csiefer/Trilinos/sandbox5/Trilinos/packages/teuchos/core/src/
> Teuchos_any.hpp:361:
>
> Throw number = 1
>
> Throw test that evaluated to true: !dyn_cast_content
>
> any_cast<Teuchos::Array<std::string>>(operand): Error, cast to type
> any::holder<Teuchos::Array<std::string>> failed but should not have and
> the actual underlying type is
> 'Teuchos::any::holder<Teuchos::Array<std::string> >! The problem might
> be related to incompatible RTTI systems in static and shared libraries!
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2893Teuchos::Time::wallTime() might not return a wall time but a CPU time2018-06-06T15:00:38ZJames WillenbringTeuchos::Time::wallTime() might not return a wall time but a CPU time*Created by: finkandreas*
Teuchos:e:Time::wallTime() could not return actually a wall time, but the cpu time. Looking into the implementation, I've seen this piece of code:
```
#ifdef HAVE_MPI
int mpiInitialized;
MPI...*Created by: finkandreas*
Teuchos:e:Time::wallTime() could not return actually a wall time, but the cpu time. Looking into the implementation, I've seen this piece of code:
```
#ifdef HAVE_MPI
int mpiInitialized;
MPI_Initialized(&mpiInitialized);
if( mpiInitialized ) {
return(MPI_Wtime());
}
else {
clock_t start;
start = clock();
return( (double)( start ) / CLOCKS_PER_SEC );
}
```
I realized it, when I did not initialize MPI, so I'll end up with the `clock()` call.
On Linux the value returned is the CPU time, NOT a wallclock time, i.e. in an OpenMP programm this will give wrong results.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2880Multiple definition of HAVE_MPI in configure files.2018-06-04T21:52:36ZJames WillenbringMultiple definition of HAVE_MPI in configure files.*Created by: kyungjoo-kim*
<!---
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: ".
-->
I am wondering...*Created by: kyungjoo-kim*
<!---
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: ".
-->
I am wondering why we have multiple definition of HAVE_MPI ? For example with TPL_ENABLE_MPI=ON, I can find out following multiple definitions from my build directory.
```
[kyukim @bread] packages > grep -r "HAVE_MPI" *
belos/src/Belos_config.h:#define HAVE_MPI
sacado/src/Sacado_config.h:#define HAVE_MPI
stokhos/src/Stokhos_config.h:#define HAVE_MPI
teuchos/core/src/Teuchos_config.h:#define HAVE_MPI
```
Do we do this because it does not cause a problem so far ? Any potential issue with this ? Also this macro is not guarded by package name.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2774Teuchos: Unit test system does not initialize Kokkos, if Kokkos is enabled2018-05-17T19:05:58ZJames WillenbringTeuchos: Unit test system does not initialize Kokkos, if Kokkos is enabled*Created by: csiefer2*
This has the side effect of making it impossible to use the Kokkos profiling tools on any of the unit tests.
This is the case because the unit test uses a Teuchos Timer, which tries to use a profiling region of...*Created by: csiefer2*
This has the side effect of making it impossible to use the Kokkos profiling tools on any of the unit tests.
This is the case because the unit test uses a Teuchos Timer, which tries to use a profiling region of an uninitialized Kokkos. Segfaults ensue.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2524 TEUCHOS_UNREACHABLE_RETURN(Teuchos::null) still throws a warning in cuda.2018-11-30T11:16:52ZJames Willenbring TEUCHOS_UNREACHABLE_RETURN(Teuchos::null) still throws a warning in cuda.*Created by: bathmatt*
Even with this call at the end of a function I get warnings in cuda. Not sure on the magic that is needed but ...
```
/home/mbetten/Trilinos/EMPIRE/src/PIC/InjectionBCs.hpp(289): warning: missing return state...*Created by: bathmatt*
Even with this call at the end of a function I get warnings in cuda. Not sure on the magic that is needed but ...
```
/home/mbetten/Trilinos/EMPIRE/src/PIC/InjectionBCs.hpp(289): warning: missing return statement at end of non-void function "empire::pic::createInjectionBC(const empire::pic::ElementalParticleData<MESH_TRAITS> &, const Teuchos::RCP<panzer::UniqueGlobalIndexerBase> &, const panzer_stk::STK_Interface &, const std::__cxx11::string &, const Teuchos::ParameterList &) [with MESH_TRAITS=empire::TetSecondOrder]"
```
but this is the end of that function
```
TEUCHOS_UNREACHABLE_RETURN(Teuchos::null);
}
```https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2410Test TeuchosNumerics_LAPACK_test_MPI_1 fails in all 'debug' builds on power8 ...2018-12-19T14:42:14ZJames WillenbringTest TeuchosNumerics_LAPACK_test_MPI_1 fails in all 'debug' builds on power8 'ride'*Created by: bartlettroscoe*
**CC:** @trilinos/teuchos
## Next Action Status:
PR #2447 was merged on 3/23/2018 which disabled the test. PR #4064 which enables the whole test `TeuchosNumerics_LAPACK_test_MPI_1` but disables the ...*Created by: bartlettroscoe*
**CC:** @trilinos/teuchos
## Next Action Status:
PR #2447 was merged on 3/23/2018 which disabled the test. PR #4064 which enables the whole test `TeuchosNumerics_LAPACK_test_MPI_1` but disables the single unit test for `STEQR()` merged to 'develop' on 12/18/2018. Next: Watch for test running and passing (minus `STEQR()` unit test) on 'release-debug' and 'opt' builds on 'white', 'ride', and 'waterman' on 12/19/2018 ...
## Description
The test `TeuchosNumerics_LAPACK_test_MPI_1` segfaults on the 'debug' builds `Trilinos-atdm-white-ride-cuda-debug` and `Trilinos-atdm-white-ride-gnu-debug-openmp` on 'ride' and 'white' but passes in all of the 'opt' builds on these same machines as well as for all of the builds on `hansen` as shown this morning in:
* https://testing-vm.sandia.gov/cdash/queryTests.php?project=Trilinos&date=2018-03-17&filtercombine=and&filtercombine=and&filtercount=2&showfilters=1&filtercombine=and&field1=buildname&compare1=65&value1=Trilinos-atdm-&field2=testname&compare2=61&value2=TeuchosNumerics_LAPACK_test_MPI_1
The failing tests all show segfaults showing the output:
```
Teuchos in Trilinos 12.13 (Dev)
GESV test ... passed!
LAPY2 test ... passed!
--------------------------------------------------------------------------
mpiexec noticed that process rank 0 with PID 16320 on node white24 exited on signal 11 (Segmentation fault).
--------------------------------------------------------------------------
```
What is interesting is that this test only failed in all of the Trilinos builds that were done yesterday in the query:
* https://testing-vm.sandia.gov/cdash/queryTests.php?project=Trilinos&date=2018-03-16&filtercombine=and&filtercount=3&showfilters=1&filtercombine=and&field1=buildname&compare1=65&value1=Trilinos-atdm-&field2=testname&compare2=61&value2=TeuchosNumerics_LAPACK_test_MPI_1&field3=status&compare3=62&value3=passed
May this be the same error reported in #1208 that we basically gave up on?
## Steps to Reproduce
Following the instructions at:
* https://github.com/trilinos/Trilinos/blob/develop/cmake/std/atdm/README.md#ridewhite
one can reproduce this failing test by enabling the Teuchos package for the builds `gnu-debug-openmp` or `cuda-debug` and running the failing test.
## Related issues
* Related to: #1208?
Initial cleanup of new ATDM builds of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/2371Teuchos: YAML parser: Non-ascii characters in comments cause parser to fail2018-03-13T16:22:28ZJames WillenbringTeuchos: YAML parser: Non-ascii characters in comments cause parser to fail*Created by: bathmatt*
This is a cut-n-paste issue from my code, but it is trilinos.
[file.txt](https://github.com/trilinos/Trilinos/files/1804790/file.txt)
When a non-ascii character is in a comment, the parser fails and the simu...*Created by: bathmatt*
This is a cut-n-paste issue from my code, but it is trilinos.
[file.txt](https://github.com/trilinos/Trilinos/files/1804790/file.txt)
When a non-ascii character is in a comment, the parser fails and the simulation doesn't run.
Possible Solution
Steps to Reproduce
Download this file that has four different unrecognized characters right at the top in their own comment sections: SingleParticle.yaml
Run it.
Shake fist angrily at computer.
Context
I was creating a test and put the experimental value in a comment with the unicode plus-or-minus sign along with the error.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2111Allow ParameterList to be case insensitive2018-01-04T00:03:17ZJames WillenbringAllow ParameterList to be case insensitive*Created by: bartgol*
<!--- Provide a general summary of the issue in the Title above. -->
<!---
Note that anything between these delimiters is a comment that will not appear
in the issue description once created. Click on the Pre...*Created by: bartgol*
<!--- Provide a general summary of the issue in the Title above. -->
<!---
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.
-->
## Expectations
<!---
Tell us what you think should happen, how you think things should work, what
you would like to see in the documentation, etc.
-->
I was wondering if there is a reason why ParameterList does not support case-insensitive strings (upon request, of course). I sometimes spend some time debugging a crash, and realize I used a lowercase letter instead of an uppercase (or viceversa) in the name of a parameter/sublist in the xml file. If ParameterList was somehow able to ignore the case of the parameters/sublists names, then this would not be a problem.
Note: I'm not talking about the (string-type) parameters values (although, at this point, the class could ignore that too), since those I can always convert to lower/upper case after fetching them from the list. I'm only talking about the parameter name, since I don't want/can't try all the possible typos when I look for a parameter.
## Possible Solution
I guess one could set a bool flag at construction time, or even set it afterwards via a setter (in which case, the parameter list is immediately looped through and all the parameters/sublists names are converted to a predefined lower/upper case). Then, in all the getters/setters, before looking for the parameter/sublist, if the bool flag is on, the input string is first converted to a predefined lower/upper case.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1910Teuchos_StandardParameterEntryValidators throw on normal execution2017-10-27T04:16:47ZJames WillenbringTeuchos_StandardParameterEntryValidators throw on normal execution*Created by: jclause*
Standard probing of parameterLists results in a lot of code that throws during the course of normal execution, e.g., testing whether a parameter was specified and then catching to prescribe a default.
See Ifpac...*Created by: jclause*
Standard probing of parameterLists results in a lot of code that throws during the course of normal execution, e.g., testing whether a parameter was specified and then catching to prescribe a default.
See Ifpack2_AdditiveSchwarz_def.hpp:903 for an example
This is a bad practice that results in a library that is difficult to use and debug within an application. Do not throw unless it is an exceptional event.