[Trilinos-Users] bug in Tpetra::CrsGraph()?

[Baker, Christopher G.]

Nico, indeed, that looks like a bug.

I will take a look and fix it in the effected versions.

On a positive note, all of the internals of CrsGraph and CrsMatrix are being re-written from scratch, so this bug has likely been eliminated in my working version of the dev branch. (Disclaimer: by the doctrine of double jeopardy, if I independently write the same bug twice, it is allowed to live on as a feature.)

Which version of Trilinos/Tpetra are you using?

Chris


On 8/2/10 4:26 PM, "Nico Schlömer" <nico.schloemer at ua.ac.be> wrote:

Hi all,

I just noticed an oddity about the dynamic profile of a Tpetra::CrsGraph.
I'd have expected that, when using a dynamic profile (which is the
default), one can just insert as many indices as one wants in each row,
independent of the maxNumEntriesPerRow argument of the graph constructor.
As I can't tell beforehand what the maximum number of entries per row will
be, I generically set this value to 0. This worked out fine with
Epetra_CrsGraph.

In Tpetra::CrsGraph, inserting one set of indices is never a problem;
inserting a second set in the same row, though, blows away some of the
indices previously inserted. If maxNumEntriesPerRow is set to the correct
number of entries per row, things work out fine.

A minimal example code is attached to this mail. The output I get is
===================== *snip* =====================
The graph after the *first* insertion:
G[ 0 , 0 ]
G[ 0 , 1 ]
G[ 0 , 2 ]


The graph after the *second* insertion:
G[ 0 , -1572835640 ]
G[ 0 , 32515 ]
G[ 0 , -1572835640 ]
G[ 0 , 0 ]
G[ 0 , 3 ]
G[ 0 , 4 ]


The graph after fillComplete:
G[ 0 , -1572835640 ]
G[ 0 , 0 ]
G[ 0 , 3 ]
G[ 0 , 4 ]
G[ 0 , 32515 ]
===================== *snap* =====================

I worked around this now by setting maxNumEntriesPerRow=N, but that's not
very pretty.

Cheers,
Nico