Zoltan 2 Version 0.5
for very large files, each process reads in part of the file
Zoltan1 mtx and mtxp files
Block partitioning uses one weight only
Block partitioning assumes one part per process.
check for memory allocation failures
The metrics come out really bad. Is it an error in algorithm or in metrics.
timing and memory usage profiling and debug messages
catch errors and pass back
write the rcb tree back to the solution
for "repartition", start with the tree in the solution
work on performance issues. Some of the global communication can probably be consolidated into fewer messages.
Global identifiers should be optional. If the user gives us gids in the input adapter, we will include them in the solution.
Is there any reason to specify coordinates for vector elements?
a separate simpler function when weightDim <= 1
During the first global comm, ensure all procs have same values for cutDim and fractionLeft.
We don't really need global Ids. They should be optional
Migration doesn't move weights. Should it?
test for global IDs that are std::pair<T1, T2>
we require that user's gid_ts have base zero if we are to use them as consecutive gno_ts. This can be fixed if needed. We are not getting the efficiency advantage of using the user's gids simply because those IDs do not have base 0. We can add a flag about base 0 being required, and then map only if base 0 is required.
write an example where user's global ID is a C-struct containing
fix this note regarding gid_t Developer note: By convention we use
gid_t as the users global ID data type and
gno_t as the data type used internally by Zoltan2.
Create BasicCrsMatrixInput subclass
Do we want to require input adapters to give us the global number of rows, columns etc? We can figure that out.
This is a row-oriented matrix. Do we need a column-oriented matrix? In particular - we assumed coordinates are for rows.
If the user can tell us there are no diagonal entries in a square matrix, it can save time if we have to remove them for the algorithm. Should we have a set method in subclasses for setMatrixHasDiagonalEntries yes, no and maybe?
include pointers to examples
follow ordering with partitioning
include pointers to examples
repartition given an initial solution
follow partitioning with global or local ordering
allow unsetting of part sizes by passing in null pointers
add a parameter by which user tells us there are no self edges to be removed.
Problem computes metrics using the Solution. Should Solution have a pointer to the metrics, since it may persist after the Problem is gone?
save an RCB tree, so it can be used in repartitioning, and supplied to the caller.
doxyfy the comments in this file.
For some problems it will be necessary to build the Model again in order to compute metrics. For now we don't have any problems like that.
write a unit test for this class
test for memory alloc failure when we resize a vector
we assume FillComplete has been called. Should we support objects that are not FillCompleted.
we assume FillComplete has been called. We should support objects that are not FillCompleted.