[elemental-dev] New distribution added

[Jack Poulson]

Dear all,

Over the last few days a new distribution was added into the DistMatrix class in order to facilitate I/O to and from a single process. This was done for two reasons:

   1) The routines in the include/io/ folder tend to involve collecting data to a single process.

   2) It has been a common question on the list (and in private communications) how to distribute sequential data and how to collect distributed data on a single process.

This is all quite easy now with the [o ,o ] distribution, which is essentially the same as [* ,* ], but with the data stored on a single 'root' process instead of on every process. Please see the following example driver to see its usage:
    https://github.com/poulson/Elemental/blob/master/examples/lapack-like/HermitianEigFromSequential.cpp

Additionally, during the process of implementing said distribution, the DistMatrix constructors were significantly simplified due to a subtle bug being noticed in their copy constructors which involved redistributions from matrices where only subsets of the entire team stored data, e.g., [MC,MR] <- [MD,* ]. The overly complicated DistMatrix initialization lists are now completely gone.

Also, as part of the debugging process of adding in [o ,o ], I noticed that the call-stack manipulation routine ReportException was constructing an output stream for the exception message, but it wasn't actually forwarding it to std::cout. Thus, when an exception was thrown in debug mode, the call-stack was being printed but not the error message. This effects release 0.80 and is now fixed in the development branch.

Two more small details:

    1) All I/O routines, e.g., Print and Write, are no longer member functions of (Dist)Matrix and now reside in the io/ folder.

    2) A bug was fixed in the examples/lapack-like/ID.cpp driver

I am considering releasing these modifications as part of a version labeled 0.80-p1, though I have received a complaint that I should simply up the version number instead of bothering with patch numbers. Any thoughts?

Jack

[Jack Poulson]

One more item which I should have included in my last email: due to expanding Elemental's functionality, the SWIG wrappers are now significantly larger and are exhausting all of my laptop's available memory during compilation. I expect that I will not be the only one effected, so finding some means of trimming down the amount of generated code may be prudent.

Jack

[Michael C. Grant]

It may help for me to break out the Matrix subclasses I created to handle the NumPy/Elemental integration. In fact, what I want to is modify Elemental itself to provide more built-in support for different types of local matrices---so for example, Matrix would actually use NumPy's own matrix allocation and resizing functions instead of its own when in Python.

I also suspect that we can break apart the single monolithic elem.i file into multiple files, but it's going to take some fiddling.

On Jun 16, 2013, at 1:17 PM, Jack Poulson <jack.p...@gmail.com>

 wrote:

[Jack Poulson]

Since we've already modified the source code a bit to accommodate a few problems with SWIG's parser, I don't have any problem with directly adding in NumPy support, especially if it decreases the SWIG compilation cost.

Modifying the DistMatrix class should also be a bit more straightforward now that the previous overly complicated constructor code has been removed.

Jack