Zoltan 2 Version 0.5
Todo List

File StridedData.cpp
Some of the tests require that you look at the output to know if they did the right thing. Enhance this so the test itself determines correctness.

Class UserInputForTests

for very large files, each process reads in part of the file

Zoltan1 mtx and mtxp files

File XpetraCrsGraphInput.cpp
add weights and coordinates

File XpetraCrsMatrixInput.cpp
test with geometric row coordinates.

File XpetraMultiVectorInput.cpp
test with weights

File XpetraVectorInput.cpp
add test with weights

Member Zoltan2::AlgBlock (const RCP< const Environment > &env, const RCP< Comm< int > > &problemComm, const RCP< const IdentifierModel< typename Adapter::base_adapter_t > > &ids, RCP< PartitioningSolution< Adapter > > &solution)

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.

Member Zoltan2::AlgRCB (const RCP< const Environment > &env, RCP< Comm< int > > &problemComm, const RCP< const CoordinateModel< typename Adapter::base_adapter_t > > &coords, RCP< PartitioningSolution< Adapter > > &solution)

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.

Class Zoltan2::BasicVectorInput< User >

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?

Member Zoltan2::BSPfindCut (const RCP< const Environment > &env, const RCP< Comm< int > > &comm, const std::bitset< NUM_RCB_PARAMS > &params, int numTestCuts, typename mvector_t::scalar_type tolerance, int cutDim, int coordDim, const RCP< mvector_t > &vectors, ArrayView< typename mvector_t::local_ordinal_type > index, ArrayView< double > fractionLeft, ArrayView< bool > uniformWeights, typename mvector_t::scalar_type coordGlobalMin, typename mvector_t::scalar_type coordGlobalMax, typename mvector_t::scalar_type &cutValue, ArrayView< unsigned char > lrFlags, typename mvector_t::scalar_type &totalWeightLeft, typename mvector_t::scalar_type &totalWeightRight, typename mvector_t::local_ordinal_type &localCountLeft, typename mvector_t::scalar_type &imbalance)

a separate simpler function when weightDim <= 1

During the first global comm, ensure all procs have same values for cutDim and fractionLeft.

Class Zoltan2::CoordinateInput< User >

We don't really need global Ids. They should be optional

Migration doesn't move weights. Should it?

Class Zoltan2::DebugManager
For nightly testing, add a build for -DZ2_OMIT_ALL_STATUS_MESSAGES.

Class Zoltan2::GraphInput< User >
Create BasicCrsGraphInput subclass.

Member Zoltan2::GraphModel< Adapter >::GraphModel (const Adapter *ia, const RCP< const Environment > &env, const RCP< const Comm< int > > &comm, modelFlag_t &modelFlags)
document the model flags that might be set

Class Zoltan2::IdentifierMap< User >

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.

Member Zoltan2::IdentifierMap< User >::gidTranslate (ArrayView< gid_t > gid, ArrayView< gno_t > gno, TranslationType tt) const
If the gnos need to be translated to gids, check first to see if the gnos are in their original order. If so, we can save memory by returning an arrayview of the gids.

Class Zoltan2::IdentifierModel< Adapter >
Add instantiations for GraphInput, MeshInput

Class Zoltan2::IdentifierTraits< T >

write an example where user's global ID is a C-struct containing i and j indices.

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.

Class Zoltan2::InputAdapter< User >
Add add a MeshInput adapter

Class Zoltan2::InputTraits< User >

Class Zoltan2::MatrixInput< User >

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?

Member Zoltan2::MetricValues< scalar_t >::printHeader (ostream &os)
This method is static and the header is the same for every type of MetricValues object. But when we add metrics for graph and hypergraph, we may need to look at which type of metric are set in order to decide what header to print. So it would be a member method instead of static.

Class Zoltan2::Model< Adapter >
Add HypergraphModel, CoordinateModel

Member Zoltan2::normedPartWeights (const RCP< const Environment > &env, int numberOfParts, const ArrayView< const pnum_t > &parts, const ArrayView< StridedData< lno_t, scalar_t > > &vwgts, multiCriteriaNorm mcNorm, scalar_t *weights)
- Zoltan_norm() in Zoltan may scale the weight. Do we ever need this?

Member Zoltan2::objectMetrics (const RCP< const Environment > &env, const RCP< const Comm< int > > &comm, multiCriteriaNorm mcNorm, const RCP< const Adapter > &ia, const RCP< const PartitioningSolution< Adapter > > &solution, partId_t &numParts, partId_t &numNonemptyParts, ArrayRCP< MetricValues< typename Adapter::scalar_t > > &metrics)
check that part sizes sum to one if we're doing COMPLEX_ASSERTION

Class Zoltan2::OrderingProblem< Adapter >

include pointers to examples

follow ordering with partitioning

Class Zoltan2::OrderingSolution< gid_t, lno_t >

Class Zoltan2::PartitioningProblem< Adapter >

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.

hierarchical partitioning

Member Zoltan2::PartitioningProblem< Adapter >::setPartSizes (int len, partId_t *partIds, scalar_t *partSizes, bool makeCopy=true)
A user should be able to give us one set of part sizes that applies to all weight dimensions. Right now for each weight dimension that does not have uniform part sizes, the user has to give us the part sizes once for each.

Class Zoltan2::PartitioningSolution< Adapter >

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.

Member Zoltan2::PartitioningSolution< Adapter >::convertSolutionToImportList (int numExtra, ArrayRCP< Extra > &xtraInfo, ArrayRCP< typename Adapter::gid_t > &imports, ArrayRCP< Extra > &newXtraInfo) const
A version which takes the export part numbers and returns the import part numbers in addition to the global IDs. Although this can be done with the extra data, it might be better to do it explicitly.

Member Zoltan2::PartitioningSolution< Adapter >::getCriteriaPartSize (int idx, partId_t part) const
It would be useful to algorithms to get the sum of part sizes from a to b, or the sum or a list of parts.

Member Zoltan2::PartitioningSolution< Adapter >::getLocalFractionOfPart () const
More useful to get number of processes owning part? Or not useful at all - remove this?

Member Zoltan2::PartitioningSolution< Adapter >::PartitioningSolution (RCP< const Environment > &env, RCP< const Comm< int > > &comm, RCP< const IdentifierMap< user_t > > &idMap, int userWeightDim, ArrayView< ArrayRCP< partId_t > > reqPartIds, ArrayView< ArrayRCP< scalar_t > > reqPartSizes)
handle errors that may arise - like duplicate part numbers

Class Zoltan2::PartitioningSolutionQuality< Adapter >

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

Member Zoltan2::testCoordinatesOnRightBoundary (const RCP< const Environment > &env, const RCP< Comm< int > > &comm, scalar_t totalWeightLeft, scalar_t targetLeftScalar, int cutLocation, ArrayView< scalar_t > localSums, ArrayView< scalar_t > globalSums, ArrayView< lno_t > index, ArrayView< StridedData< lno_t, scalar_t > > weights, multiCriteriaNorm mcnorm, ArrayView< unsigned char > lrFlags, scalar_t &globalWeightMovedRight)
document parameters

Class Zoltan2::VectorInput< User >
We can make global Ids optional. We don't need them.

Class Zoltan2::XpetraCrsGraphInput< User >

test for memory alloc failure when we resize a vector

we assume FillComplete has been called. Should we support objects that are not FillCompleted.

Class Zoltan2::XpetraCrsMatrixInput< User >

we assume FillComplete has been called. We should support objects that are not FillCompleted.

add RowMatrix

File Zoltan2_IO.cpp
write a solution and its model to an exodus file

File Zoltan2_Metric.hpp
Add graph and hypergraph metrics.

File Zoltan2_Solution.hpp
The Solution classes are part of the API. This is problematic right now - they use many internal classes and are used by Problems and algorithms. Maybe there should be a SolutionAPI object within the Solution which is the visible part of the Solution. The source for this class could be in the src/input directory. This is where the input adapters which use that part of the solution reside.

File Zoltan2_Standards.hpp
Should we allow data types for part ID to be set as cmake configure options? Part ID lists in the PartitioningSolution are of length "number of objects". If part ID could be short or int, we save significant memory. For now - typedef'd to int so it is easy to change. It seems data type for proc should be int - since it is int in the rest of Trilinos.

File Zoltan2_Util.hpp
Should each class of utility functions be in a separate source file instead of having a source file with the unhelpful name of Util?