[Trilinos-Users] Question on Epetra_BlockMap with variable element length

[Littlewood, David John]

Mike,

I dug around a bit for the exception that was being thrown when an element has zero length.  The exception is thrown in the Epetra_BlockMap constructor where the entries in the ElementSizeList are explicitly checked to make sure they are not <= 0.  I changed this to check for < 0 and the simple test I was looking at passed.  Could it be possible that the only required change is to switch the check from 'ElementSizeList[i] <= 0' to 'ElementSizeList[i] < 0' ?

I don't have any experience with Epetra_CrsGraph, but I took a quick look at the documentation.  It looks to me that Epetra_CrsGraph would work for storing connectivity, but in our case we have "peridynamic bond data" that we need to store as well.  There is a bond associated with each neighbor of a given node, and this bond could have an arbitrary set of constitutive data attached to it (scalars).  An Epetra_MultiVector works great except for the little glitch we're discussing; I can allocate the number of vectors in the multivector to the number of bond data associated with a given constitutive model, and I can allocate space for an arbitrary number of bonds for each node.

I'll e-mail you directly and send you a little test code I put together.

Thanks,
Dave


On 1/28/11 8:24 AM, "Heroux, Michael A" <maherou at sandia.gov> wrote:

Dave,

A thought I had was, why not use Epetra_CrsGraph to encode this information?  This class is specifically designed to encode edge information for each node, and it can handle zero edges very well.  In fact, I think your use of BlockMap, might be exactly what CrsGraph is meant to support.

Mike


On 1/27/11 6:02 PM, "Michael Heroux" <maherou at sandia.gov> wrote:

Dave,

It is also possible to push through support for this in BlockMap.  We would have to determine its impact.  Your unintended use of blockmap is interesting.  Would you be willing to look at the memory errors you are encountering?

Mike


On 1/27/11 5:53 PM, "Littlewood, David John" <djlittl at sandia.gov> wrote:

Mike,

Thanks for your nearly instantaneous response!

Your suggestion makes sense, but unfortunately it is not compatible with other parts of the code that operate directly on the underlying arrays of doubles and assume that there will be no entries in the array for points with no neighbors.  This perhaps points to shortcomings in our code that have nothing to do with Epetra, we'll have to review what we're doing there.

For the time being I'm just going to omit points with no neighbors when constructing the Epetra_BlockMap for the storage of neighbor-related data.  This works but has the unfortunate consequence of making the number of entries in the map for bond data different from the number of entries in the map for point-wise data.  Not a huge disaster, but the bookkeeping becomes a bit ugly.

Best Regards,
Dave


On 1/27/11 11:23 AM, "Heroux, Mike" <MHeroux at CSBSJU.EDU> wrote:

Dave,

BlockMap was not designed to handle a block entry size of 0.  I am not sure what would be required to do so.  Might it be possible to keep the ID of the self, then check the ID list and ignore the self ID?

This would allow you to proceed.

Mike


On 1/27/11 12:11 PM, "Littlewood, David John" <djlittl at sandia.gov> wrote:

Greetings,

When constructing an Epetra_BlockMap with a variable element length, is it possible to have an element with length zero?

I am using a map to store the list of neighbors in a peridynamics simulation, and it is possible to have zero neighbors.  It appears that one cannot construct an Epetra_BlockMap with an element that has zero length (throws exception).

Thanks,
Dave

________________________________
_______________________________________________
Trilinos-Users mailing list
Trilinos-Users at software.sandia.gov
http://software.sandia.gov/mailman/listinfo/trilinos-users





-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://software.sandia.gov/pipermail/trilinos-users/attachments/20110128/71e77a8c/attachment.html