startup

The Main of CPAIMD, it calls all the init functions. More...

Functions
void	InstanceController::doneInit (CkReductionMsg *msg)

Detailed Description

The Main of CPAIMD, it calls all the init functions.

Parallel Startup Phases:

1. Phase 0 is kicked off by reaching the end of main. This turns execution completely over to the Charm++ scheduler, at which point it will process the object constructor messages that we triggered in the proxy creation in main. Object construction will occur in this order + all readonlies will be initialized. + all groups will be constructed + all arrays will be constructed

   The ordering within those phases is non-deterministic, so we don't expect to have control over the ordering of chare array construction. The upshot of this is that in order to safely make array sections we wait until the objects are constructed and then call a second phase of initialization. In practice this means that arrays will contribute to reductions during construction and the completion of those reductions will trigger a chain of section creation which will eventually feed back into a reduction that reports to the global startup phase ordering in InstanceController.

2. Phase 2 and 3 are automatically triggered during the construction process. These phases are ortho constructing proxies to sections of the paircalculators. In each case they construct a section and send a message on that section to its elements to initialize a cookie. Receipt of that cookie increments a counter and when each PC element has received all the cookies it expects, it contributes to a reduction which reports to InstanceController::doneInit(). There is a phase for symmetric and asymmetric calculator, they could complete in either order.
3. Phase 4 triggers the post construction initialization of section proxies and cache registrations in RhoReal RhoG RhoGHartExt. The big ticket item here is the sections of RealSpace made by RhoReal. These operate in the previously described fashion wherein you make a section, initialize the cookies with a dummy message and report on completion via a reduction along the section. When realspace has received as many cookies as there are rhoreal subplanes, it contributes to a reduction reporting to InstanceController::doneInit.
4. Phase 5 is triggered by the completion of the RS sections. When EES is enabled, phase 5 will launch the section construction and registration process in RealParticlePlane. The coalesced completion of eesCache, enlSection, and planeRedSection initialization contributes to a single reduction reporting to InstanceController::doneInit. This phase always triggers the loading and multicasting of the gspace state data from the statefiles. When all elements of gspace are initialized with that data they contribute to a reduction which reports to InstanceController::doneInit.
5. Phase 6 happens only if EES is enabled, it broadcasts registrationDone to all RealParticlePlane elements.
6. Phase 7 (or 6 if no realparticleplane) means that all initialization is complete and startup is effectively over. Control is then turned over to the gSpaceDriver::startControl. Some chares will do a little local first iteration initialization after this. Semantically it should now be safe to engage in any operation as the previous phases should have taken care of any synchronized initialization issues.

Sequential startup within Main

Startup parses the physics simulation input, parses the parallel driver config file, constructs chares, computes chare placement, coordinates the launch of chares in parallel, the reading of input, and initiates computation when everything is initialized and ready to start timestepping.

1) Read PINY config and the rest of the physical system parameter files to set the constants which determine problem size. These are stored in the CPcharmParaInfo class object named sim (for simulation).

2) Read the cpaimd_config file which determines parallel decomposition. This is mostly stored in the config object, but a bunch of readonly globals also get instantiated with this information.

3) Topological map setup : we initialize several structures which will be useful for using network topology for more optimal chare placement

4) Parallel Object Proxy Creation We loop through a four deep nested launcher by integral, kpoint, temper, and spin to construct the appropriate chare arrays for each instance.

• We setup the State chares (GS, RS, PP, RPP) along with their maps.
• We setup the Paircalc and ortho chares (SymPC, AsymmPC, ortho, CLA)
• We setup the Density chares (rho, rho*hart)
• We setup the non-local chares for Ees (if configured)

In each case we are constructing the proxy and calling for parallel object construction of the elements in each of those arrays. Note that while we are inside Main the chares for PE 0 will be constructed inline in program order. No assumptions should be made about chares constructed on other PEs until we exit main and pass control to the Charm++ scheduler for parallel launch.