Improved scheduling - Revision history

Bentivegna: /* Whiteboard snapshots */

2011-11-02T09:04:25Z

‎Whiteboard snapshots

Bentivegna: /* Whiteboard snapshots */

2011-11-02T08:49:31Z

‎Whiteboard snapshots

Bentivegna: /* Whiteboard snapshots */

2011-11-02T08:48:13Z

‎Whiteboard snapshots

Hinder: /* Possible plan */

2011-11-02T08:16:19Z

‎Possible plan

Hinder: /* Possible plan */

2011-11-02T08:15:16Z

‎Possible plan

Hinder: /* Possible plan */

2011-11-02T08:13:15Z

‎Possible plan

194.94.224.254 at 08:05, 2 November 2011

2011-11-02T08:05:50Z

Hinder: /* Work plan */

2011-11-01T17:18:37Z

‎Work plan

Hinder: /* Issues/thoughts */

2011-11-01T15:47:20Z

‎Issues/thoughts

Hinder: /* Issues/thoughts */

2011-11-01T15:16:31Z

‎Issues/thoughts

←Older revision		Revision as of 09:04, 2 November 2011
Line 157:		Line 157:

	====Whiteboard snapshots====		====Whiteboard snapshots====
		+	[[Image:wb0.jpg\|thumb\|left\|Discussion on GPU and changes in the make system]]
		+
	[[Image:wb1.jpg\|thumb\|left\|Discussion on scheduling example]]		[[Image:wb1.jpg\|thumb\|left\|Discussion on scheduling example]]

←Older revision		Revision as of 08:49, 2 November 2011
Line 157:		Line 157:

	====Whiteboard snapshots====		====Whiteboard snapshots====
−	[[Image:wb1.jpg\|thumb]]	+	[[Image:wb1.jpg\|thumb\|left\|Discussion on scheduling example]]

←Older revision		Revision as of 08:48, 2 November 2011
Line 157:		Line 157:

	====Whiteboard snapshots====		====Whiteboard snapshots====
−	[[Image:wb1.jpg]]	+	[[Image:wb1.jpg\|thumb]]

←Older revision		Revision as of 08:16, 2 November 2011
Line 30:		Line 30:

	* Check that the schedule that is derived is the same as before (except where it was wrong or ambiguous before - Frank mentioned that he once tried to change Cactus to schedule functions in the reverse order where it is currently ambiguous, and this led to errors, so there are probably some thorns which do not correctly specify orderings).		* Check that the schedule that is derived is the same as before (except where it was wrong or ambiguous before - Frank mentioned that he once tried to change Cactus to schedule functions in the reverse order where it is currently ambiguous, and this led to errors, so there are probably some thorns which do not correctly specify orderings).
−
−	* Deprecate unneeded schedule groups and "before" and "after" and transition entirely to the new dependency-based scheduling (one year from now?)

	* Have both data-driven and current systems available at the same time. We probably will need elements of both in the end, and this makes compatibility much easier to handle. We can slowly transition different parts of the schedule to the new system where possible. We can check the two systems against each other as well.		* Have both data-driven and current systems available at the same time. We probably will need elements of both in the end, and this makes compatibility much easier to handle. We can slowly transition different parts of the schedule to the new system where possible. We can check the two systems against each other as well.

←Older revision		Revision as of 08:15, 2 November 2011
Line 32:		Line 32:

	* Deprecate unneeded schedule groups and "before" and "after" and transition entirely to the new dependency-based scheduling (one year from now?)		* Deprecate unneeded schedule groups and "before" and "after" and transition entirely to the new dependency-based scheduling (one year from now?)
		+
		+	* Have both data-driven and current systems available at the same time. We probably will need elements of both in the end, and this makes compatibility much easier to handle. We can slowly transition different parts of the schedule to the new system where possible. We can check the two systems against each other as well.

	====Issues/thoughts====		====Issues/thoughts====

@@ Line 17: / Line 17: @@
 * Define a semantics for accessing only parts of the domain, e.g. boundaries, symmetries. What domain parts should be supported? Should sync, prolongation, buffer zone prolongation, symmetries be applied automatically? Do we then just have interior, boundary, and everything? If so, note that interior | boundary != everything since we don't have an explicit notion for ghosts and buffer zones. Should there, in addition to a CCL syntax, be an API for declaring things at run-time? If so, should this API be more extensive than the CCL syntax? Probably best to write down, on a white board, the schedule for a parallel unigrid WaveToy with MoL.
-* Set up a sequence of functions in CCTK_INITIAL with dependency information between variables.  Make Carpet decide the scheduling order within CCTK_INITIAL based on these.  This could be possible in Cactus, by just adding the currently supported BEFORE and AFTER options to the schedule information based on the values of the READS and WRITES options.  Carpet/driver would then insert its own calls to so sync/prolongate etc, but the ordering wouldn't change.  Could provide a version of ScheduleTraverse which took a list of variables (or parts of variables) that need to be filled.  This would run a passed callback function as it currently does, but only on those functions which are needed to compute those variables.
+* Set up a sequence of functions in CCTK_INITIAL with dependency information between variables.  Make Carpet decide the scheduling order within CCTK_INITIAL based on these.  We will do this by having Carpet call a function in an external thorn or the flesh which tells it what functions need to be run to update certain variables (see later).
 * Get evolution working

←Older revision		Revision as of 08:05, 2 November 2011
Line 154:		Line 154:

	In summary: GetDependentFunctions({{varnum, gridpart}, ...}, bin) ->		In summary: GetDependentFunctions({{varnum, gridpart}, ...}, bin) ->
		+
		+
		+	====Whiteboard snapshots====
		+	[[Image:wb1.jpg]]

←Older revision		Revision as of 17:18, 1 November 2011
Line 138:		Line 138:

	</pre>		</pre>
		+
		+	====Code====
		+
		+	=====Flesh=====
		+
		+	New function GetScheduledFunctionData returns a list of structures with the schedule information of each scheduled function. Do we also want a GetScheduledGroupData for schedule groups? Do we still need schedule groups?
		+
		+	=====DataDrivenScheduler=====
		+
		+	Provides functions: GetDependentFunctions(vars) -> DAG of functions which should be traversed in order to compute all the variables in vars. This calls GetScheduledFunctionData. vars will have to be a list of objects which indicate both the variable and the part of the grid. Need a representation of the different parts of the grid - maybe we want to OR these together. Carpet will be calling this function. Might want to specify the Cactus timebin that we are interested in for this as well.
		+
		+	varspec is {varnum, gridpart}
		+
		+	gridpart is an OR of Interior, PhysicalBoundary, SymmetryBoundary, InterprocessorBoundary, RefinementBoundary - or whatever we decided were the disjoint and covering parts of the grid. We could then combine some by defining Everything = Interior \| PhysicalBoundary \| ... \| RefinementBoundary etc. These identifiers could be defined in the flesh at some point: CCTK_Interior, CCTK_PhysicalBoundary etc, and could be used in future in functions for looping over parts of the grid.
		+
		+	In summary: GetDependentFunctions({{varnum, gridpart}, ...}, bin) ->

←Older revision		Revision as of 15:47, 1 November 2011
Line 82:		Line 82:

	* We will write a new thorn, whose functionality might eventually go into the flesh or Carpet. This will call a new flesh API to get information about scheduled functions, including the READS and WRITES sections. This thorn will then convert this information into a dependency tree. The thorn will provide a function which takes a list of (parts of) variables which must be updated, and then returns (or calls a callback function on) the required scheduled functions to evaluate those variables.		* We will write a new thorn, whose functionality might eventually go into the flesh or Carpet. This will call a new flesh API to get information about scheduled functions, including the READS and WRITES sections. This thorn will then convert this information into a dependency tree. The thorn will provide a function which takes a list of (parts of) variables which must be updated, and then returns (or calls a callback function on) the required scheduled functions to evaluate those variables.
−	]	+
		+	* Everything which is specified by data dependencies should be ensured. This will leave ambiguities - for example, when should "filter" functions be called? Probably the simplest way to do this is to use BEFORE and AFTER. In the example of adding noise to initial data, you have an initial data thorn which WRITES gxx, and another thorn (MoL) which READS gxx (for its RHS). If we have a filter function which adds noise to gxx - it READS and WRITES gxx. Does this get called before or after MoL? In the current thinking, we would say that the Noise function is called BEFORE MoL. This is possible because the author of Noise knows that MoL exists. There will be situations where the two thorns don't know about each other, and in that case the only person who can resolve this is the end-user in the parameter file. We need a way to specify these orderings. Suppose we have two filters: Noise and Perturb. Both of these are scheduled BEFORE MoL, and READ and WRITE gxx. We could have a flesh string parameter called
		+
		+	dependencies = Noise < Perturb, <fn2> < <fn3>, ...
		+
		+	where "<" means "before". This provides an ordering on scheduled functions. This is one way to solve this problem - there probably are other ways.

	====Work plan====		====Work plan====

←Older revision		Revision as of 15:16, 1 November 2011
Line 76:		Line 76:

	* Christian introduced SphericalSlice		* Christian introduced SphericalSlice
		+
		+	* functionattribute structure - private flesh structure containing scheduled function information
		+
		+	* requirements.cc already committed to Carpet - depends on an ifdef. does some checking.
		+
		+	* We will write a new thorn, whose functionality might eventually go into the flesh or Carpet. This will call a new flesh API to get information about scheduled functions, including the READS and WRITES sections. This thorn will then convert this information into a dependency tree. The thorn will provide a function which takes a list of (parts of) variables which must be updated, and then returns (or calls a callback function on) the required scheduled functions to evaluate those variables.
		+	]

	====Work plan====		====Work plan====