Documents/Program submission for the ROADEF/EURO challenge 2020 Qualification phase

Registered participants shall send (before the deadline of the qualification stage) the following material:

  • Team Id (provided upon registration) and category,
  • An abstract (2 pages) of the proposed method including the characteristics of the computer used,
  • A table giving the results and CPU times obtained on each instance,
  • the solution files of each instance of set A,
  • the program to solve the problem).

All these documents shall be sent to organizers with the subject " ROADEF/EURO challenge 2020 qualification material from XX" where XX is your teamId. Do not send direclty an archive attached to the mail (our mailers may not receive it if the size is too large), but give us a link to download it.

For our evaluation scripts, the participants are asked to provide an executable called challengeRTE, with the following syntax: executable -t time_limit -p instance_name -o new_solution_filename -name -s seed

  • -t time_limit to stop the program execution after time_limit seconds (caution: this is "real time", not cputime). The test machine will be totally dedicated and the tests will be done sequentially, therefore all the teams will have the same amount of CPU power. If program don't stop at time_limit, it is considered as infeasible.
  • -p instance_name to load the data associated with the instance.
  • -o new_solution_filename to designate the result file.
  • -name to return the teamId that is the author of the executable (if it is the only option the executable returns the team identifier and quits). The teamId will be given to every team upon registration.
  • -s seed force program with random to be deterministic. The same seed will be used for each team and each instance. Using the seed value passed as a parameter to the executable program is under the responsibility of participants to support the repeatability of experiments/evaluations, particularly, if their solution methods are based on probabilistic frameworks or components
    Programs will be evaluated only ONCE, never TWICE. If variability occurs, the organisers can not be responsible from potential bad behaviour on this single run.