Hi Everybody, This mail describes the format of the files that should be generated by your planners, and that contain the output plans. The format of these files is very similar to the one used for the deterministic part of the previous competitions (see the explanation below). There is an additional item "Planning technique" only for those planners that use multiple, alternative techniques or subplanners. Cheers, Alfonso ========================================================================= Results File Format ------------------- PLEASE USE ***STRICTLY*** THE FOLLOWING FORMAT. ; Time ; ParsingTime ; NrActions ; MakeSpan ; MetricValue ; PlanningTechnique : ( .. ) [] . . . : ( .. ) [] Explanation of the different items (from top to bottom) ------------------------------------------------------- ; Time Here you specify the TOTAL CPU time taken by your planner to solve the instance (including parsing time and any possible preprocessing and/or postprocessing performed by the planner). As said before, we will run sampled tests to check that the runtimes you specify are correct. If your planner can't solve an instance, then you should NOT produce a results file. Please give in SECONDS, with a precision of 0.01 seconds, i.e. two decimal places. If your planner is incremental, e.g., it is capable of producing multiple solutions with increasing quality, the CPU time reported in the output plan file generated by the planner should be the time when the process *ENDS*. Please take into account that each process will be automatically killed when the CPU usage exceeds 30 minutes, and so before being killed it should generate the output file (reporting 30min CPU-time). ; ParsingTime We would like to be able to distinguish the planning time from the parsing time, just in case the parsing time is significant for some planner(s). By parsing time we mean the time taken from the start of your planner until the files are parsed into data structures, **before** any other planning activities or pre-processes start. If you can't measure parsing time for some reason, leave the field empty. i.e., just output the line ; ParsingTime Please make your planner output the parsing time clearly visibly, so we can check that, too. ; NrActions ; MakeSpan ; MetricValue Here you specify the quality of your plan. Please use only **one** of the three options (leaving the two other fields empty) as indicated in the following. For problems in the domain category "Propositional", you can **choose* between NrActions (number of plan actions) and MakeSpan (number of time steps), depending on which of these quality notions your planner tries to optimize. E.g., if you have a Graphplan-like planner that for the propositional category optimizes makespan, then these three lines should be: ; NrActions ; MakeSpan ; MetricValue For the test problems in all other categories (Simple Preference, Qualitative Preference, Metric-time, Constraints, Complex Preferences), all planners should use the **MetricValue** field. In the evaluation of the plan quality, for the propositional domain category, we will try to compare planners that use the same quality notion, while for the other categories, we will use the value specified in the MetricValue field. If a domain variant in the metric-temporal category is purely temporal (without numerical fluents), then the MetricValue will be the same as the makespan. Descrition of the three different quality notions: is, of course, just the number of actions in your plan; is the latest endpoint of any action in your plan, i.e. maximum + (see the explanation of the plan notation below); is, if a :metric field is given in the problem file, the value of that metric in the state that results from execution of your plan. By the definition of PDDL, if no :metric field is given, by default (total-time), i.e. plan makespan, is to be minimized. ; PlanningTechnique This item should be considered only by those planners that use multiple, alternative techniques or subplanners. If this does not apply to your planner, then you should leave the field empty, i.e., just output the line ; PlanningTechnique Otherwise, please give one or few keywords indicating the specific technique(s) that was used by the planner (. For instance, the well-known FF planner can solve a problem using "enforced hill-climbing" of "best-first" search. In FF were a competing planner, then the technique (most likely the first) used to generate the solution plan in the file would have to be specified as follows ; PlanningTechnique enforced hill-climbing The keywords should be chosen is such a way that, from the abstract of your planner (that you will submit), it is sufficiently clear to identify which of the alternative method/subplanner was used. : ( .. ) [] . . . : ( .. ) [] This is the specification of your plan for the instance. The format is the general one for durational domains, and subsumes non-durational plans both in the sequential and the (Graphplan-)parallel form. In the non-durational setting, assume that is 1 for all actions. A non-durational sequential plan with, e.g., 15 actions is like this: 0: ( .. ) [1] . . . 15: ( .. ) [1] A non-durational (Graphplan-)parallel plan with, e.g., 15 steps is like this: 0: ( .. ) [1] . . 0: ( .. ) [1] . . . 15: ( .. ) [1] . . 15: ( .. ) [1] In the unlikely case that the problem is NOT solvable, and your planner does prove it, the planner should produce a results file where, instead of the plan actions, there is "no valid plan". We will check your plans with VAL, the validation tool by Derek Long and Richard Howey. The current version of VAL supports only PDDL2.2; work is in progress to extend it to PDDL3.0. VAL is available from http://www.cis.strath.ac.uk/~rh/val.html The input of VAL is a plan in the format given above, i.e. in the same format as our results files with the first 6 lines ignored.