: This class also manages the RDMA setup requests, although it could also assume the responsibility for processing the ack msg that arrives in GSpace to complete an RDMA handshake.

Member cp::ortho::orthoConfig::isGenWave

: Used in ortho only for shifting step number by 1. Eliminate

Member cp::paircalc::MessageDataCollator< msgType, dataType >::minSender

: A better way to accomplish that leaves the collator class less rigid might be better

Member cp::paircalc::MessageDataCollator< msgType, dataType >::operator() (msgType *msg)

: Define a PUP method

: Debate if some kind of check is needed to ensure that the message received is the correct iteration etc. For e.g, if the message defined a uniqID() method that would return a unique tag indicating the group the message belonged to, then all messages that belonged to this group could be buffered together. uniqID() could return iteration number if messages from a single iteration are to be grouped, or the sender ID if messages from a single sender are to be grouped together. Other possible scenarios where it is possible to receive messages from separate collation groups might occur.

Member CP_State_ParticlePlane::initKVectors ()

: Made this public to remove friendship. Check if this can go back to being private.

Member CP_State_ParticlePlane::sendToEesRPP ()

: realPP_proxy is initialized in initKVectors only if nloc_on is true. Should we check the same here too?

Member GSpaceDriver::init ()

: When is the earliest that you can do this? Can we do this upon construction? Probably not, as we have no guarantee that UsfCompProxy is up and ready.

Member init_rho_chares (CPcharmParaInfo *sim, UberCollection thisInstance)

: valgrind complains of a tiny memleak here. Check if callbacks get destroyed properly.

Member INVSQR_TOLERANCE

: Temporary, till Ortho classes live within namespace ortho

Member paircalcInputMsg::blkSize

: blkSize is used in paircalc only for dumping data files in the backward path. Also, it cannot be retreived when usng RDMA. Is there an alternative?

Member paircalcInputMsg::points

: Message data, should slowly be hidden from the world. The sender and end user could become friends

Member PairCalculator::acceptOrthoT (multiplyResultMsg *msg)

Document this after talking with EB. Shouldnt it be an error if orthoX/Y > maxorthostateindex?

Member PairCalculator::bwbarrier (CkReductionMsg *msg)

: Comments says this is a minimization only hack! Figure out!

Member PairCalculator::cleanupAfterBWPath ()

: is this redundant? isnt othernewData always allocated?

Member PairCalculator::multiplyResult (multiplyResultMsg *msg)

: It appears actionType = PSIV will not enter multiplyResult. Needs to be verified as lots of conditions here chk for actionType==PSIV

Member PairCalculator::PairCalculator (CProxy_InputDataHandler< CollatorType, CollatorType > inProxy, const pc::pcConfig _cfg)

: This is a hack to ensure that phantoms which get matrix blocks

Member PairCalculator::pup (PUP::er &)

: Fix this to allocate or grab a msgLeft and msgRight. inDataLeft/Right is no longer allocated directly

: Fix this to pack msgLeft and msgRight directly. inDataLeft/Right is no longer allocated directly msgLeft and msgRight will already be packed and available as msgs. They just wont be packed together with the rest of paircalc. Is there any way we could simply hand the msgs back to charm and ask it to deliver them to me after I am done migrating.? Or am I talking crap? if(existsLeft) p(inDataLeft, numExpectedX * numPoints * 2); if(existsRight) p(inDataRight, numExpectedY* numPoints * 2);

Member PairCalculator::sendTiles (bool flag_dp)

: The only use of flag_dp has been commented out. Check if this argument is still needed, else weed it out.