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.txt. 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 information is passed to Code1. See the Challenge 3 Data Format page for details about file formats.

InFile1 = case.json (All Problem Description Data)

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 minues or 2 hours) for Division 2, and 14400 (240 minutes or 4 hours) for Division 3 when executing Code1. Division 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 the greatest market surplus gain. The input files for a given scenario are different for each division.

NetworkModel = C3SvNxxxxxDn is a 12 character string identifying the Network Model of the input files. These are the first twelve characters of the Dataset Network Model folder name.

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. 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 (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), and Nxxxxx indicates that the Network has xxxxx buses and Dn is the Division number. 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=C3S0N00014D2

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=C3S0N00014D2", the choice is 1 or 2, i.e., "scenario=1". The scenario parameter is required EXCEPT during an 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:

language2=<language>

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

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) 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

and

java -cp "MyJava.jar:lib/*" MyJava.MyJava2 InFile1 InFile2 InFile3 InFile4 TimeLimitInSeconds ScoringMethod NetworkModel
>> MyJava2.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 --con=case.con --sup=case.json --raw=case.raw --timelimit=[300 | 3600] --ScoringMethod=[1 | 2 | 3 | 4] 
--NetworkModel=model_name >> submission1.log

and

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: 
https://www.gams.com/latest/docs/UG_GamsCall.html#UG_GamsCall_DoubleDashParametersEtc_DoubleDashParam.

 

Julia/JuMP

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

and

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.

 

Python

Submitted code will be executed with the commands

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

and

python MyPython2.py 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/MATPOWER

MATLAB is not supported for Challenge 2 or later submissions.

 

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 InFile2 InFile3 InFile4 TimeLimitInSeconds ScoringMethod NetworkModel >> MyExe1.log

and

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