Input Parameters

An Entrants' code will be executed twice against a selected set of the power system model scenarios of a dataset; once to determine the base case solution and once to determine contingency solutions. Strict wall clock timing is determined by TimeLimitInSeconds in both cases. Consequently, there must be two versions of the code to satisfy these requirements: Code1, which produces the file solution_BASECASE.txt; and Code2, which produces a file solution_labelk.txt for each contingency k with labelk (see the Challenge 2 Output Files page). The solution files must be created at the same directory level that the run commands are executed. The naming, invocation procedure, and other language dependencies are described below for each language supported. The language is chosen from information in the submission.conf file on GitHub, which is specified during the submission process along with the submission title and notes. 

The following information is passed to both Codeand Code2. See the Challenge 2 Input Files page for details about file formats.

InFile1 = case.con (Contingency Description Data)

InFile2 = case.json (Supplementary Data)

InFile3 = case.raw (Power Flow Raw Data)

InFile4 = Not used in Challenge 2 but maintained for compatibility.

TimeLimitInSeconds = the amount of wall-clock time in seconds before the execution will be terminated. The value is either 300 (5 minutes) for Divisions 1 & 3, or 3,600 (60 minutes) for Divisions 2 & 4 when executing Code1. The value for Code2 is 2 seconds per contingency.

Division = 1, 2, 3, or 4.  All Challenge 2 Divisions use Objective Function Scoring where the objective is the greatest market surplus. Divisions 1 & 2 do not allow transmission line switching; Divisions 3 & 4 do allow transmission line switching. The input files for a given scenario are the same for all 4 divisions.

NetworkModel is a 10 character string identifying the Network Model of the input files. These are the first ten characters of the Dataset Network Model folder name.


The file, submission.conf (all lower case), should be added to the root your GitHub repository, but is overriden by the contents of the submission.conf text box provided at the time of submission. This text file determines which dataset is run and permits additional control of the runtime environment. For additional hardware information see the Evaluation Platform page. All entries are optional and defaults are assumed if not specified. All entries are case sensitive. The current directives and their possible values (default underlined, options separated by |) are: 

model=Network_Model_Name, where Network_Model_Name (no spaces around equal sign) is one of the network model names belonging to a given submission. For example, one of the network models in the Sandbox submission set (C2_Sandbox) C2SvNxxxxx where C2 indicates this is a Challenge 2 dataset, Sv indicates it is a Sandbox dataset from release v (check the Dataset page for the current release number), and Nxxxxx indicates that the Network has xxxxx buses. The purpose of this field is solely for identification of the problem being solved. The model parameter is required EXCEPT during a Trial or Final Event when the choice is made by the platform. Example: model=C2S4N00014

scenario=scenario_number, where scenario_number (no spaces around equal sign) is a valid  integer number of a scenario in the dataset selected by the model parameter above. The number of scenarios for available for a given model is given on the dataset page for the Sandbox datasets. For Trial and Final events all scenarios will be run for you. For the model example above, "model=C2S4N00014", the choice is 1 or 2, i.e., "scenario=1". For "model=C2S1N11152", the scenario value choices are 1, 2, 3, 4, or, 5. The scenario parameter is required EXCEPT during a Trial or Final Event when the choice is made by the platform.

language = [cpp | EXE | GAMS | Java | Julia | Python]   

To choose a different language for Code 2, add the following entry:


Choose specific versions of software (language, solver, MPI library) either through modules variable as below or through exporting environment variables in consultation with GO Operations Team.

modules=<space separated modules>

Here are a few commonly used modules. Other modules, versions and library packages are also possible.  Contact the GO Operations Team for specific requirements (e.g. virtual environments for python).

  • python/2.7.14 
  • python/3.7.0
  • gcc/7.3.0
  • cmake/3.15.3       
  • intel/18.0.0 intelmpi/2019u4
  • gcc/4.8.5 openmpi/2.1.1

Gurobi request



export GRB_LICENSE_FILE="$GUROBI_811_HOME/license/gurobi_client.lic"

Julia (example version 1.5)

export JULIA_DEPOT_PATH=<request the GO Team for your own depot>

export PATH=$JULIA_150:$PATH

Ipopt v 3.13.3, ASL, HSL built with MKL

source $INTEL2019/mkl/bin/ intel64

source $INTEL2019/compilers_and_libraries/linux/bin/

export PATH=$PATH:$APPS_BASE/Ipopt/build/bin


MPI options

srun_options=[no defaults] For srun_options, anything valid on srun command line can be included. Most common are:

  • srun -N 1 : get one complete node and manage cores
  • srun -n 5 :  get five cores
  • srun -N 1 -n 5 :  get five cores on the same node
  • srun -N 3 -m cyclic : get three nodes, but just one core per node
  • srun -N 3 -n 2 -m cyclic : get three nodes but just two cores per node


GPU access

srun_options=-p gpu -N 1   This allows access to a Competition standard node [dual Xeon E5-2670 v3 (Haswell) CPUs, 24 cores per node] with NVidia Tesla K-80 GPUs



Java projects must be supplied with jar files for the main executable and dependent libraries. Be sure to use forward path separators (//), which is considered system independent on the Java platform, to create the solution files. All dependencies, with the exception of the suite of commercial libraries that are preinstalled (e.g., cplex, gurobi, mosek, etc.), must be included in the lib directory of your project (e.g., Ipopt). Projects are executed without network access so managed dependencies will be unreachable. Your code must take command line arguments which will specify the input data for the case being evaluated. The following commands will be executed with MyJava being the jar and package name while MyJava1 (Code1) and MyJava2 (Code2) are your submission codes packaged inside the provided jar file:

java -cp "MyJava.jar:lib/*" MyJava.MyJava1 InFile1 InFile2 InFile3 InFile4 TimeLimitInSeconds ScoringMethod NetworkModel
>> MyJava1.log


java -cp "MyJava.jar:lib/*" MyJava.MyJava2 InFile1 InFile2 InFile3 InFile4 TimeLimitInSeconds ScoringMethod NetworkModel
>> MyJava2.log



The GO Competition may be using GAMS version 26.1.0. Please contact the GO Operations Team to find out which solvers supported by GAMS are available.

It is recommended that Entrants wishing to use GAMS first process the input files with another language, e.g., Python, and invoke GAMS from within that language. The syntax that will be used for anyone selecting GAMS during submission is as follows:

gams MyGams1.gms --con=case.con --sup=case.json --raw=case.raw --timelimit=[300 | 3600] --ScoringMethod=[1 | 2 | 3 | 4] 
--NetworkModel=model_name >> submission1.log


gams MyGams2.gms --con=case.con ----sup=case.json --raw=case.raw --timelimit=[300 | 3600] --ScoringMethod=[1 | 2 | 3 | 4] 
--NetworkModel=model_name >> submission2.log

GAMS refers to this method of passing arguments as “double dash parameters”. The method of retrieving their values in a GAMS script is documented here:



Submitted code will be executed with the commands

julia --compiled-modules=no -e ‘include(“MyJulia1.jl"); MyJulia1(InFile1, InFile2, InFile3, InFile4, TimeLimitInSeconds, 
ScoringMethod, NetworkModel)' &>MyJulia1.log


julia --compiled-modules=no -e ‘include(“MyJulia2.jl"); MyJulia2(InFile1, InFile2, InFile3, InFile4, TimeLimitInSeconds, 
ScoringMethod, NetworkModel)' &>MyJulia2.log

“--compiled-modules=no” is included on the command line to turn off module precompilation within timed runs. warmup.jl must be used instead for triggering precompilation. Contact the Go Operations Team for further information.

See the submission.conf section above for version options and how to select them.



Submitted code will be executed with the commands

python InFile1 InFile2 InFile3 InFile4 TimeLimitInSeconds ScoringMethod NetworkModel >> MyPython1.log


python InFile1 InFile2 InFile3 InFile4 TimeLimitInSeconds ScoringMethod NetworkModel >> MyPython2.log

Python versions 2.7 and 3.7 are supported.  Please execute the command "pip freeze > requirements.txt" on your home system and send the results to the GO Operations Team to request specific Python packages.



MATLAB is not supported for Challenge 2 submissions.



C++ submissions must provide MyCpp1.cpp and MyCpp2.cpp. Either make or cmake system can be requested to generate executables MyExe1 and MyExe2 from sources and libraries.

Before execution, the command "make all" is issued, then the code will be executed with the commands

./MyExe1 InFile1 InFile2 InFile3 InFile4 TimeLimitInSeconds ScoringMethod NetworkModel >> MyExe1.log


./MyExe2 InFile1 InFile2 InFile3 InFile4 TimeLimitInSeconds ScoringMethod NetworkModel >> MyExe2.log


Linux binary executables

The executables must be named MyExe1 and MyExe2. The invocations are the same as C++, with parameters being passed via command line arguments.


If you have any questions, please contact the GO Operations Team.