Trilinos issueshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues2019-03-15T03:39:45Zhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/4468Epetra: Remove build warnings2019-03-15T03:39:45ZJames WillenbringEpetra: Remove build warnings*Created by: ZUUL42*
<!---
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: ".
-->
<!---
Replace <team...*Created by: ZUUL42*
<!---
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: ".
-->
<!---
Replace <teamName> below with the appropriate Trilinos package/team name.
-->
@trilinos/epetra
<!---
Assignees: If you know anyone who should likely tackle this issue, select them
from the Assignees drop-down on the right.
-->
<!---
Labels: 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.
-->
Epetra builds should not emit any warnings that will be promoted to errors once Werror is set in the GCC 7.2.0 automated build.
## Current Behavior
<!---
Tell us how the current behavior fails to meet your expectations in some way.
-->
Currently Epetra has a number of warnings that need to be handled before we can set Werror for all packages.
A recent test build was performed with -Werror set for Epetra. The CDash report can be found [here](https://testing-vm.sandia.gov/cdash/viewBuildError.php?buildid=4584123).
## Motivation, Context and Related Issues
<!---
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.
-->
Issue #3178 is working toward turning Warnings as Errors on for all packages.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4464MueLu: add unit tests for class Zoltan2Interface2019-02-21T21:29:02ZJames WillenbringMueLu: add unit tests for class Zoltan2Interface*Created by: jhux2*
While looking at another issue, I discovered there are no MueLu unit tests for the Zoltan2Interface class. This should be fixed.
@trilinos/muelu *Created by: jhux2*
While looking at another issue, I discovered there are no MueLu unit tests for the Zoltan2Interface class. This should be fixed.
@trilinos/muelu https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4461Framework: Autotester Occasionally Refuses to Do Inspection2019-03-08T17:10:35ZJames WillenbringFramework: Autotester Occasionally Refuses to Do Inspection*Created by: csiefer2*
Which means you can't merge a tested, approved PR.
This can be 'fixed' by throwing on 'AT: RETEST' and burning another 4 hours of testing time (if the test machines all work), but this is getting annoying.
@...*Created by: csiefer2*
Which means you can't merge a tested, approved PR.
This can be 'fixed' by throwing on 'AT: RETEST' and burning another 4 hours of testing time (if the test machines all work), but this is getting annoying.
@trilinos/framework @william76 @jwillenbring 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/4422Tpetra: CrsMatrix & CrsGraph swap() test updates2019-02-18T19:53:05ZJames WillenbringTpetra: CrsMatrix & CrsGraph swap() test updates*Created by: william76*
@trilinos/tpetra
The tests for `CrsMatrix::Swap()` and `CrsGraph::Swap()` are set up to run on MPI using 2 processors.
@wcmclen will expand them to work with 1..N processors
*Created by: william76*
@trilinos/tpetra
The tests for `CrsMatrix::Swap()` and `CrsGraph::Swap()` are set up to run on MPI using 2 processors.
@wcmclen will expand them to work with 1..N processors
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4421Framework: new version of gtest with gmock and gtest_main2019-02-18T19:00:39ZJames WillenbringFramework: new version of gtest with gmock and gtest_main*Created by: rppawlo*
@trilinos/framework - is there any chance someone could upgrade the gtest version in Trilinos to the most recent release and make sure to include gmock and gtest_main? Since gtest is installed as part of Trilinos, ...*Created by: rppawlo*
@trilinos/framework - is there any chance someone could upgrade the gtest version in Trilinos to the most recent release and make sure to include gmock and gtest_main? Since gtest is installed as part of Trilinos, some external apps are interested in leveraging this.
@jwillenbring @bathmatt https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4416cannot convert 'Intrepid2::Basis<Kokkos::Serial, double, double>*' to 'Intrep...2019-02-18T13:38:19ZJames Willenbringcannot convert 'Intrepid2::Basis<Kokkos::Serial, double, double>*' to 'Intrepid2::Basis<Kokkos::OpenMP, double, double>*'*Created by: anhvt2*
<!---
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: ".
-->
Hi, this is not a Tril...*Created by: anhvt2*
<!---
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: ".
-->
Hi, this is not a Trilinos issue per se, but it is very related to Trilinos and I hope you can point me in the right direction. The Trilinos compilation went fine, but I'm encountering a compiling error from another package.
<!---
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.
-->
```
/Users/anhtran/Documents/trilinos/MILO/src/interfaces/physicsInterface.cpp: In member function 'void physics::setPeriBCs(Teuchos::RCP<Teuchos::ParameterList>&, Teuchos::RCP<panzer_stk::STK_Interface>&)':
/Users/anhtran/Documents/trilinos/MILO/src/interfaces/physicsInterface.cpp:1351:18: warning: comparison of integer expressions of different signedness: 'int' and 'std::vector<std::__cxx11::basic_string<char> >::size_type' {aka 'long unsigned int'} [-Wsign-compare]
for (int i=0; i<periSides.size(); i++){ //check that periodic sides have been correctly named
~^~~~~~~~~~~~~~~~~
In file included from /usr/local/trilinos/include/Teuchos_ArrayRCPDecl.hpp:47,
from /usr/local/trilinos/include/Teuchos_ArrayRCP.hpp:46,
from /usr/local/trilinos/include/Teuchos_ArrayView.hpp:47,
from /usr/local/trilinos/include/Teuchos_GlobalMPISession.hpp:52,
from /Users/anhtran/Documents/trilinos/MILO/src/./trilinos.hpp:23,
from /Users/anhtran/Documents/trilinos/MILO/src/physics/physics_base.hpp:15,
from /Users/anhtran/Documents/trilinos/MILO/src/interfaces/physicsInterface.hpp:15,
from /Users/anhtran/Documents/trilinos/MILO/src/interfaces/physicsInterface.cpp:12:
/usr/local/trilinos/include/Teuchos_RCP.hpp: In instantiation of 'Teuchos::RCP<T>::RCP(const Teuchos::RCP<T2>&) [with T2 = Intrepid2::Basis<Kokkos::Serial, double, double>; T = Intrepid2::Basis<Kokkos::OpenMP, double, double>]':
/Users/anhtran/Documents/trilinos/MILO/src/interfaces/physicsInterface.cpp:559:77: required from here
/usr/local/trilinos/include/Teuchos_RCP.hpp:289:38: error: cannot convert 'Intrepid2::Basis<Kokkos::Serial, double, double>*' to 'Intrepid2::Basis<Kokkos::OpenMP, double, double>*' in initialization
node_(r_ptr.access_private_node())
```
is there any way to bypass this Kokkos error?
<!---
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/kokkos
<!---
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.
-->
## 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:** 5dbd77aee8 4f90e42a6b
- **Relevant configure flags or configure script:**
```
cd $TRIL_BUILD
rm -r CMakeCache.txt
# rm -rfv *
### 5Feb19
cmake -D CMAKE_INSTALL_PREFIX:PATH="/usr/local/trilinos" \
-D MPI_BASE_DIR:PATH="/usr/local/" \
-D CMAKE_CXX_FLAGS:STRING="-O2 -std=c++11 -pedantic -ftrapv -Wall -Wno-long-long" \
-D CMAKE_Fortran_FLAGS:STRING="-O3 -lgfortran" \
-D CMAKE_BUILD_TYPE:STRING=RELEASE \
-D CMAKE_VERBOSE_MAKEFILE:BOOL=ON \
-D Trilinos_ENABLE_Fortran:BOOL=ON \
-D Trilinos_EXTRA_LINK_FLAGS:STRING="-ldl" \
-D Trilinos_ENABLE_SECONDARY_TESTED_CODE:BOOL=OFF \
-D Trilinos_INSTALL_LIBRARIES_AND_HEADERS=ON \
-D Trilinos_WARNINGS_AS_ERRORS_FLAGS:STRING="" \
-D Trilinos_ENABLE_CHECKED_STL:BOOL=OFF \
-D Trilinos_ENABLE_EXPLICIT_INSTANTIATION:BOOL=ON \
-D Trilinos_ENABLE_INSTALL_CMAKE_CONFIG_FILES:BOOL=ON \
-D Trilinos_SKIP_FORTRANCINTERFACE_VERIFY_TEST:BOOL=ON \
-D Trilinos_ENABLE_EXAMPLES:BOOL=OFF \
-D Trilinos_ENABLE_TESTS:BOOL=OFF \
-D Trilinos_ENABLE_ALL_PACKAGES:BOOL=OFF \
-D Trilinos_ENABLE_ALL_OPTIONAL_PACKAGES:BOOL=OFF \
-D Trilinos_ENABLE_ALL_PACKAGES:BOOL=OFF \
-D Trilinos_ENABLE_SCOREC:BOOL=ON \
-D PCU_COMPRESS:BOOL=ON \
-D SCOREC_DISABLE_STRONG_WARNINGS:BOOL=ON \
-D Trilinos_ENABLE_EXPORT_MAKEFILES:BOOL=OFF \
-D Trilinos_ASSERT_MISSING_PACKAGES:BOOL=OFF \
-D Trilinos_ENABLE_EXPORT_MAKEFILES:BOOL=OFF \
-D Trilinos_ASSERT_MISSING_PACKAGES:BOOL=OFF \
-D Trilinos_ENABLE_Teuchos:BOOL=ON \
-D Trilinos_ENABLE_TeuchosCore:BOOL=ON \
-D Trilinos_ENABLE_TeuchosParameterList=ON \
-D Trilinos_ENABLE_TeuchosComm=ON \
-D Trilinos_ENABLE_TeuchosNumerics=ON \
-D Trilinos_ENABLE_TeuchosParser=ON \
-D Trilinos_ENABLE_TeuchosRemainder=ON \
-D Teuchos_ENABLE_THREAD_SAFE=ON \
-D Teuchos_ENABLE_yaml-cpp:BOOL=ON \
-D Trilinos_ENABLE_Shards:BOOL=ON \
-D Trilinos_ENABLE_Sacado:BOOL=ON \
-D Trilinos_ENABLE_Tpetra:BOOL=ON \
-D Trilinos_ENABLE_Kokkos:BOOL=ON \
-D HAVE_INTREPID_KOKKOSCORE:BOOL=ON \
-D Trilinos_ENABLE_Epetra:BOOL=ON \
-D Trilinos_ENABLE_EpetraExt:BOOL=ON \
-D Trilinos_ENABLE_Ifpack:BOOL=ON \
-D Trilinos_ENABLE_AztecOO:BOOL=ON \
-D Trilinos_ENABLE_Amesos:BOOL=ON \
-D Trilinos_ENABLE_Anasazi:BOOL=ON \
-D Trilinos_ENABLE_Belos:BOOL=ON \
-D Trilinos_ENABLE_ML:BOOL=ON \
-D Trilinos_ENABLE_Phalanx:BOOL=ON \
-D Trilinos_ENABLE_Intrepid:BOOL=ON \
-D Trilinos_ENABLE_Intrepid2:BOOL=ON \
-D Trilinos_ENABLE_NOX:BOOL=ON \
-D Trilinos_ENABLE_Stratimikos:BOOL=ON \
-D Trilinos_ENABLE_Thyra:BOOL=ON \
-D Trilinos_ENABLE_Rythmos:BOOL=ON \
-D Trilinos_ENABLE_MOOCHO:BOOL=ON \
-D Trilinos_ENABLE_TriKota:BOOL=ON \
-D Trilinos_ENABLE_Stokhos:BOOL=ON \
-D Trilinos_ENABLE_Zoltan:BOOL=ON \
-D Trilinos_ENABLE_Piro:BOOL=ON \
-D Trilinos_ENABLE_Teko:BOOL=ON \
-D Trilinos_ENABLE_SEACAS:BOOL=ON \
-D Trilinos_ENABLE_SEACASIoss:BOOL=ON \
-D Trilinos_ENABLE_SEACASBlot:BOOL=ON \
-D Trilinos_ENABLE_SEACASPLT:BOOL=ON \
-D Trilinos_ENABLE_SEACASExo2mat=OFF \
-D Trilinos_ENABLE_SEACASExo2mat:BOOL=OFF \
-D Trilinos_ENABLE_SEACASExodus:BOOL=ON \
-D Trilinos_ENABLE_SEACASSVDI:BOOL=ON \
-D Trilinos_ENABLE_Pamgen:BOOL=ON \
-D Trilinos_ENABLE_EXAMPLES:BOOL=OFF \
-D Trilinos_ENABLE_TESTS:BOOL=ON \
-D Trilinos_ENABLE_Teko:BOOL=ON \
-D Trilinos_ENABLE_Belos:BOOL=ON \
-D Trilinos_ENABLE_ROL:BOOL=ON \
-D Trilinos_ENABLE_AztecOO:BOOL=ON \
-D Trilinos_ENABLE_Ifpack2:BOOL=ON \
-D Trilinos_ENABLE_Panzer:BOOL=ON \
-D Trilinos_ENABLE_Intrepid:BOOL=ON \
-D Trilinos_ENABLE_Intrepid2:BOOL=ON \
-D Trilinos_ENABLE_Shards:BOOL=ON \
-D Trilinos_ENABLE_Stratimikos:BOOL=ON \
-D Trilinos_ENABLE_ML:BOOL=ON \
-D Trilinos_ENABLE_Zoltan:BOOL=ON \
-D Trilinos_ENABLE_FEI:BOOL=ON \
-D Trilinos_ENABLE_Amesos:BOOL=ON \
-D Trilinos_ENABLE_Amesos2:BOOL=ON \
-D Amesos2_ENABLE_KLU2:BOOL=ON \
-D Trilinos_ENABLE_STKClassic:BOOL=OFF \
-D Trilinos_ENABLE_STKIO:BOOL=ON \
-D Trilinos_ENABLE_STKMesh:BOOL=ON \
-D Trilinos_ENABLE_STKUtil:BOOL=ON \
-D Trilinos_ENABLE_STKSearch:BOOL=ON \
-D Trilinos_ENABLE_STKTopology:BOOL=ON \
-D Trilinos_ENABLE_STKTransfer:BOOL=ON \
-D Trilinos_ENABLE_Belos:BOOL=ON \
-D Trilinos_ENABLE_MueLu:BOOL=ON \
-D Trilinos_ENABLE_OpenMP=ON \
-D TPL_ENABLE_Netcdf:BOOL=ON \
-D TPL_ENABLE_HDF5:BOOL=ON \
-D TPL_ENABLE_Matio=ON \
-D EpetraExt_ENABLE_HDF5:BOOL=OFF \
-D Matio_INCLUDE_DIRS="/usr/local/matio/include" \
-D Matio_LIBRARY_DIRS="/usr/local/matio/lib" \
-D Panzer_ENABLE_TESTS:BOOL=OFF \
-D Panzer_ENABLE_EXAMPLES:BOOL=OFF \
-D Panzer_ENABLE_EXPLICIT_INSTANTIATION:BOOL=ON \
-D STK_ENABLE_TESTS:BOOL=OFF \
-D Zoltan_INCLUDE_DIRS="/usr/local/zoltan/include" \
-D Zoltan_LIBRARY_DIRS="/usr/local/zoltan/lib" \
-D TPL_ENABLE_Boost:BOOL=ON \
-D TPL_ENABLE_BLAS:BOOL=ON \
-D TPL_ENABLE_GLM=OFF \
-D TPL_ENABLE_LAPACK:BOOL=ON \
-D TPL_ENABLE_MPI:BOOL=ON \
-D TPL_ENABLE_X11=ON \
-D HDF5_INCLUDE_DIRS:PATH="/usr/local/hdf5/include" \
-D HDF5_LIBRARY_DIRS:PATH="/usr/local/hdf5/lib" \
-D Netcdf_INCLUDE_DIRS:PATH="/usr/local/netcdf/include" \
-D Netcdf_LIBRARY_DIRS:PATH="/usr/local/netcdf/lib" \
-D Boost_INCLUDE_DIRS:PATH="/usr/local/boost/include" \
-D Boost_LIBRARY_DIRS:PATH="/usr/local/boost/lib" \
-D TPL_ENABLE_ParMETIS:STRING=ON \
-D ParMETIS_INCLUDE_DIRS:PATH="/usr/local/parmetis/include" \
-D ParMETIS_LIBRARY_DIRS:PATH="/usr/local/parmetis/lib" \
-D HAVE_PARMETIS_VERSION_4_0_3=ON \
-D TPL_ENABLE_METIS:STRING=ON \
-D METIS_INCLUDE_DIRS:PATH="/usr/local/metis/include" \
-D METIS_LIBRARY_DIRS:PATH="/usr/local/metis/lib" \
-D Trilinos_ENABLE_EXPLICIT_INSTANTIATION:BOOL=ON \
-D Tpetra_INST_FLOAT=OFF \
-D Tpetra_INST_INT_INT=ON \
-D Tpetra_INST_DOUBLE=ON \
-D Tpetra_INST_COMPLEX_FLOAT=OFF \
-D Tpetra_INST_COMPLEX_DOUBLE=OFF \
-D Tpetra_INST_INT_LONG=OFF \
-D Tpetra_INST_INT_UNSIGNED=OFF \
-D Tpetra_INST_INT_LONG_LONG=ON \
-D Zoltan_ENABLE_ULLONG_IDS:BOOL=ON \
-D Teuchos_ENABLE_LONG_LONG_INT:BOOL=ON \
-D KOKKOS_DEVICES="OpenMP" \
-D CMAKE_VERBOSE_MAKEFILE:BOOL=OFF \
-D Trilinos_VERBOSE_CONFIGURE:BOOL=OFF \
${TRIL_SRC}
```
- **Operating system and version:** macOS High Sierra version 10.13.6
- **Compiler and TPL versions:** gcc-8.2.0
## 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/4404Switch to C bindings of BLAS & LAPACK?2019-02-15T22:57:28ZJames WillenbringSwitch to C bindings of BLAS & LAPACK?*Created by: mhoemmen*
@trilinos/framework
@mwglass pointed out that:
- Trilinos, kokkos-kernels, Sierra, ATDM, etc. all spent a lot of effort deducing and maintaining Fortran mangling of BLAS and LAPACK, yet
- the BLAS (and...*Created by: mhoemmen*
@trilinos/framework
@mwglass pointed out that:
- Trilinos, kokkos-kernels, Sierra, ATDM, etc. all spent a lot of effort deducing and maintaining Fortran mangling of BLAS and LAPACK, yet
- the BLAS (and even LAPACK)[
http://netlib.org/lapack/#_standard_c_language_apis_for_lapack] come with standard C bindings.
Why don't we all switch to the C bindings? That would get rid of all that mangling deduction code.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4391Xpetra: need a RowMatrixTransposer2019-02-13T17:28:38ZJames WillenbringXpetra: need a RowMatrixTransposer*Created by: mayrmt*
@trilinos/xpetra
@lucbv
## Expectations
Implement an `Xpetra::RowMatrixTransposer` that explicitly forms the transpose of a given `Xpetra::RowMatrix`.
## Current Behavior
`EpetraExt::RowMatrixTransposer` ...*Created by: mayrmt*
@trilinos/xpetra
@lucbv
## Expectations
Implement an `Xpetra::RowMatrixTransposer` that explicitly forms the transpose of a given `Xpetra::RowMatrix`.
## Current Behavior
`EpetraExt::RowMatrixTransposer` and `Tpetra::RowMatrixTransposer` are implemented and tested, but are not accessible through `Xpetra`.
## Motivation and Context
Forming the transpose of a matrix explicitly sometimes is useful.
This is required for #4084.
## Definition of Done
- [ ] Implement Xpetra interface to access Epetra/Tpetra version of a RowMatrixTransposer.
- [ ] Add unit test.
## Possible Solution
`EpetraExt::RowMatrixTransposer` and `Tpetra::RowMatrixTransposer` already exist and are tested. We could just add an `Xpetra::RowMatrixTransposer` and derived classes `Xpetra::EpetraRowMatrixTransposer` and `Xpetra::TpetraRowMatrixTransposer` that internally call the respective EpetraExt/Tpetra functionality.
## Related Issues
* Blocks #4084https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4385Tpetra::BlockCrsMatrix: Deprecate "experimental" headers & namespace2019-02-12T22:35:30ZJames WillenbringTpetra::BlockCrsMatrix: Deprecate "experimental" headers & namespace*Created by: mhoemmen*
@trilinos/tpetra @kddevin (as discussed in the weekly Tpetra meeting today)
`Tpetra::BlockCrsMatrix` is implemented in the `Tpetra_Experimental_BlockCrsMatrix*.hpp` headers and the `Tpetra::Experimental` namesp...*Created by: mhoemmen*
@trilinos/tpetra @kddevin (as discussed in the weekly Tpetra meeting today)
`Tpetra::BlockCrsMatrix` is implemented in the `Tpetra_Experimental_BlockCrsMatrix*.hpp` headers and the `Tpetra::Experimental` namespace. However, at least one production code uses BlockCrsMatrix. This means that we should not call it "experimental" any more. We should deprecate the "experimental" headers and namespace, and put this class into the `Tpetra` namespace. (In fact, it's already there; see below.)
"De-experimental-ing" BlockCrsMatrix could happen in N steps:
1. The `Tpetra_BlockCrsMatrix*.hpp` headers already exist, and they import BlockCrsMatrix into the `Tpetra` namespace. Production codes should just include those header files for now.
2. Tpetra could then put the implementation of BlockCrsMatrix in the existing `Tpetra_BlockCrsMatrix*.hpp` headers, make sure that Tpetra's CMake logic auto-generates `Tpetra_BlockCrsMatrix.cpp` (instead of `Tpetra_Experimental_BlockCrsMatrix.cpp`). Each `Tpetra_Experimental_BlockCrsMatrix*.hpp` header would then just include the corresponding `Tpetra_BlockCrsMatrix*.hpp` header, and import the class into the `Tpetra::Experimental` namespace.
3. It's possible to deprecate header files, so we can then mark the `Tpetra_Experimental_BlockCrsMatrix*.hpp` headers as deprecated.
@kyungjoo-kim brings up a good concern, that perhaps we should evaluate BlockCrsMatrix's performance and fix any major issues we find, before "releasing" it into the Tpetra namespace. While the `Tpetra_BlockCrsMatrix*.hpp` headers do already import it into the Tpetra namespace, the above actions would constitute a more formal release. The application that uses BlockCrsMatrix depends mainly on a specialized solver for performance, not on sparse matrix-vector multiply (`BlockCrsMatrix::apply`).https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4381Tpetra: Changes to Import broke MMM_Timings2019-02-13T18:15:02ZJames WillenbringTpetra: Changes to Import broke MMM_Timings*Created by: csiefer2*
Both the changes and the MMM_Timings use "prefix" to mean different data types.
*Created by: csiefer2*
Both the changes and the MMM_Timings use "prefix" to mean different data types.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4379Kokkos: Intel not supported with CUDA?2019-02-13T17:14:52ZJames WillenbringKokkos: Intel not supported with CUDA?*Created by: amklinv*
@trilinos/kokkos @mhoemmen
## Expectations
Trilinos builds with CUDA support using Intel for the host compiler. Alternatively, document that this is not supported.
## Current Behavior
When I try to buil...*Created by: amklinv*
@trilinos/kokkos @mhoemmen
## Expectations
Trilinos builds with CUDA support using Intel for the host compiler. Alternatively, document that this is not supported.
## Current Behavior
When I try to build Trilinos with CUDA support using the nvcc_wrapper and Intel as the host compiler, I get an error message during the build
> nvcc fatal : Option --expt-extended-lambda (-expt-extended-lambda) is unsupported with the icc compiler
## Your Environment
- CUDA 9.1
- Intel 16.0.4
- CentOS 7
Relevant CMake flags
- CMAKE_CXX_FLAGS='--expt-extended-lambda'
- KOKKOS_ARCH="SKX;Volta72"https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4370Tpetra: CMake output about CUDA-aware MPI should talk about environment varia...2019-02-11T22:44:51ZJames WillenbringTpetra: CMake output about CUDA-aware MPI should talk about environment variable that controls this behavior at run time*Created by: mhoemmen*
@trilinos/tpetra
Request by @amklinv : Tpetra attempts to detect at configure time whether the MPI implementation is CUDA aware. If that detection fails, Tpetra will assume by default that MPI is not CUDA awar...*Created by: mhoemmen*
@trilinos/tpetra
Request by @amklinv : Tpetra attempts to detect at configure time whether the MPI implementation is CUDA aware. If that detection fails, Tpetra will assume by default that MPI is not CUDA aware. That's OK, but it would be helpful for the warning message to say that Tpetra has an environment variable that users can set to override the default setting.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4364(C)Make fails at Scotch on various systems2019-03-08T07:06:46ZJames Willenbring(C)Make fails at Scotch on various systems*Created by: LennartSchu*
<!---
When building or cmake-ing the ShyLU-package, errors occur when enabling Scotch, which is needed by the Basker-LU-decomposition method.
-->
@trilinos/shylu
<!---
Assignees: If you know anyone w...*Created by: LennartSchu*
<!---
When building or cmake-ing the ShyLU-package, errors occur when enabling Scotch, which is needed by the Basker-LU-decomposition method.
-->
@trilinos/shylu
<!---
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.
-->
Hello,
I'm currently trying to build the ShyLU-package with the Basker solver on my systems. I've tried that on a Ubuntu 16.04.5 LTS xenial Server and a Fedora Workstation. Building the packages works on neither one of them with different errors. However, both errors seem to be caused by the Scotch-package.
In order to make sure that this error is not due to my system, I'm asking you to provide information about the system (OS, version, version of gcc, cmake, etc.) with which you build the Basker-Library in ShyLU. The README.txt in Trilinos/packages/shylu/shylu_node/Basker includes the info "Currently, it is unknown how Basker will behave on a random system and with HWLOC.", which is why I ask about your set up.
## Current Behavior
On Ubuntu, you have to build scotch version 6.0.3 by yourself since the most recent one provided by the official Ubuntu-repositories is version 5.1. Doing so, the CMake command (you find the exact commands below) runs fine and Scotch is included. However, running "make" gives numerous errors caused by scotch, first one of which is:
/home/om/Trilinos/packages/shylu/shylu_node/basker/src/shylubasker_order_scotch.hpp:186:5: error: ‘SCOTCH_Strat’ was not declared in this scope
SCOTCH_Strat strdat;
which indicates that Scotch is not actually linked in the process. My effort of debugging the error came to the conclusion that it might be due to the inclusion of the C-code into a C++-library. Scotch is written in C, but not included into the C++ code of Basker using an 'extern "C"'-statement. It might be that the version of g++ on the server (which is 5.5.0) does not support this.
Running the same CMake-command on the Fedora Workstation (which provides Scotch 6.0.7 in the repositories) fails at checking the scotch version:
HAVE_SCOTCH_VERSION_6_0_3 - Failure
even though Version 6.0.3 (or newer) is installed and cmake finds the libraries.
## Motivation and Context
I'm currently working on including Basker into the ida/sundials library. I've already included the NicsLU-solver into that library after observing that it is quicker in a testing environment I've set up for linear solvers. In my next step, I want to implement Basker into that testing enviroment to determine whether it would be useful for large-scale power system simulations. Finding quicker solvers is useful for both research and companies (e.g. transmission system operators) that use simulation software to provide stability and safety of the power supply of their customers.
## Steps to Reproduce
On Ubuntu 16.10 LTS:
1. Install Scotch 6.0.3 (or higher) manually and install it (here in /usr/local)
1. run cmake -DTrilinos_ENABLE_ShyLU=ON -DTrilinos_ENABLE_ShyLUBasker=ON -DTrilinos_ENABLE_ShyLU_NodeBasker=ON -DTPL_ENABLE_OpenMP=ON -DTrilinos_ENABLE_Kokkos=ON -DTrilinos_ENABLE_ShyLU_DD=ON -DTrilinos_ENABLE_ShyLU_DDBDDC=ON -DTPL_ENABLE_MPI=ON -DTrilinos_ENABLE_OpenMP=ON ..
1. run make
On Fedora Workstation:
1. Install Scotch (either using the official repositories or manually, the error will be the same)
1. run cmake -DTrilinos_ENABLE_ShyLU=ON -DTrilinos_ENABLE_ShyLUBasker=ON -DTrilinos_ENABLE_ShyLU_NodeBasker=ON -DTPL_ENABLE_OpenMP=ON -DTrilinos_ENABLE_Kokkos=ON -DTrilinos_ENABLE_ShyLU_DD=ON -DTrilinos_ENABLE_ShyLU_DDBDDC=ON -DTPL_ENABLE_MPI=ON -DTrilinos_ENABLE_OpenMP=ON ..
## Your Environment
<!---
Include relevant details about your environment such that we can replicate this
issue.
-->
- **Relevant configure flags or configure script:** the cmake-flags given above
- **Operating system and version:** Ubuntu 16.10 LTS and Fedora Workstation
- **Compiler and TPL versions:** gcc version 5 on Ubuntu, version 8 on Fedora
<!---
## 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/4360Question: Single-reduce iterative solvers in Belos2019-02-11T21:13:35ZJames WillenbringQuestion: Single-reduce iterative solvers in Belos*Created by: srajama1*
Do we have two "single-reduce" iterative methods in Belos ? One by Ichi that is Tpetra specific and one that can work with Epetra ? I would appreciate any pointers, new information on when to use one vs another, ...*Created by: srajama1*
Do we have two "single-reduce" iterative methods in Belos ? One by Ichi that is Tpetra specific and one that can work with Epetra ? I would appreciate any pointers, new information on when to use one vs another, differences etc.
@hkthorn @cgcgcg @egboman @mhoemmen https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4325MueLu: why using `linAlgebra=Epetra` with unit_tests_kokkos?2019-02-06T14:39:12ZJames WillenbringMueLu: why using `linAlgebra=Epetra` with unit_tests_kokkos?*Created by: lucbv*
@trilinos/muelu
## Expectations
It should be possible to use all of `kokkos` and `kokkos-kernels` in functions marked `_kokkos` in MueLu. Otherwise what is the point of the kokkos refactor?
## Current Behavior...*Created by: lucbv*
@trilinos/muelu
## Expectations
It should be possible to use all of `kokkos` and `kokkos-kernels` in functions marked `_kokkos` in MueLu. Otherwise what is the point of the kokkos refactor?
## Current Behavior
`unit_tests_kokkos.exe` is called with both `linAlgebra=Tpetra` and `linAlgebra=Epetra`
## Motivation and Context
Running these kokkos specific unit tests with `linAlgebra=Epetra` pretty much guarantees a problematic behavior and a failing test...
## Definition of Done
MueLu team members need to discuss the need for the `linAlgebra=Epetra` test of the kokkos refactor path in MueLu, if there is a legitimate reason for this behavior we then also need to come up with a reasonable way to still allow kokkos refactor work to happen while this restriction is applied.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4309MueLu: CoalesceDropFactory builds Import object ex nihilo, if we amalgamate2019-02-05T18:53:16ZJames WillenbringMueLu: CoalesceDropFactory builds Import object ex nihilo, if we amalgamate*Created by: csiefer2*
We should be able to amalgamate an importer.
Filing for future consideration.*Created by: csiefer2*
We should be able to amalgamate an importer.
Filing for future consideration.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4304MueLu: structured region driver2019-02-11T15:10:03ZJames WillenbringMueLu: structured region driver*Created by: lucbv*
@trilinos/muelu
@rstumin @mayrmt @pohm01
## Expectations
This new driver constructs a problem on a perfectly structured grid and provides necessary data for HHG region matrix construction
## Motivation and ...*Created by: lucbv*
@trilinos/muelu
@rstumin @mayrmt @pohm01
## Expectations
This new driver constructs a problem on a perfectly structured grid and provides necessary data for HHG region matrix construction
## Motivation and Context
This driver will provide a testing ground for new HHG capabilities on a simple mesh.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4300Stratimikos: "declaration shadows a typedef" warnings from Apple clang 10.0.02019-01-30T17:32:27ZJames WillenbringStratimikos: "declaration shadows a typedef" warnings from Apple clang 10.0.0*Created by: CamelliaDPG*
@trilinos/stratimikos
## Expectations
Builds with clang that use the `-Wshadow` flag should not emit warnings.
## Current Behavior
One warning is emitted by clang when building `BelosThyraAdapter.hpp`.
...*Created by: CamelliaDPG*
@trilinos/stratimikos
## Expectations
Builds with clang that use the `-Wshadow` flag should not emit warnings.
## Current Behavior
One warning is emitted by clang when building `BelosThyraAdapter.hpp`.
```
.../include/BelosThyraAdapter.hpp:301:49: warning: declaration shadows a typedef in 'MultiVecTraits<type-parameter-0-0, MultiVectorBase<type-parameter-0-0> >' [-Wshadow]
typedef Teuchos::ScalarTraits<ScalarType> ST;
^
.../include/BelosThyraAdapter.hpp:87:47: note: previous declaration is here
typedef Teuchos::ScalarTraits<ScalarType> ST;
```
## Possible Solution
Since the shadowing typedef is identical to the shadowed typedef, likely the correct solution is simply to delete the shadowing typedef (delete line 301).
## Environment
I'm building on a Mac using Apple clang 10.0.0.https://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.