Trilinos issueshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues2019-03-20T17:46:08Zhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/4663Epetra_CrsMatrix::Multiply with locally replicated range map question2019-03-20T17:46:08ZJames WillenbringEpetra_CrsMatrix::Multiply with locally replicated range map question*Created by: bartgol*
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
<!---
Note that an...*Created by: bartgol*
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
<!---
Note that anything between these delimiters is a comment that will not appear
in the issue description once created. Click on the Preview tab to see what
everything will look like when you submit.
-->
<!---
Feel free to delete anything from this template that is not applicable to the
issue you are submitting.
-->
<!---
Replace <teamName> below with the appropriate Trilinos package/team name.
-->
@trilinos/epetra
<!---
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.
-->
## Current Behavior
<!---
Tell us how the current behavior fails to meet your expectations in some way.
-->
Currently, if the range map is locally replicated, the result of `A.Apply(X,Y)` is not what I expected. In particular, Epetra does a final call `Y.Reduce()`, which ends up giving a Y vector that is numProc times larger than what I expected. Why is Epetra doing this? I.e., why are we reducing the output vector, in case of a locally replicated range map? Isn't the result (before the Reduce() call) already what one most likely wants? The user can always call `Y.Reduce()` if he is interested in that.
## Possible Solution
<!---
Not obligatory, but suggest a fix for the bug or documentation, or suggest
ideas on how to implement the addition or change.
-->
Assuming my concern is correct, simply remove line 3212 (and the likes in other branches of if statements) in Epetra_CrsMatrix.cpphttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/4651Piro: Epetra classes to check for int type before calling NumGlobalElements2019-03-19T15:50:51ZJames WillenbringPiro: Epetra classes to check for int type before calling NumGlobalElements*Created by: bartgol*
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
<!---
Note that an...*Created by: bartgol*
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
<!---
Note that anything between these delimiters is a comment that will not appear
in the issue description once created. Click on the Preview tab to see what
everything will look like when you submit.
-->
<!---
Feel free to delete anything from this template that is not applicable to the
issue you are submitting.
-->
<!---
Replace <teamName> below with the appropriate Trilinos package/team name.
-->
@trilinos/piro
<!---
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.
-->
One should be able to use Epetra maps with long long global indices, and still use Piro.
## Current Behavior
<!---
Tell us how the current behavior fails to meet your expectations in some way.
-->
If the Epetra maps are built with long long global indices, piro epetra classes to not work, due to calls to `NumGlobalElements` rather than `NumGlobalElements64`.
## 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.
-->
Albany needs to use 64bits global ordinals. Therefore, the epetra maps store long long global ordinals. However, the method `NumGlobalElements` in `Epetra_BlockMap` returns an int. One should use `NumGlobalElements64` to get a 64bits integer return value. Even more: the former method throws if the map actually stores 64bits integers.
## 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 epetra classes in piro (e.g., Piro::Epetra::NOXSolver) should work with both 32 and 64 bits integers.
## Possible Solution
<!---
Not obligatory, but suggest a fix for the bug or documentation, or suggest
ideas on how to implement the addition or change.
-->
Before each call to NumGlobalElements, check for the type of indices. If they are int (32bits), use `NumGlobalElements`, while if they are long long (64bits), use `NumGlobalElements64`.
https://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/4105Closing old PR #1019 "Misleading indentation (whitespace only)" 2018-12-20T18:57:01ZJames WillenbringClosing old PR #1019 "Misleading indentation (whitespace only)" *Created by: william76*
Pull Request #1019 "Misleading indentation (whitespace only)" is really old and appears to be stale and/or abandoned. I'm closing that PR and creating this issue to link to it.
I'm doing this because we need...*Created by: william76*
Pull Request #1019 "Misleading indentation (whitespace only)" is really old and appears to be stale and/or abandoned. I'm closing that PR and creating this issue to link to it.
I'm doing this because we need to close out some of the old PR's due to some GitHub limitations on the number of checks/hour that are allowed. The pull request autotester uses a polling model to check existing pull requests' status flags, etc. and we have occasionally hit that limit, which causes GitHub to reject the queries and can cause the Autotester to fail on a PR. If this PR needs to be brought back to life it can easily be reopened on the pull request page.
If this PR is truly dead, please close out this issue ticket.
FYI: @nschloe @egboman
PR #1019 touches files in these packages:
@trilinos/epetra
@trilinos/aztecoo
@trilinos/epetraext
@trilinos/isorropia
@trilinos/ml
@trilinos/pamgen https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4103Epetra: Closing old PR #503 "Updated minimal example Epetra_CrsMatrix.h ..." 2018-12-23T19:01:27ZJames WillenbringEpetra: Closing old PR #503 "Updated minimal example Epetra_CrsMatrix.h ..." *Created by: william76*
@trilinos/epetra
Pull Request #503 "WIP: Updated minimal example Epetra_CrsMatrix.h and Epetra_CrsMatrix.cpp…" is really old and appears to be stale and/or abandoned. I'm closing that PR and creating this is...*Created by: william76*
@trilinos/epetra
Pull Request #503 "WIP: Updated minimal example Epetra_CrsMatrix.h and Epetra_CrsMatrix.cpp…" is really old and appears to be stale and/or abandoned. I'm closing that PR and creating this issue to link to it.
I'm doing this because we need to close out some of the old PR's due to some GitHub limitations on the number of checks/hour that are allowed. The pull request autotester uses a polling model to check existing pull requests' status flags, etc. and we have occasionally hit that limit, which causes GitHub to reject the queries and can cause the Autotester to fail on a PR. If this PR needs to be brought back to life it can easily be reopened on the pull request page.
FYI: @michelemartone @mhoemmen https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4038Xpetra/Epetra: link error in panzer test for intel debug static2019-04-26T16:35:24ZJames WillenbringXpetra/Epetra: link error in panzer test for intel debug static*Created by: bathmatt*
<!---
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: ".
-->
When I try to link p...*Created by: bathmatt*
<!---
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: ".
-->
When I try to link packages/panzer/adapters-stk/test/solver/PanzerAdaptersSTK_solver.exe I get a missing tpetra symbol for intel debug static, but intel opt static works.. No idea why. This is with a RHEL7 machine using all sems and Ross' new build scripts.
<!---
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.
-->
Here is the error message I see, no idea why the xpetra epetra map is looking for something tpetra??
```
packages/xpetra/src/libxpetra.a(Xpetra_EpetraMap.cpp.o): In function `Tpetra::Details::LocalMap<int, long, Kokkos::Device<Kokkos::OpenMP, Kokkos::HostSpace> >::LocalMap()':
```
Here is my link line
```
: && /projects/sems/install/rhel7-x86_64/sems/compiler/intel/17.0.1/openmpi/1.10.1/bin/mpicxx --std=c++11 -g -fopenmp -g packages/panzer/adapters-stk/test/solver/CMakeFiles/PanzerAdaptersSTK_solver.dir/solver.cpp.o packages/panzer/adapters-stk/test/solver/CMakeFiles/PanzerAdaptersSTK_solver.dir/__/__/__/__/phalanx/test/Utilities/Phalanx_UnitTestMain.cpp.o -o packages/panzer/adapters-stk/test/solver/PanzerAdaptersSTK_solver.exe packages/panzer/adapters-stk/src/libpanzer-stk.a packages/muelu/adapters/libmuelu-adapters.a packages/muelu/src/Interface/libmuelu-interface.a packages/muelu/src/libmuelu.a packages/teko/src/libteko.a packages/ifpack2/adapters/libifpack2-adapters.a packages/ifpack2/src/libifpack2.a packages/seacas/libraries/ioss/src/main/libio_info_lib.a packages/seacas/libraries/ioss/src/init/libIonit.a packages/seacas/libraries/ioss/src/transform/libIotr.a packages/seacas/libraries/ioss/src/heartbeat/libIohb.a packages/seacas/libraries/ioss/src/gen_struc/libIogs.a packages/seacas/libraries/ioss/src/generated/libIogn.a packages/seacas/libraries/ioss/src/visualization/libIovs.a packages/seacas/libraries/ioss/src/pamgen/libIopg.a packages/seacas/libraries/ioss/src/exo_fac/libIoexo_fac.a packages/seacas/libraries/ioss/src/exo_fpp/libIofx.a packages/seacas/libraries/ioss/src/exodus/libIoex.a packages/seacas/libraries/ioss/src/libIoss.a packages/seacas/libraries/exodus/libexodus.a packages/panzer/disc-fe/src/libpanzer-disc-fe.a packages/panzer/dof-mgr/src/libpanzer-dof-mgr.a packages/phalanx/src/libphalanx.a packages/panzer/core/src/libpanzer-core.a packages/piro/src/libpiro.a packages/muelu/adapters/libmuelu-adapters.a packages/muelu/src/Interface/libmuelu-interface.a packages/muelu/src/libmuelu.a packages/intrepid2/src/libintrepid2.a packages/sacado/src/libsacado.a packages/tempus/src/libtempus.a packages/rythmos/src/librythmos.a packages/nox/src-loca/src-thyra/liblocathyra.a packages/nox/src-loca/src-epetra/liblocaepetra.a packages/nox/src-loca/src-lapack/liblocalapack.a packages/nox/src-loca/src/libloca.a packages/nox/src-epetra/libnoxepetra.a packages/nox/src-lapack/libnoxlapack.a packages/nox/src/libnox.a packages/teko/src/libteko.a packages/ifpack2/adapters/libifpack2-adapters.a packages/ifpack2/src/libifpack2.a packages/zoltan2/src/libzoltan2.a packages/anasazi/tpetra/src/libanasazitpetra.a packages/anasazi/epetra/util/ModeLaplace/libModeLaplace.a packages/anasazi/epetra/src/libanasaziepetra.a packages/anasazi/src/libanasazi.a packages/stk/stk_io/stk_io/util/libstk_io_util.a packages/stk/stk_io/stk_io/libstk_io.a packages/seacas/libraries/ioss/src/main/libio_info_lib.a packages/seacas/libraries/ioss/src/init/libIonit.a packages/seacas/libraries/ioss/src/transform/libIotr.a packages/seacas/libraries/ioss/src/heartbeat/libIohb.a packages/seacas/libraries/ioss/src/gen_struc/libIogs.a packages/seacas/libraries/ioss/src/generated/libIogn.a packages/seacas/libraries/ioss/src/visualization/libIovs.a packages/seacas/libraries/ioss/src/pamgen/libIopg.a packages/seacas/libraries/ioss/src/exo_fac/libIoexo_fac.a packages/seacas/libraries/ioss/src/exo_fpp/libIofx.a packages/seacas/libraries/ioss/src/exodus/libIoex.a packages/seacas/libraries/ioss/src/libIoss.a packages/pamgen/src/libpamgen_extras.a packages/pamgen/src/libpamgen.a packages/stk/stk_mesh/stk_mesh/base/libstk_mesh_base.a packages/shards/src/libshards.a packages/stk/stk_topology/stk_topology/libstk_topology.a packages/stk/stk_util/stk_util/use_cases/libstk_util_use_cases.a packages/stk/stk_util/stk_util/registry/libstk_util_registry.a packages/stk/stk_util/stk_util/diag/libstk_util_diag.a packages/stk/stk_util/stk_util/environment/libstk_util_env.a packages/stk/stk_util/stk_util/parallel/libstk_util_parallel.a packages/stk/stk_util/stk_util/util/libstk_util_util.a /projects/sems/install/rhel7-x86_64/sems/tpl/boost/1.59.0/intel/17.0.1/base/lib/libboost_program_options.so /projects/sems/install/rhel7-x86_64/sems/tpl/boost/1.59.0/intel/17.0.1/base/lib/libboost_system.so packages/seacas/libraries/aprepro_lib/libaprepro_lib.a packages/seacas/libraries/exodus/libexodus.a -L/projects/sems/install/rhel7-x86_64/sems/tpl/hdf5/1.8.12/intel/17.0.1/openmpi/1.10.1/parallel/lib -L/projects/sems/install/rhel7-x86_64/sems/tpl/boost/1.59.0/intel/17.0.1/base/lib -L/projects/sems/install/rhel7-x86_64/sems/tpl/netcdf/4.4.1/intel/17.0.1/openmpi/1.10.1/exo_parallel/lib -L/lib -lboost_program_options -lboost_system -lnetcdf -lpnetcdf -lhdf5 -lcurl -lhdf5_hl -lz packages/stratimikos/src/libstratimikos.a packages/stratimikos/adapters/belos/src/libstratimikosbelos.a packages/stratimikos/adapters/amesos2/src/libstratimikosamesos2.a packages/stratimikos/adapters/aztecoo/src/libstratimikosaztecoo.a packages/stratimikos/adapters/amesos/src/libstratimikosamesos.a packages/stratimikos/adapters/ml/src/libstratimikosml.a packages/stratimikos/adapters/ifpack/src/libstratimikosifpack.a packages/amesos2/src/libamesos2.a packages/ml/src/libml.a packages/galeri/src-xpetra/libgaleri-xpetra.a packages/galeri/src-epetra/libgaleri-epetra.a packages/ifpack/src/libifpack.a packages/amesos/src/libamesos.a packages/common/auxiliarySoftware/SuiteSparse/src/libtrilinosss.a packages/belos/xpetra/src/libbelosxpetra.a packages/belos/tpetra/src/libbelostpetra.a packages/belos/epetra/src/libbelosepetra.a packages/belos/src/libbelos.a packages/xpetra/sup/libxpetra-sup.a packages/xpetra/src/libxpetra.a packages/thyra/adapters/tpetra/src/libthyratpetra.a packages/thyra/adapters/epetraext/src/libthyraepetraext.a packages/epetraext/src/libepetraext.a packages/thyra/adapters/epetra/src/libthyraepetra.a packages/thyra/core/src/libthyracore.a packages/rtop/src/librtop.a packages/tpetra/core/ext/libtpetraext.a packages/tpetra/core/inout/libtpetrainout.a packages/tpetra/core/src/libtpetra.a packages/kokkos-kernels/src/libkokkoskernels.a packages/kokkos/algorithms/src/libkokkosalgorithms.a packages/kokkos/containers/src/libkokkoscontainers.a packages/tpetra/classic/LinAlg/libtpetraclassiclinalg.a packages/tpetra/classic/NodeAPI/libtpetraclassicnodeapi.a packages/tpetra/classic/src/libtpetraclassic.a packages/aztecoo/src/libaztecoo.a packages/triutils/src/libtriutils.a packages/epetra/src/libepetra.a packages/teuchos/kokkoscomm/src/libteuchoskokkoscomm.a packages/teuchos/kokkoscompat/src/libteuchoskokkoscompat.a packages/teuchos/remainder/src/libteuchosremainder.a packages/teuchos/numerics/src/libteuchosnumerics.a packages/teuchos/comm/src/libteuchoscomm.a packages/teuchos/parameterlist/src/libteuchosparameterlist.a packages/teuchos/parser/src/libteuchosparser.a -mkl packages/teuchos/core/src/libteuchoscore.a packages/kokkos/core/src/libkokkoscore.a -ldl packages/zoltan/src/libzoltan.a -lm && :
```
<!---
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/<teamName>
<!---
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:**
- **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/3589Epetra: NumGlobalElements in Epetra_Map without MPI2018-11-08T17:55:06ZJames WillenbringEpetra: NumGlobalElements in Epetra_Map without MPI*Created by: freaklovesmango*
If I create a Epetra_CrsMatrix and let's say this matrix is 10x10 big and has 50 non-zero values. If I want to create this without MPI, what is the right number for the NumGlobalElements for the Epetra_Map?...*Created by: freaklovesmango*
If I create a Epetra_CrsMatrix and let's say this matrix is 10x10 big and has 50 non-zero values. If I want to create this without MPI, what is the right number for the NumGlobalElements for the Epetra_Map? I mean how should I think this? Is it all non-zero values, hence 50? Or maybe the entries per row?
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3494Epetra lessons don't show code2018-09-27T18:05:14ZJames WillenbringEpetra lessons don't show code*Created by: davydden*
PackageName: Epetra
HTML pages for Epetra Lessons (i.e. https://trilinos.org/docs/dev/packages/epetra/doc/html/Epetra_Lesson02.html) do not render the code. This works as expected for TPetra (i.e. https://trili...*Created by: davydden*
PackageName: Epetra
HTML pages for Epetra Lessons (i.e. https://trilinos.org/docs/dev/packages/epetra/doc/html/Epetra_Lesson02.html) do not render the code. This works as expected for TPetra (i.e. https://trilinos.org/docs/dev/packages/tpetra/doc/html/Tpetra_Lesson01.html)
@trilinos/epetra
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3322Epetra_CrsMatrix: InsertMyValues() is not working correctly2018-08-20T04:47:15ZJames WillenbringEpetra_CrsMatrix: InsertMyValues() is not working correctly*Created by: freaklovesmango*
I am using the InsertMyValues() method of Epetra_CrsMatrix. However, it does not set the Col Index' correctly and I do not know why. If I change the visibility of the method InsertValues() which is called b...*Created by: freaklovesmango*
I am using the InsertMyValues() method of Epetra_CrsMatrix. However, it does not set the Col Index' correctly and I do not know why. If I change the visibility of the method InsertValues() which is called by InsertMyValues() from protected/private to public and use this instead of the other, the column IDs are set correctly.
Basically, what my code does is similar to this short version:
```
double c = 0.9;
for (int r = 0; r < 6; ++r ){
crsMatrix.InsertMyValues(r, 1, &c, &r);
}
std::cout << "The Matrix with InsertMyValues(): \n " << crsMatrix << std::endl;
```
where crsMatrix is a Epetra_CrsMatrix with a serial communicator.
The output is this:
```
The Matrix with InsertMyValues():
Epetra::CrsMatrix
Number of Global Rows = 6
Number of Global Cols = 6
Number of Global Diagonals = 0
Number of Global Nonzeros = 0
Global Maximum Num Entries = 0
** Matrix is Lower Triangular **
** Matrix is Upper Triangular **
** Matrix has no diagonal **
Number of My Rows = 6
Number of My Cols = 6
Number of My Diagonals = 0
Number of My Nonzeros = 0
My Maximum Num Entries = 1
Processor Row Index Col Index Value
0 0 -1 0.9
0 1 -1 0.9
0 2 -1 0.9
0 3 -1 0.9
0 4 -1 0.9
0 5 -1 0.9
```
wheras with InsertValues() the output is correct like this:
```
The Matrix with InsertValues():
Epetra::CrsMatrix
Number of Global Rows = 6
Number of Global Cols = 6
Number of Global Diagonals = 0
Number of Global Nonzeros = 0
Global Maximum Num Entries = 0
** Matrix is Lower Triangular **
** Matrix is Upper Triangular **
** Matrix has no diagonal **
Number of My Rows = 6
Number of My Cols = 6
Number of My Diagonals = 0
Number of My Nonzeros = 0
My Maximum Num Entries = 1
Processor Row Index Col Index Value
0 0 0 0.9
0 1 1 0.9
0 2 2 0.9
0 3 3 0.9
0 4 4 0.9
0 5 5 0.9
```
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3235Belos: BLAS error in GMRES - matrix with no entries on a rank2018-08-10T18:33:17ZJames WillenbringBelos: BLAS error in GMRES - matrix with no entries on a rank*Created by: chochmuth*
Hello,
I'm encountering a problem using Belos GMRES (Flexible GMRES too) with a matrix, that has an empty row, or several.
cblas_dgemm BLAS routine throws the following error:
`lda must be >= MAX(K,1): lda=0...*Created by: chochmuth*
Hello,
I'm encountering a problem using Belos GMRES (Flexible GMRES too) with a matrix, that has an empty row, or several.
cblas_dgemm BLAS routine throws the following error:
`lda must be >= MAX(K,1): lda=0 K=0ldb must be >= MAX(K,1): ldb=0 K=0BLAS error: Parameter number 9 passed to cblas_dgemm had an invalid value`
With parameter number 9(lda) standing for the number of rows.
Is this a desired/necessary behaviour?
You can find an example for a matrix with entries on the first mpi-rank only below.
It runs fine if executed on one mpi-rank but with more than one mpi-rank i get the above error.
```
#include <mpi.h>
#include <Teuchos_XMLParameterListCoreHelpers.hpp>
#include <Xpetra_Operator.hpp>
#include <Xpetra_Matrix_fwd.hpp>
#include <Xpetra_MatrixMatrix.hpp>
#include "Xpetra_MapFactory.hpp"
#include "Xpetra_MultiVectorFactory.hpp"
#include "Xpetra_MatrixFactory.hpp"
#include <BelosOperatorT.hpp>
#include <BelosXpetraAdapter.hpp>
#include <BelosSolverFactory.hpp>
#include <Xpetra_Export.hpp>
typedef unsigned UN;
typedef double SC;
typedef int LO;
typedef int GO;
typedef KokkosClassic::DefaultNode::DefaultNodeType EpetraNode;
typedef EpetraNode NO;
using namespace std;
using namespace Teuchos;
using namespace Xpetra;
using namespace Belos;
int main(int argc, char *argv[]) {
MPI_Init(&argc,&argv);
{
RCP<const Teuchos::Comm<int> > TeuchosComm = rcp(new MpiComm<int> (MPI_COMM_WORLD));
RCP<Map<LO,GO,NO> > UniqueMap;
RCP<Matrix<SC,LO,GO,NO> > K;
int NumMyElements = 0;
if (TeuchosComm->getRank()==0) {
NumMyElements = 10;
}
Array<GO> uniqueMapArray(NumMyElements);
for (LO i=0; i<uniqueMapArray.size(); i++) {
uniqueMapArray[i] = i;
}
UniqueMap = MapFactory<LO,GO,NO>::Build(UseTpetra,-1,uniqueMapArray(),0,TeuchosComm);
K = MatrixFactory<SC,LO,GO,NO>::Build(UniqueMap,1);
for (LO i=0; i<UniqueMap->getNodeNumElements(); i++) {
LO numEntries = 10-i;
Array<GO> indicesArray(numEntries);
Array<SC> valuesArray(numEntries);
for (LO k=0; k<numEntries; k++) {
indicesArray[k] = k+i;
valuesArray[k] = 1;
}
K->insertGlobalValues(UniqueMap->getGlobalElement(i),indicesArray(),valuesArray());
}
K->fillComplete();
//Solve with GMRES
RCP<MultiVector<SC,LO,GO,NO> > xSolution = MultiVectorFactory<SC,LO,GO,NO>::Build(UniqueMap,1);
RCP<MultiVector<SC,LO,GO,NO> > xRightHandSide = MultiVectorFactory<SC,LO,GO,NO>::Build(UniqueMap,1);
xSolution->putScalar(0.0);
xRightHandSide->putScalar(1.0);
RCP<OperatorT<MultiVector<SC,LO,GO,NO> > > OpK = rcp(new XpetraOp<SC, LO, GO, NO>(K));
RCP<LinearProblem<SC,MultiVector<SC,LO,GO,NO>,OperatorT<MultiVector<SC,LO,GO,NO> > > > belosLinearProblem(new LinearProblem<SC,MultiVector<SC,LO,GO,NO>,OperatorT<MultiVector<SC,LO,GO,NO> > >(OpK,xSolution,xRightHandSide));
SolverFactory<SC,MultiVector<SC,LO,GO,NO>,OperatorT<MultiVector<SC,LO,GO,NO> > > belosFactory;
RCP<ParameterList> solverParameterList = rcp(new ParameterList());
solverParameterList->set("Convergence Tolerance",1.e-12);
solverParameterList->set("Verbosity",47);
solverParameterList->set("Output Frequency",1);
solverParameterList->set("Output Style",1);
RCP<SolverManager<SC,MultiVector<SC,LO,GO,NO>,OperatorT<MultiVector<SC,LO,GO,NO> > > > belosSoverManager = belosFactory.create("GMRES",solverParameterList);
belosSoverManager->setProblem(belosLinearProblem);
belosLinearProblem->setProblem(xSolution,xRightHandSide);
belosSoverManager->solve();
}
MPI_Finalize();
return(EXIT_SUCCESS);
}
```
@trilinos/belos Belos
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3220teuchos can not find Epetra_ConfigDefs.h2018-08-03T16:13:13ZJames Willenbringteuchos can not find Epetra_ConfigDefs.h*Created by: VictorEijkhout*
That file is in `epetra/src`, but that directory is not listed as include path.
```
[ 98%] Building CXX object packages/PyTrilinos/src/CMakeFiles/pytrilinos.dir/PyTrilinos_DAP.cpp.o
cd /tmp/trilinos-bui...*Created by: VictorEijkhout*
That file is in `epetra/src`, but that directory is not listed as include path.
```
[ 98%] Building CXX object packages/PyTrilinos/src/CMakeFiles/pytrilinos.dir/PyTrilinos_DAP.cpp.o
cd /tmp/trilinos-build/packages/PyTrilinos/src && /opt/apps/intel18/cray_mpich/7.7.0/bin/mpicxx -Dpytrilinos_EXPORTS -I/tmp/trilinos-build -I/tmp/trilinos-build/packages/PyTrilinos/src -I/admin/
rpms/BUILD/trilinos-git/packages/PyTrilinos/src -I/opt/apps/intel18/python2/2.7.15/include/python2.7 -I/opt/apps/intel18/python2/2.7.15/lib/python2.7/site-packages/numpy-1.14.3-py2.7-linux-x86_64
.egg/numpy/core/include -I/opt/apps/intel18/cray_mpich_7_7/python2/2.7.15/lib/python2.7/site-packages/mpi4py/include -I/admin/rpms/BUILD/trilinos-git/packages/galeri/src-xpetra -I/tmp/trilinos-bu
ild/packages/galeri/src-xpetra -I/admin/rpms/BUILD/trilinos-git/packages/galeri/src-xpetra/../src-epetra -I/tmp/trilinos-build/packages/galeri/src-xpetra/../src-epetra -I/admin/rpms/BUILD/trilino
s-git/packages/galeri/src-xpetra/../src/Utils -I/admin/rpms/BUILD/trilinos-git/packages/galeri/src-xpetra/../src/Headers -I/admin/rpms/BUILD/trilinos-git/packages/xpetra/sup/Matrix -I/admin/rpms/
BUILD/trilinos-git/packages/xpetra/sup/StridedMap -I/admin/rpms/BUILD/trilinos-git/packages/xpetra/sup/Cloner -I/admin/rpms/BUILD/trilinos-git/packages/xpetra/sup/Utils -I/tmp/trilinos-build/pack
ages/xpetra/sup -I/admin/rpms/BUILD/trilinos-git/packages/xpetra/src/CrsGraph -I/admin/rpms/BUILD/trilinos-git/packages/xpetra/src/CrsMatrix -I/admin/rpms/BUILD/trilinos-git/packages/xpetra/src/B
lockedCrsMatrix -I/admin/rpms/BUILD/trilinos-git/packages/xpetra/src/DistObject -I/admin/rpms/BUILD/trilinos-git/packages/xpetra/src/Export -I/admin/rpms/BUILD/trilinos-git/packages/xpetra/src/He
aders -I/admin/rpms/BUILD/trilinos-git/packages/xpetra/src/Import -I/admin/rpms/BUILD/trilinos-git/packages/xpetra/src/Map -I/admin/rpms/BUILD/trilinos-git/packages/xpetra/src/BlockedMap -I/admin
/rpms/BUILD/trilinos-git/packages/xpetra/src/MultiVector -I/admin/rpms/BUILD/trilinos-git/packages/xpetra/src/BlockedMultiVector -I/admin/rpms/BUILD/trilinos-git/packages/xpetra/src/BlockedVector
-I/admin/rpms/BUILD/trilinos-git/packages/xpetra/src/Operator -I/admin/rpms/BUILD/trilinos-git/packages/xpetra/src/Platform -I/admin/rpms/BUILD/trilinos-git/packages/xpetra/src/RowGraph -I/admin
/rpms/BUILD/trilinos-git/packages/xpetra/src/RowMatrix -I/admin/rpms/BUILD/trilinos-git/packages/xpetra/src/Utils -I/admin/rpms/BUILD/trilinos-git/packages/xpetra/src/Utils/ForwardDeclaration -I/
admin/rpms/BUILD/trilinos-git/packages/xpetra/src/Vector -I/tmp/trilinos-build/packages/xpetra/src -I/admin/rpms/BUILD/trilinos-git/packages/thyra/adapters/tpetra/src -I/admin/rpms/BUILD/trilinos
-git/packages/thyra/core/src -I/admin/rpms/BUILD/trilinos-git/packages/thyra/core/src/interfaces/operator_vector/fundamental -I/admin/rpms/BUILD/trilinos-git/packages/thyra/core/src/interfaces/op
erator_vector/extended -I/admin/rpms/BUILD/trilinos-git/packages/thyra/core/src/support/operator_vector/client_support -I/admin/rpms/BUILD/trilinos-git/packages/thyra/core/src/support/operator_ve
ctor/adapter_support -I/admin/rpms/BUILD/trilinos-git/packages/thyra/core/src/interfaces/operator_solve/fundamental -I/admin/rpms/BUILD/trilinos-git/packages/thyra/core/src/interfaces/operator_so
lve/extended -I/admin/rpms/BUILD/trilinos-git/packages/thyra/core/src/support/operator_solve/client_support -I/admin/rpms/BUILD/trilinos-git/packages/thyra/core/src/interfaces/nonlinear/model_eva
luator/fundamental -I/admin/rpms/BUILD/trilinos-git/packages/thyra/core/src/support/nonlinear/model_evaluator/client_support -I/admin/rpms/BUILD/trilinos-git/packages/thyra/core/src/interfaces/no
nlinear/solvers/fundamental -I/admin/rpms/BUILD/trilinos-git/packages/thyra/core/src/support/nonlinear/solvers/client_support -I/tmp/trilinos-build/packages/thyra/core/src -I/admin/rpms/BUILD/tri
linos-git/packages/thyra/core/example/operator_vector -I/admin/rpms/BUILD/trilinos-git/packages/rtop/src -I/admin/rpms/BUILD/trilinos-git/packages/rtop/src/interfaces -I/admin/rpms/BUILD/trilinos
-git/packages/rtop/src/support -I/admin/rpms/BUILD/trilinos-git/packages/rtop/src/ops_lib -I/admin/rpms/BUILD/trilinos-git/packages/rtop/src/lapack -I/tmp/trilinos-build/packages/rtop/src -I/admi
n/rpms/BUILD/trilinos-git/packages/teuchos/numerics/src -I/admin/rpms/BUILD/trilinos-git/packages/teuchos/comm/src -I/admin/rpms/BUILD/trilinos-git/packages/teuchos/parameterlist/src -I/admin/rpm
s/BUILD/trilinos-git/packages/teuchos/parser/src -I/tmp/trilinos-build/packages/teuchos/core/src -I/admin/rpms/BUILD/trilinos-git/packages/teuchos/core/src -I/tmp/trilinos-build/packages/kokkos/c
ore/src -I/admin/rpms/BUILD/trilinos-git/packages/kokkos/core/src -I/opt/intel/compilers_and_libraries_2018.2.199/linux/mkl/include -I/admin/rpms/BUILD/trilinos-git/packages/tpetra/core/ext -I/tm
p/trilinos-build/packages/tpetra/core/ext -I/admin/rpms/BUILD/trilinos-git/packages/tpetra/core/inout -I/tmp/trilinos-build/packages/tpetra/core/inout -I/admin/rpms/BUILD/trilinos-git/packages/tp
etra/core/src -I/admin/rpms/BUILD/trilinos-git/packages/tpetra/core/src/kokkos_refactor -I/tmp/trilinos-build/packages/tpetra/core/src -I/admin/rpms/BUILD/trilinos-git/packages/tpetra/tsqr/src -I
/tmp/trilinos-build/packages/tpetra/tsqr/src -I/admin/rpms/BUILD/trilinos-git/packages/tpetra/classic/LinAlg -I/admin/rpms/BUILD/trilinos-git/packages/tpetra/classic/NodeAPI -I/tmp/trilinos-build
/packages/tpetra/classic/NodeAPI -I/tmp/trilinos-build/packages/tpetra/classic/src -I/admin/rpms/BUILD/trilinos-git/packages/tpetra/classic/src -I/tmp/trilinos-build/packages/teuchos/kokkoscomm/s
rc -I/admin/rpms/BUILD/trilinos-git/packages/teuchos/kokkoscomm/src -I/tmp/trilinos-build/packages/teuchos/kokkoscompat/src -I/admin/rpms/BUILD/trilinos-git/packages/teuchos/kokkoscompat/src -I/a
dmin/rpms/BUILD/trilinos-git/packages/teuchos/remainder/src -I/tmp/trilinos-build/packages/teuchos/remainder/src -I/tmp/trilinos-build/packages/kokkos-kernels/src -I/admin/rpms/BUILD/trilinos-git
/packages/kokkos-kernels/src -I/admin/rpms/BUILD/trilinos-git/packages/kokkos-kernels/src/impl -I/admin/rpms/BUILD/trilinos-git/packages/kokkos-kernels/src/impl/tpls -I/admin/rpms/BUILD/trilinos-
git/packages/kokkos-kernels/src/blas -I/admin/rpms/BUILD/trilinos-git/packages/kokkos-kernels/src/blas/impl -I/admin/rpms/BUILD/trilinos-git/packages/kokkos-kernels/src/sparse -I/admin/rpms/BUILD
/trilinos-git/packages/kokkos-kernels/src/sparse/impl -I/admin/rpms/BUILD/trilinos-git/packages/kokkos-kernels/src/graph -I/admin/rpms/BUILD/trilinos-git/packages/kokkos-kernels/src/graph/impl -I
/admin/rpms/BUILD/trilinos-git/packages/kokkos-kernels/src/batched -I/admin/rpms/BUILD/trilinos-git/packages/kokkos-kernels/src/batched/impl -I/admin/rpms/BUILD/trilinos-git/packages/kokkos-kerne
ls/src/common -I/tmp/trilinos-build/packages/kokkos/algorithms/src -I/admin/rpms/BUILD/trilinos-git/packages/kokkos/algorithms/src -I/tmp/trilinos-build/packages/kokkos/containers/src -I/admin/rp
ms/BUILD/trilinos-git/packages/kokkos/containers/src -I/tmp/trilinos-build/packages/domi/src -I/admin/rpms/BUILD/trilinos-git/packages/domi/src -g -xhost -O2 -mkl -DMPICH_SKIP_MPICXX -DHAVE_AMES
OS_SUPERLU5_API -DHAVE_AMESOS2_SUPERLU5_API -DHAVE_IFPACK2_SUPERLU5_API -std=c++11 -O3 -DNDEBUG -fPIC -o CMakeFiles/pytrilinos.dir/PyTrilinos_DAP.cpp.o -c /admin/rpms/BUILD/trilinos-git/package
s/PyTrilinos/src/PyTrilinos_DAP.cpp
In file included from /admin/rpms/BUILD/trilinos-git/packages/PyTrilinos/src/PyTrilinos_Galeri_Headers.hpp(53),
from /tmp/trilinos-build/packages/PyTrilinos/src/Teuchos.RCPPYTHON_wrap.cpp(3209):
/admin/rpms/BUILD/trilinos-git/packages/galeri/src-xpetra/../src-epetra/Galeri_Maps.h(47): catastrophic error: cannot open source file "Epetra_ConfigDefs.h"
#include "Epetra_ConfigDefs.h"
^
compilation aborted for /tmp/trilinos-build/packages/PyTrilinos/src/Teuchos.RCPPYTHON_wrap.cpp (code 4)
make[2]: *** [packages/PyTrilinos/src/CMakeFiles/PyTrilinos_Teuchos_RCP.dir/Teuchos.RCPPYTHON_wrap.cpp.o] Error 4
make[2]: Leaving directory `/tmp/trilinos-build'
make[1]: *** [packages/PyTrilinos/src/CMakeFiles/PyTrilinos_Teuchos_RCP.dir/all] Error 2
```https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3207Epetra: What's the point of BlockMap?2018-08-01T16:13:05ZJames WillenbringEpetra: What's the point of BlockMap?*Created by: bartgol*
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
<!---
Note that an...*Created by: bartgol*
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
<!---
Note that anything between these delimiters is a comment that will not appear
in the issue description once created. Click on the Preview tab to see what
everything will look like when you submit.
-->
<!---
Feel free to delete anything from this template that is not applicable to the
issue you are submitting.
-->
<!---
Replace <teamName> below with the appropriate Trilinos package/team name.
-->
@trilinos/Epetra
<!---
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.
-->
## 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.
-->
This is more of a big picture view, but its consequences have sometimes bit me when implementing functions that take `Epetra_Map&` as input. As I see it, `Epetra_Map` is just a 'special case' of `Epetra_BlockMap`, when all blocks have size one. It is useful to enforce this constraint at compile time, rather than check inside every constructor if that's the case. On the other hand, this code does not compile:
```
void f(const Epetra_Map& m) {...}
void g(const Epetra_Vector&v) { f(v.Map()); }
```
since the `Map()` method returns a reference to `Epetra_BlockMap`, and you would have to cast `Epetra_BlockMap` down to `Epetra_Map` before calling `f`. Yes, this is possible, since `Epetra_Map` does not store any additional attribute compared to `Epetra_BlockMap`, but it is...ugly!
However, it appears to me that _all_ Epetra classes use only `Epetra_Map&`. All the matrices only accept and return `Epetra_Map`. Even the vector and multivector, which formally take a `Epetra_BlockMap` as input at construction, allocate enough space for `Map().NumMyPoints()` doubles (per vector), which means they would be _wrong_ if the element size is larger than one.
Or perhaps I am completely misunderstanding what `Epetra_BlockMap` is intended to do.
Could someone shed some light on this? Or, if my impression is right, why shouldn't we completely remove the `Epetra_BlockMap` (perhaps with a typedef for backward compatibility)?https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3192Epetra64: Epetra_CrsMatrix throws if given a Map with a 64-bit (long long) nu...2018-07-28T18:22:29ZJames WillenbringEpetra64: Epetra_CrsMatrix throws if given a Map with a 64-bit (long long) number of rows; 32-bit (int) number of rows is OK*Created by: mhoemmen*
I was working on #3139, in particular on an Ifpack2 BlockRelaxation test that @brian-kelley wrote, that compares Ifpack2 and ML performance. My first pass of changes used a 64-bit (`long long`) value for the glob...*Created by: mhoemmen*
I was working on #3139, in particular on an Ifpack2 BlockRelaxation test that @brian-kelley wrote, that compares Ifpack2 and ML performance. My first pass of changes used a 64-bit (`long long`) value for the global number of rows, when building both an Epetra and a Tpetra Map. The test threw in that case. However, when I gave `Epetra_Map`'s constructor the global number of rows as a 32-bit (`int`) value, the test passed.
@trilinos/epetra @trilinos/tpetra @trilinos/ifpack2 @kddevin
## Expectations
`Epetra_CrsMatrix` should behave the same, whether its row Map was created with a 64-bit or 32-bit global number of indices.
## Current Behavior
```c++
using GO = long long;
const GO localRows = 5000;
#ifdef EPETRA_MPI
Epetra_MpiComm ecomm(MPI_COMM_WORLD);
#else
Epetra_SerialComm ecomm;
#endif
// If I cast localRows to int, this code doesn't throw.
// Otherwise, something after the Epetra_Map constructor will throw.
Epetra_Map rowmap(localRows, 0, ecomm);
Teuchos::RCP<Epetra_CrsMatrix> crsmatrix =
Teuchos::rcp(new Epetra_CrsMatrix(Epetra_DataAccess::Copy, rowmap, 3));
int numRows = rowmap.NumGlobalElements();
double tile[3] = {-2, 4, -2};
int firstCols[] = {0, 1};
crsmatrix->InsertGlobalValues(0, 2, tile + 1, firstCols);
for(int row = 1; row < numRows - 1; row++)
{
int cols[] = {row - 1, row, row + 1};
crsmatrix->InsertGlobalValues(row, 3, tile, cols);
}
int lastCols[] = {numRows - 2, numRows - 1};
crsmatrix->InsertGlobalValues(numRows - 1, 2, tile, lastCols);
crsmatrix->FillComplete();
```
I see now that the code passes 32-bit global column indices into `InsertGlobalValues`. Is it wrong to do that after creating a row Map with a 64-bit global number of rows? That's very easy to do when writing Epetra vs. Tpetra comparisons.
## Motivation and Context
This hindered #3139. Also, we're generally interested in Epetra vs. Tpetra performance comparisons.
## Related Issues
* Related to #3139
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3041Xpetra/Epetra Undefined Reference when Compiling MueLu Test2019-04-03T13:29:08ZJames WillenbringXpetra/Epetra Undefined Reference when Compiling MueLu Test*Created by: nmhamster*
@trilinos/muelu @trilinos/xpetra
Compiling Trilinos (with tests) for KNL on Argonne Theta. I am using the Master branch.
Using:
* Cray MPI
* Intel 18.2 Compiler
* OpenMP enabled
```
[100%] Built ...*Created by: nmhamster*
@trilinos/muelu @trilinos/xpetra
Compiling Trilinos (with tests) for KNL on Argonne Theta. I am using the Master branch.
Using:
* Cray MPI
* Intel 18.2 Compiler
* OpenMP enabled
```
[100%] Built target MueLu_Viz
[100%] Built target MueLu_Convergence
[100%] Linking CXX executable MueLu_Driver.exe
Warning:
Headers and libraries from cray-libsci/18.04.1 will be ignored because they conflict with -mkl.
../../../kokkos/core/src/libkokkoscore.a(Kokkos_Profiling_Interface.cpp.o): In function `Kokkos::Profiling::initialize()':
../../../kokkos/core/src/libkokkoscore.a(Kokkos_Profiling_Interface.cpp.o): In function `Kokkos::Profiling::initialize()':
Kokkos_Profiling_Interface.cpp:(.text+0x5c5): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
CMakeFiles/MueLu_Driver.dir/Driver.cpp.o: In function `int main_<double, int, long, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::Serial, Kokkos::HostSpace> >(Teuchos::CommandLineProcessor&, Xpetra::UnderlyingLib&, int, char**)':
Driver.cpp:(.text._Z5main_IdilN6Kokkos6Compat23KokkosDeviceWrapperNodeINS0_6SerialENS0_9HostSpaceEEEEiRN7Teuchos20CommandLineProcessorERN6Xpetra13UnderlyingLibEiPPc[_Z5main_IdilN6Kokkos6Compat23KokkosDeviceWrapperNodeINS0_6SerialENS0_9HostSpaceEEEEiRN7Teuchos20CommandLineProcessorERN6Xpetra13UnderlyingLibEiPPc]+0x31ca): undefined reference to `Epetra_MultiVector& Xpetra::toEpetra<long, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::Serial, Kokkos::HostSpace> >(Xpetra::MultiVector<double, int, long, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::Serial, Kokkos::HostSpace> >&)'
Driver.cpp:(.text._Z5main_IdilN6Kokkos6Compat23KokkosDeviceWrapperNodeINS0_6SerialENS0_9HostSpaceEEEEiRN7Teuchos20CommandLineProcessorERN6Xpetra13UnderlyingLibEiPPc[_Z5main_IdilN6Kokkos6Compat23KokkosDeviceWrapperNodeINS0_6SerialENS0_9HostSpaceEEEEiRN7Teuchos20CommandLineProcessorERN6Xpetra13UnderlyingLibEiPPc]+0x3213): undefined reference to `Epetra_MultiVector& Xpetra::toEpetra<long, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::Serial, Kokkos::HostSpace> >(Xpetra::MultiVector<double, int, long, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::Serial, Kokkos::HostSpace> >&)'
CMakeFiles/MueLu_Driver.dir/Driver.cpp.o: In function `int main_<double, int, long, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::OpenMP, Kokkos::HostSpace> >(Teuchos::CommandLineProcessor&, Xpetra::UnderlyingLib&, int, char**)':
Driver.cpp:(.text._Z5main_IdilN6Kokkos6Compat23KokkosDeviceWrapperNodeINS0_6OpenMPENS0_9HostSpaceEEEEiRN7Teuchos20CommandLineProcessorERN6Xpetra13UnderlyingLibEiPPc[_Z5main_IdilN6Kokkos6Compat23KokkosDeviceWrapperNodeINS0_6OpenMPENS0_9HostSpaceEEEEiRN7Teuchos20CommandLineProcessorERN6Xpetra13UnderlyingLibEiPPc]+0x31ca): undefined reference to `Epetra_MultiVector& Xpetra::toEpetra<long, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::OpenMP, Kokkos::HostSpace> >(Xpetra::MultiVector<double, int, long, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::OpenMP, Kokkos::HostSpace> >&)'
Driver.cpp:(.text._Z5main_IdilN6Kokkos6Compat23KokkosDeviceWrapperNodeINS0_6OpenMPENS0_9HostSpaceEEEEiRN7Teuchos20CommandLineProcessorERN6Xpetra13UnderlyingLibEiPPc[_Z5main_IdilN6Kokkos6Compat23KokkosDeviceWrapperNodeINS0_6OpenMPENS0_9HostSpaceEEEEiRN7Teuchos20CommandLineProcessorERN6Xpetra13UnderlyingLibEiPPc]+0x3213): undefined reference to `Epetra_MultiVector& Xpetra::toEpetra<long, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::OpenMP, Kokkos::HostSpace> >(Xpetra::MultiVector<double, int, long, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::OpenMP, Kokkos::HostSpace> >&)'
```https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2795Epetra requires C++11 now; update documentation2018-05-22T20:13:48ZJames WillenbringEpetra requires C++11 now; update documentation*Created by: mhoemmen*
I merged the following pull request that fixes GLIBCXX debug checking for deal.II's tests:
https://github.com/trilinos/Trilinos/pull/2783
This pull request introduces a modest C++11 requirement into Epetra. ...*Created by: mhoemmen*
I merged the following pull request that fixes GLIBCXX debug checking for deal.II's tests:
https://github.com/trilinos/Trilinos/pull/2783
This pull request introduces a modest C++11 requirement into Epetra. Please see discussion there for rationale. In particular, no one could come up with a current use case demanding that Epetra be built with a C++98 compiler. Even the Epetra-only MueLu build for Windows requires Teuchos, which in turn requires C++11. More importantly, we have no idea if Epetra builds with a C++98 compiler, since we have not tested this use case for a long time.
@trilinos/epetra @trilinos/framework @trilinos/muelu @maherou @trilinos/tpetra
If y'all have a problem with that, now might be a good time to say something. Otherwise, I hereby declare that Epetra now requires C++11. Next step is to update Epetra's documentation to make this clear.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2743Epetra: Epetra_IntMultiVectorDistributed_test failing in nightly clean build2018-05-15T14:40:20ZJames WillenbringEpetra: Epetra_IntMultiVectorDistributed_test failing in nightly clean build*Created by: william76*
<!---
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: ".
-->
@trilinos/epetra
...*Created by: william76*
<!---
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: ".
-->
@trilinos/epetra
The test [Epetra_IntMultiVectorDistributed](https://testing-vm.sandia.gov/cdash/testDetails.php?test=46495883&build=3509186) is failing on nightly Clean testing.
### Test output
```
Epetra in Trilinos 12.13 (Dev)
Processor 0 of 1 is alive.
Non zero error code 1, file: /scratch/trilinos/workspace/trilinos-folder/Trilinos_generic_nightly@2/SERIAL_Release_gcc_4.9.3__DEV/Trilinos/packages/epetra/test/IntMultiVectorDistributed/cxx_main.cpp, line: 168
Non zero error code 1, file: /scratch/trilinos/workspace/trilinos-folder/Trilinos_generic_nightly@2/SERIAL_Release_gcc_4.9.3__DEV/Trilinos/packages/epetra/test/IntMultiVectorDistributed/cxx_main.cpp, line: 170
Non zero error code 1, file: /scratch/trilinos/workspace/trilinos-folder/Trilinos_generic_nightly@2/SERIAL_Release_gcc_4.9.3__DEV/Trilinos/packages/epetra/test/IntMultiVectorDistributed/cxx_main.cpp, line: 172
```
@lucbv had the most recent commit to [epetra/test/IntMultiVectorDistributed/cxx_main.cpp](https://github.com/trilinos/Trilinos/blob/develop/packages/epetra/test/IntMultiVectorDistributed/cxx_main.cpp). https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2692PyTrilinos: build fails when Epetra, NOX enabled, but not Ifpack2018-10-10T05:23:13ZJames WillenbringPyTrilinos: build fails when Epetra, NOX enabled, but not Ifpack*Created by: wfspotz*
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
<!---
Note that an...*Created by: wfspotz*
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
<!---
Note that anything between these delimiters is a comment that will not appear
in the issue description once created. Click on the Preview tab to see what
everything will look like when you submit.
-->
<!---
Feel free to delete anything from this template that is not applicable to the
issue you are submitting.
-->
<!---
Replace <teamName> below with the appropriate Trilinos package/team name.
-->
@trilinos/pytrilinos
<!---
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.
-->
When PyTrilinos, Epetra, and NOX are enabled, but Ifpack is not, PyTrilinos should build without error. The `NOX.Epetra` module should NOT be enabled, consistent with NOX.
## Current Behavior
<!---
Tell us how the current behavior fails to meet your expectations in some way.
-->
The build fails because NOX does not enable `NOX::Epetra`, but PyTrilinos tries to wrap these interfaces.
## 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.
-->
A user tried to build with this combination and ran into the failed build. PyTrilinos should be checking the `NOX_ENABLE_ABSTRACT_IMPLEMENTATION_EPETRA` Cmake variable.
## 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.
-->
- [x] Rework the PyTrilinos configuration logic to check `NOX_ENABLE_ABSTRACT_IMPLEMENTATION_EPETRA`
- [x] Test that the above-mentioned combination of packages builds cleanly
- [x] Test that the `NOX.Epetra` module is not enabled
- [x] Test that enabled PyTrilinos tests pass
- [x] Test that when proper packages ARE enabled, that `NOX.Epetra` does get enabled and that tests pass
N.B. Both AztecOO and Amesos have to be enabled for the last step to work.
<!--- ## 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. Write a cmake script that disables all packages except PyTrilinos, Epetra, and NOX
1. Verify build failure
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2590Epetra: adding IntMultiVector to mirror the IntVector object2018-05-15T16:30:29ZJames WillenbringEpetra: adding IntMultiVector to mirror the IntVector object*Created by: lucbv*
@trilinos/epetra
@csiefer2 @mhoemmen
## Expectations
Implementation of a `IntMultiVector` class that allows for the storage of multiple indices in the same object instead of using arrays of `IntVector` which i...*Created by: lucbv*
@trilinos/epetra
@csiefer2 @mhoemmen
## Expectations
Implementation of a `IntMultiVector` class that allows for the storage of multiple indices in the same object instead of using arrays of `IntVector` which is a more sketchy...
## Current Behavior
Currently such object does not exist and that leads to funny code with multiple `IntVectors` stored in Arrays or `std::vector`. Also this would use significantly less storage than the equivalent `MultiVector` in the case of `int` data
## Motivation and Context
The implementation of overlapping aggregates in MueLu requires to store multiple indices per node and it was done in the case of non-overlapping aggregates done with IntVector.
## Definition of Done
The implementation of an `IntMultiVector` class that mirrors the capabilities of the `IntVector` class.
## Possible Solution
see above
## Related Issues
* Blocks #2577
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2522Xpetra::CrsMatrix::doImport() fails with Negative count into MPI_Send2018-04-24T22:39:06ZJames WillenbringXpetra::CrsMatrix::doImport() fails with Negative count into MPI_Send*Created by: SG38*
The MPI_Send() has a Negative count when importing big data set of a matrix ; same issue with MultiVector and CrsMatrix. When distributing the matrix with an import of the SerialMatrix rows:
_RCP<Xpetra::Import<SOL...*Created by: SG38*
The MPI_Send() has a Negative count when importing big data set of a matrix ; same issue with MultiVector and CrsMatrix. When distributing the matrix with an import of the SerialMatrix rows:
_RCP<Xpetra::Import<SOL_LO, SOL_GO, SOL_EPETRA_TYPE> > importer = Xpetra::ImportFactory<SOL_LO, SOL_GO, SOL_EPETRA_TYPE>::Build(SerialMap, DistributedMap);_
_DistributedMatrix->doImport(*SerialMatrix, *importer, Xpetra::INSERT);_
It throws:
> Fatal error in MPI_Send: Invalid count, error stack:
> MPI_Send(201): MPI_Send(buf=0x7ffb33824100, count=-2131745804, MPI_CHAR, dest=1, tag=1, MPI_COMM_WORLD) failed
> MPI_Send(117): Negative count, value is -2131745804
Configuration is:
(1) Trilinos 12.12.1
Linux 64 bits
(2) CMakeCache:
- Tpetra_INST_INT_LONG_LONG:BOOL=ON
- HAVE_TEUCHOS_LONG_LONG_INT:INTERNAL=ON
- HAVE_TEUCHOS___INT64:INTERNAL=1
(3) program:
- Xpetra::UseTpetra
- Xpetra::CrsMatrix<int, signed long long, KokkosClassic::DefaultNode::DefaultNodeType>
- Teuchos::Comm< int > comm;
@trilinos/Teuchos
To be honest, I do not understand the source code of the Teuchos communicator. More precisely, i do not find any source code where the _send_ counter would be a long long. Is there a way to distribute big matrices?
Thank you in advance,
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2448CEpetra_LAPACK: "no matching function for call to Epetra_LAPACK::GGSVD" with ...2018-03-31T15:59:25ZJames WillenbringCEpetra_LAPACK: "no matching function for call to Epetra_LAPACK::GGSVD" with HAVE_EPETRA_LAPACK_GSSVD3*Created by: edmondac*
I'm trying to build Trilinos but get the following error:
```
<PATH>/trilinos-12.12.1-Source/packages/CTrilinos/src/epetra/CEpetra_LAPACK.cpp: In function ‘void Epetra_LAPACK_GGSVD_double(CT_Epetra_LAPACK_ID_...*Created by: edmondac*
I'm trying to build Trilinos but get the following error:
```
<PATH>/trilinos-12.12.1-Source/packages/CTrilinos/src/epetra/CEpetra_LAPACK.cpp: In function ‘void Epetra_LAPACK_GGSVD_double(CT_Epetra_LAPACK_ID_t, char, char, char, i nt, int, int, int*, int*, double*, int, double*, int, double*, double*, double*, int, double*, int, double*, int, double*, int*, int*)’:
<PATH>/trilinos-12.12.1-Source/packages/CTrilinos/src/epetra/CEpetra_LAPACK.cpp:612:76: error: no matching function for call to ‘Epetra_LAPACK::GGSVD(const char&, const char&, const char&, const int&, const int&, const int&, int*&, int*&, double*&, const int&, double*&, const int&, double*&, double*&, double*&, const int&, double*&, const int&, double*&, const int&, double*&, int*&, int*&) const’
LDA, B, LDB, ALPHA, BETA, U, LDU, V, LDV, Q, LDQ, WORK, IWORK, INFO);
^
In file included from <PATH>/trilinos-12.12.1-Source/packages/CTrilinos/src/epetra/CEpetra_LAPACK_Cpp.hpp:52:0,
from <PATH>/trilinos-12.12.1-Source/packages/CTrilinos/src/epetra/CEpetra_LAPACK.cpp:50:
<PATH>/trilinos-12.12.1-Source/packages/epetra/src/Epetra_LAPACK.h:279:8: note: candidate: void Epetra_LAPACK::GGSVD(char, char, char, int, int, int, int*, int*, double *, int, double*, int, double*, double*, double*, int, double*, int, double*, int, double*, int, int*, int*) const
void GGSVD(const char JOBU, const char JOBV, const char JOBQ, const int M, const int N, const int P, int * K, int * L, double* A, const int LDA, double* B, const int LDB,
^~~~~
<PATH>/trilinos-12.12.1-Source/packages/epetra/src/Epetra_LAPACK.h:279:8: note: candidate expects 24 arguments, 23 provided
<PATH>/trilinos-12.12.1-Source/packages/epetra/src/Epetra_LAPACK.h:286:8: note: candidate: void Epetra_LAPACK::GGSVD(char, char, char, int, int, int, int*, int*, float* , int, float*, int, float*, float*, float*, int, float*, int, float*, int, float*, int, int*, int*) const
void GGSVD(const char JOBU, const char JOBV, const char JOBQ, const int M, const int N, const int P, int * K, int * L, float* A, const int LDA, float* B, const int LDB,
^~~~~
<PATH>/trilinos-12.12.1-Source/packages/epetra/src/Epetra_LAPACK.h:286:8: note: candidate expects 24 arguments, 23 provided
<PATH>/trilinos-12.12.1-Source/packages/CTrilinos/src/epetra/CEpetra_LAPACK.cpp: In function ‘void Epetra_LAPACK_GGSVD_float(CT_Epetra_LAPACK_ID_t, char, char, char, in t, int, int, int*, int*, float*, int, float*, int, float*, float*, float*, int, float*, int, float*, int, float*, int*, int*)’:
<PATH>/trilinos-12.12.1-Source/packages/CTrilinos/src/epetra/CEpetra_LAPACK.cpp:624:76: error: no matching function for call to ‘Epetra_LAPACK::GGSVD(const char&, const char&, const char&, const int&, const int&, const int&, int*&, int*&, float*&, const int&, float*&, const int&, float*&, float*&, float*&, const int&, float*&, const int&, float*&, const int&, float*&, int*&, int*&) const’
LDA, B, LDB, ALPHA, BETA, U, LDU, V, LDV, Q, LDQ, WORK, IWORK, INFO);
^
In file included from <PATH>/trilinos-12.12.1-Source/packages/CTrilinos/src/epetra/CEpetra_LAPACK_Cpp.hpp:52:0,
from <PATH>/trilinos-12.12.1-Source/packages/CTrilinos/src/epetra/CEpetra_LAPACK.cpp:50:
<PATH>/trilinos-12.12.1-Source/packages/epetra/src/Epetra_LAPACK.h:279:8: note: candidate: void Epetra_LAPACK::GGSVD(char, char, char, int, int, int, int*, int*, double *, int, double*, int, double*, double*, double*, int, double*, int, double*, int, double*, int, int*, int*) const
void GGSVD(const char JOBU, const char JOBV, const char JOBQ, const int M, const int N, const int P, int * K, int * L, double* A, const int LDA, double* B, const int LDB,
^~~~~
<PATH>/trilinos-12.12.1-Source/packages/epetra/src/Epetra_LAPACK.h:279:8: note: candidate expects 24 arguments, 23 provided
<PATH>/trilinos-12.12.1-Source/packages/epetra/src/Epetra_LAPACK.h:286:8: note: candidate: void Epetra_LAPACK::GGSVD(char, char, char, int, int, int, int*, int*, float* , int, float*, int, float*, float*, float*, int, float*, int, float*, int, float*, int, int*, int*) const
void GGSVD(const char JOBU, const char JOBV, const char JOBQ, const int M, const int N, const int P, int * K, int * L, float* A, const int LDA, float* B, const int LDB,
^~~~~
<PATH>/trilinos-12.12.1-Source/packages/epetra/src/Epetra_LAPACK.h:286:8: note: candidate expects 24 arguments, 23 provided
```
The problem seems to stem from packages/epetra/src/Epetra_LAPACK.cpp having been changed to add an extra argument for GSSVD3 but packages/CTrilinos/src/epetra/CEpetra_LAPACK.cpp not so:
packages/CTrilinos/src/epetra/CEpetra_LAPACK.cpp:
```
603 void Epetra_LAPACK_GGSVD_double (
604 CT_Epetra_LAPACK_ID_t selfID, const char JOBU, const char JOBV,
605 const char JOBQ, const int M, const int N, const int P, int * K,
606 int * L, double * A, const int LDA, double * B, const int LDB,
607 double * ALPHA, double * BETA, double * U, const int LDU,
608 double * V, const int LDV, double * Q, const int LDQ,
609 double * WORK, int * IWORK, int * INFO )
610 {
611 CEpetra::getConstLAPACK(selfID)->GGSVD(JOBU, JOBV, JOBQ, M, N, P, K, L, A,
612 LDA, B, LDB, ALPHA, BETA, U, LDU, V, LDV, Q, LDQ, WORK, IWORK, INFO);
613 }
614
615 void Epetra_LAPACK_GGSVD_float (
616 CT_Epetra_LAPACK_ID_t selfID, const char JOBU, const char JOBV,
617 const char JOBQ, const int M, const int N, const int P, int * K,
618 int * L, float * A, const int LDA, float * B, const int LDB,
619 float * ALPHA, float * BETA, float * U, const int LDU, float * V,
620 const int LDV, float * Q, const int LDQ, float * WORK,
621 int * IWORK, int * INFO )
622 {
623 CEpetra::getConstLAPACK(selfID)->GGSVD(JOBU, JOBV, JOBQ, M, N, P, K, L, A,
624 LDA, B, LDB, ALPHA, BETA, U, LDU, V, LDV, Q, LDQ, WORK, IWORK, INFO);
625 }
```
packages/epetra/src/Epetra_LAPACK.cpp
```
363 //=============================================================================
364 void Epetra_LAPACK::GGSVD(const char JOBU, const char JOBV, const char JOBQ, const int M, const int N, const int P, int * K, int * L,
365 double* A, const int LDA, double* B, const int LDB,
366 double* ALPHA, double* BETA, double* U, const int LDU, double* V, const int LDV, double* Q, const int LDQ, double* WORK,
367 #ifdef HAVE_EPETRA_LAPACK_GSSVD3
368 const int LWORK,
369 #endif
370 int* IWORK, int* INFO) const {
371 DGGSVD_F77(CHAR_MACRO(JOBU), CHAR_MACRO(JOBV), CHAR_MACRO(JOBQ), &M, &N, &P, K, L, A, &LDA, B, &LDB,
372 ALPHA, BETA, U, &LDU, V, &LDV, Q, &LDQ, WORK,
373 #ifdef HAVE_EPETRA_LAPACK_GSSVD3
374 &LWORK,
375 #endif
376 IWORK, INFO);
377 }
378
379 //=============================================================================
380 void Epetra_LAPACK::GGSVD(const char JOBU, const char JOBV, const char JOBQ, const int M, const int N, const int P, int * K, int * L,
381 float* A, const int LDA, float* B, const int LDB,
382 float* ALPHA, float* BETA, float* U, const int LDU, float* V, const int LDV, float* Q, const int LDQ, float* WORK,
383 #ifdef HAVE_EPETRA_LAPACK_GSSVD3
384 const int LWORK,
385 #endif
386 int* IWORK, int* INFO) const {
387 SGGSVD_F77(CHAR_MACRO(JOBU), CHAR_MACRO(JOBV), CHAR_MACRO(JOBQ), &M, &N, &P, K, L, A, &LDA, B, &LDB,
388 ALPHA, BETA, U, &LDU, V, &LDV, Q, &LDQ, WORK,
389 #ifdef HAVE_EPETRA_LAPACK_GSSVD3
390 &LWORK,
391 #endif
392 IWORK, INFO);
393 }
```
I've got a patch that builds on my system, but it wouldn't work in the opposite situation as the header doesn't use an ifdef.