Class Zoltan2::EvaluatePartition< Adapter >

write a unit test for this class

test with geometric row coordinates.

add weights and coordinates

test with geometric row coordinates.

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

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.

Member Zoltan2::normedPartWeights (const RCP< const Environment > &env, part_t numberOfParts, const ArrayView< const part_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?

File Zoltan2_IO.cpp

write a solution and its model to an exodus file

Member Zoltan2::imbalanceMetrics (const RCP< const Environment > &env, const RCP< const Comm< int > > &comm, multiCriteriaNorm mcNorm, const Adapter *ia, const PartitioningSolution< Adapter > *solution, const ArrayView< const typename Adapter::part_t > &partArray, const RCP< const GraphModel< typename Adapter::base_adapter_t > > &graphModel, typename Adapter::part_t &numExistingParts, typename Adapter::part_t &numNonemptyParts, ArrayRCP< RCP< BaseClassMetrics< typename Adapter::scalar_t > > > &metrics)

check that part sizes sum to one if we're doing COMPLEX_ASSERTION

File XpetraMultiVectorInput.cpp

test with weights

Class Zoltan2::EvaluatePartition< 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.

Class Zoltan2::EvaluateMapping< Adapter, MachineRep >

write a unit test for this class

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.

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.

Member Zoltan2::PartitioningSolution< Adapter >::getCriteriaPartSize (int idx, part_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 (const RCP< const Environment > &env, const RCP< const Comm< int > > &comm, int nUserWeights, ArrayView< ArrayRCP< part_t > > reqPartIds, ArrayView< ArrayRCP< scalar_t > > reqPartSizes, const RCP< Algorithm< Adapter > > &algorithm=Teuchos::null)

handle errors that may arise - like duplicate part numbers

Class Zoltan2::PartitioningSolution< Adapter >

doxyfy the comments in this file.

save an RCB tree, so it can be used in repartitioning, and supplied to the caller.

Member testFromDataFile (const RCP< const Teuchos::Comm< int > > &comm, int nParts, string &filename, bool doRemap)

check the solution, visualize it somehow

write some examples that don't use teuchos

error handling

File rcbPerformanceZ1.cpp

get the imbalance when done

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?

Member USERINPUT_FILE_FORMATS

Zoltan1 mtx and mtxp files

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

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.

Member SMALL_NUMBER_OF_ROWS

Address the TODOs in the code below.

test with GraphAdapter: add testGraphAdapter which is like testAdapter except is uses GraphAdapter queries and it may have edges weights.

test all methods of GraphModel

File XpetraVectorInput.cpp

add test with weights

Class Zoltan2::VectorAdapter< User >

We can make global Ids optional. We don't need them.

Class Zoltan2::ColoringProblem< Adapter >

- Currently, only serial and shared-memory coloring are supported.

- Should Problems and Solution have interfaces for returning views and for returning RCPs? Or just one? At a minimum, we should have the word "View" in function names that return views.

include pointers to examples

Class Zoltan2::Model< Adapter >

Add HypergraphModel, CoordinateModel

Member Zoltan2::HyperGraphModel< Adapter >::HyperGraphModel (const RCP< const MatrixAdapter< user_t, userCoord_t > > &ia, const RCP< const Environment > &env, const RCP< const Comm< int > > &comm, modelFlag_t &modelFlags, CentricView view)

document the model flags that might be set

Member Zoltan2::GraphModel< Adapter >::GraphModel (const RCP< const MatrixAdapter< user_t, userCoord_t > > &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::XpetraCrsMatrixAdapter< User, UserCoord >

add RowMatrix

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

Class Zoltan2::XpetraCrsGraphAdapter< User, UserCoord >

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

test for memory alloc failure when we resize a vector

Class Zoltan2::MatrixPartitioningProblem< Adapter >

include pointers to examples

Class Zoltan2::TpetraRowGraphAdapter< User, UserCoord >

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

test for memory alloc failure when we resize a vector

Class Zoltan2::MatrixAdapter< User, UserCoord >

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?

This is a row-oriented matrix. Do we need a column-oriented matrix? In particular - we assumed coordinates are for rows.

Do we want to require adapters to give us the global number of rows, columns etc? We can figure that out.

Create BasicCrsMatrixAdapter subclass

Class Zoltan2::DebugManager

For nightly testing, add a build for -DZ2_OMIT_ALL_STATUS_MESSAGES.

Class Zoltan2::AlgBlock< Adapter >

The metrics come out really bad. Is it an error in algorithm or in metrics.

check for memory allocation failures

Class Zoltan2::OrderingProblem< Adapter >

follow ordering with partitioning

Member Zoltan2::PartitioningProblem< Adapter >::setPartSizes (int len, part_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 indices. Right now for each weight index that does not have uniform part sizes, the user has to give us the part sizes once for each.

Class Zoltan2::PartitioningProblem< Adapter >

- Should Problems and Solution have interfaces for returning views and for returning RCPs? Or just one? At a minimum, we should have the word "View" in function names that return views.

add a parameter by which user tells us there are no self edges to be removed.

allow unsetting of part sizes by passing in null pointers

follow partitioning with global or local ordering

repartition given an initial solution

hierarchical partitioning

include pointers to examples

Class Zoltan2::OrderingProblem< Adapter >

- Should Problems and Solution have interfaces for returning views and for returning RCPs? Or just one? At a minimum, we should have the word "View" in function names that return views.

Class Zoltan2::AlgBlock< Adapter >

Block partitioning uses one weight only

Class Zoltan2::OrderingProblem< Adapter >

include pointers to examples

Class Zoltan2::MatrixPartitioningSolution< Adapter >

doxyfy the comments in this file.

save an RCB tree, so it can be used in repartitioning, and supplied to the caller.

Problem computes metrics using the Solution. Should Solution have a pointer to the metrics, since it may persist after the Problem is gone?

Class Zoltan2::MatrixPartitioningProblem< Adapter >

- Should Problems and Solution have interfaces for returning views and for returning RCPs? Or just one? At a minimum, we should have the word "View" in function names that return views.

add a parameter by which user tells us there are no self edges to be removed.

allow unsetting of part sizes by passing in null pointers

follow partitioning with global or local ordering

repartition given an initial solution