Languages

Input Parameters

For Challenge 1 and 2, an Entrants' code was 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, two versions of the code were needed to satisfy these requirements: Code1, which produced the file solution_BASECASE.txt; and Code2, which produced a file solution_labelk.txt for each contingency k with labelk (see the Challenge 2 Output Files page). The solution files were created at the same directory level that the run commands are executed.

For Challenge 3, only a single Code1 is needed to produce the file solution.json. There is NO Code2 in Challenge 3.

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 5 input parameters are passed to Code1. See the Challenge 3 Data Format page for details about file formats.

InFile1 = scenario_nnn.json (All problem description data, see Data Format for details)

TimeLimitInSeconds = the amount of wall-clock time in seconds before the execution will be terminated. The value, in seconds, is either 600 (10 minutes) for Division 1, 7200 (120 minutes or 2 hours) for Division 2, and 14400 (240 minutes or 4 hours) for Division 3 when executing Code1. Divisions 4, 5, and 6 use the results from Divisions 1, 2, and 3.

Division = 1, 2, or 3.  All Challenge 3 Divisions use Objective Function Scoring where the objective is defined by "z" in the Formulation Document. The input files for a given scenario are different for each division.

NetworkModel = C3VvNxxxxxDn is a 12-character string identifying the Network Model of the input files where V is either S (Sandbox) or E (Event) and v is an integer. These are the first twelve characters of the Dataset Network Model folder name. The purpose is to identify similar problem instances.

AllowSwitching = Either a 1 (switching is allowed) or 0 (switching is NOT allowed). This is primarily for post-Challenge analysis to study the impact of switching. In order to ensure that the AllowSwitching argument is implemented and able to be used in post-Challenge analysis, we intend that there will be some runs contributing to Challenge 3 prize awards using “AllowSwitching=1”, and there will be some using “AllowSwitching=0”. Recall that a solution is said to use switching if the on/off status of some AC line or transformer in some time interval is different from the initial status specified in the problem data. If a code is called with “AllowSwitching=0”, and the solution evaluator determines that the solution does use switching, then the solution will be deemed infeasible.

submission.conf

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. Dataset specific options are ignored for Event submissions; these will be determined by the Event. The current directives and their possible values (default underlined, options separated by |) are: 

dataset=[S0.1 | S1.1 | S2.1 | S3.1 | S4X | E1.1 | E2.1 | E3.1], the dataset value is one of the datasets listed on the current Dataset page.

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 (C3_Sandbox) C3SvNxxxxxDn where C3 indicates this is a Challenge 3 dataset, Sv indicates it is a Sandbox dataset from release v (check the Dataset page for the current release number), Nxxxxx indicates that the Network has xxxxx buses, and Dn indicates the Division number (1, 2, or 3 for Challenge 3; no Dn for S0). The purpose of this field is solely for identification of the problem being solved. The model parameter is required EXCEPT during an Event when the choice is made by the platform. Example: model=C3S0.1N00014

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 Events all scenarios will be run for you. For the model example above, "model=C3S0.1N00014", the choice is scenario 3, i.e., "scenario=3". The scenario parameter is required EXCEPT during an Event when the choice is made by the platform.

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

experiment = [SW0 | SW1], where SW0 indicates that the AllowSwitching parameter above is set to 0 (switching not allowed and if detected will result in an infeasible determination for the solution). The default is SW1, i.e., switching is allowed.

The default time limits may be overridden up to the maximum value of 24 hours for Sandbox runs. This does not apply to Event runs. Time is always specified in seconds.

div1_timelimit_sec = [600 | value <86,400 (24 hours)]

div2_timelimit_sec = [7,200 | value <86,400 (24 hours)]

div3_timelimit_sec = [14,400 | value <86,400 (24 hours)]

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 GUROBI_HOME=$GUROBI_811_HOME

export LD_LIBRARY_PATH="$GUROBI_811_HOME/lib:$LD_LIBRARY_PATH"

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/mklvars.sh intel64

source $INTEL2019/compilers_and_libraries/linux/bin/compilervars.sh

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

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$APPS_BASE/Ipopt/build

MPI options

 

The following versions are available for Challenge 3:

openmpi/2.1.1   openmpi/3.1.3   openmpi/4.0.2   openmpi/4.0.6    openmpi/4.1.0    openmpi/4.1.1     openmpi/4.1.3    openmpi/4.1.4

gcc/10.2.0  gcc/10.3.0  gcc/11.2.0  gcc/4.4.7   gcc/4.8.5   gcc/5.2.0   gcc/7.1.0   gcc/7.3.0   gcc/7.5.0   gcc/8.1.0   gcc/8.4.0   gcc/9.1.0

mvapich2/2.3a      mvapich2/2.3.2       mvapich2/2.3.5       mvapich2/2.3.5.fthread     mvapich2/2.3.6     mvapich2/2.3.6.fthread        mvapich2/2.3.7

An example that can go into the submission.conf is

               module load cmake/3.15.3 gcc/10.2.0 openmpi/4.1.4

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/Scala

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) are your submission codes packaged inside the provided jar file:

java -cp "MyJava.jar:lib/*" MyJava.MyJava1 InFile1 TimeLimitInSeconds Division NetworkModel AllowSwitching >> MyJava1.log

GAMS

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 --InFile1=case.json --timelimit=[600 | 7200 | 14400] --Division=[1 | 2 | 3] --NetworkModel=model_name 
--AllowSwitching=[1 |0] >> submission1.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: https://www.gams.com/latest/docs/UG_GamsCall.html#UG_GamsCall_DoubleDash....

Julia/JuMP

Submitted code will be executed with the commands

julia --compiled-modules=no -e ‘include(“MyJulia1.jl"); MyJulia1(InFile1, TimeLimitInSeconds, 
Division, NetworkModel, AllowSwitching)' &>MyJulia1.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.

Python

Submitted code will be executed with the commands

python MyPython1.py InFile1 TimeLimitInSeconds Division NetworkModel AllowSwitching >> MyPython1.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/MATPOWER

MATLAB is not supported.

 

C/C++

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 TimeLimitInSeconds Division NetworkModel AllowSwitching >> MyExe1.log

Linux binary executables

The executables must be named MyExe1. 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.