[Trilinos-Users] do{Ex,Im}port const'ness

[Baker, Christopher G.]

Dear Nico,

It looks like the Tpetra::DistObject class, and therefore the derived Tpetra::MultiVector class, is const-correct with regards to the doImport() and doExport() methods. What is incorrect, and leading to the confusion here, is the documentation and labeling of arguments to these methods.

There are four cases: whether to call doImport() or doExport(), and whether the distribution information is contained in an Import or Export object. Two by two is four (even in Tpetra.)  Two of these are directly needed by the typical sparse-matvec use case, while the other two come via the reverse distribution scenarios (transpose sparse-matvec).

In all four cases, the object (*this) where the import/export method is called, is the destination of the operation, and thus the method is non-const. Likewise, the input object is the source of the transport operation, and is therefore const. This latter point is where the documentation is incorrect; in both doExport() methods, the input object is incorrectly labeled "dest", though it is treated correctly (i.e., as the source) by the implementation. The distinction between Importing and Exporting (and Import and Export containers) is to allow these operation to be reversed; it can get a little confusing deciding which to do initially, or deciding which does what (hence, my error in the documentation).

I will update the development and 10.0 release branches; this change should propagate in the online documentation immediately.

Regarding the follow-up question:
how to export data from a distributed const Tpetra object onto another one.
This is done in Tpetra in the same way it is done in Epetra. A const distributed object we will call SrcObj is to have data exported to a non-const distributed object we will call DestObj. Both of these objects have data distributed according to a Map; both of these objects inherit from DistObject. We will call the former SrcMap and the latter DestMap; these can be queried from the objects. We will create an Import object from the Map objects, which will capture the information we need to efficiently perform the communication. We will maintain this Import object, and use it for the doImport() operations on these objects (or any other objects with described by equivalent Map objects). Here is some code illustrating this (we use a typedef for Map for clarity here):
typedef Map<LocalOrdinal, GlobalOrdinal> MAP;
// Inputs:
//   const DistObject< Packet, LocalOrdinal, GlobalOrdinal >  SrcObj;
//         DistObject< Packet, LocalOrdinal, GlobalOrdinal > DestObj;
RCP<const MAP> DestMap = DestObj->getMap(),
                SrcMap =  SrcObj->getMap();
// Import object analyzes the maps and determines a communication pattern for the operations to follow
Import<LocalOrdinal, GlobalOrdinal> importer(SrcMap, DestMap);
...
// communicate elements contained in DestMap from SrcObj to DestObj, replacing the data in DestObj before the operation
DestObj.doImport(SrcObj, importer, Tpetra::REPLACE);
...

The calls to getMap() are const. The call DestObj->doImport(srcObj,...) respects the const on srcObj.

I'm 99% sure this is correct :)
Attached devs will correct me if I'm wrong.

Please email if you have any other questions.

Chris

On 11/21/09 3:50 PM, "Schlömer Nico" <nico.schloemer at ua.ac.be> wrote:

Hi,

I'm trying to write a small routine that puts all data onto one processor for I/O, but I'm running a bit into const problems here.
I realize that I probably don't fully understand why the

doExport
http://trilinos.sandia.gov/packages/docs/r10.0/packages/tpetra/doc/html/classTpetra_1_1DistObject.html#cc1e5a6b30b441ef487d21d577b9828b

and

doImport
http://trilinos.sandia.gov/packages/docs/r10.0/packages/tpetra/doc/html/classTpetra_1_1DistObject.html#94806d93edd334c8bf2b07df61e75fde

methods, respectively, aren't const on their source.

Is that something that's been forgotten?

Otherwise I'd be very interested to know how to export data from a distributed const Tpetra object onto another one.

Cheers,
Nico