[Developers] eliminating scheduling ambiguities

[David Rideout]

I propose to modify the specification of Cactus slightly, to state that the 
relative order of scheduled routines, beyond that specified by before & after 
requests in thorns' schedule.ccl, is fixed in some arbitrary way (say 
alphabetically).  I believe that currently it is unspecified.

The reason for this proposal is described in detail below.  This is a request 
for comment.


Currently the Cactus flesh computes a 'topological sort' of scheduled 
routines, based upon what thorns request in their schedule.ccl.  This simply 
means some linear ordering of the routines which is compatible with all 
before and after requests in the schedule.ccl files.  (In the language of 
partial order relations, the before / after requests impose a partial order 
on the set of scheduled routines, and the flesh computes a linear extension 
of this order.)

In general there will be many routines whose relative order is unspecified by 
before / after requests.  e.g.

schedule routineA in CCTK_EVOL ...

schedule routineB in CCTK_EVOL ...

Now consider a computation which uses a pseudorandom number generator (RNG).  
This is a (deterministic) function which, each time it is called, returns an 
approximately random number, based upon its previous value.  The initial 
value is initialized as a seed.  Thus for a given seed, the RNG produces a 
fixed sequence of pseudorandom numbers.

Now a problem arises, as follows.  If we imagine fixing the seed in a 
parameter file, then one may expect to get a fixed unique output from that 
parameter file.  Such behavior is needed for a testsuite, for example.  
However, two different builds of Cactus may differ in the relative order of 
routineA and routineB.  If both of these routines contain calls to the RNG, 
then the output from Cactus will differ, even though each build runs the same 
parameter file.

A simple fix is to (arbitrarily) specify this unspecified aspect of the 
scheduler as described above.  Note that the actual choice of ordering makes 
no difference, it only matters that the order of routines is fixed for a 
given collection of compiled thorns and parameter settings.

One can dream up many more complicated solutions, but I believe this simple 
resolution can be extremely easy to implement (e.g. just by sorting the 
thornlist before processing!).

Thanks,
David