ATTENTION: Trial Event 1 has closed. Sandbox and Challenge 1 submissions are closed during the Trial Event 1 evaluation period. E-mail will be sent to all GO website registered users once the GO Competition Platform has reopened.
Frequently Asked Questions
The Department of Energy Advanced Research Projects Agency-Energy (ARPA-E) is challenging the research and industrial communities to successfully develop and test power system optimization and control algorithms on new, publicly available, large-scale, and high-fidelity power system network models. For more information, please read here.
The GO Competition consists of multiple stages summarized below:
Beta Testing: This is the predecessor to the actual competition and allows the public to understand and test the submission processes. The relatively small and simple datasets and solutions are publicly available for download. This stage began June15, 2017, and ended October 30, 2018.
Challenge 1: The first round of the formal competition will solve a Security-Constrained OPF (SCOPF) problem. The focus will be on large-scale industry sized systems, up to, up to 60,000 buses and thousands of contingencies, with an updated problem description. Datasets will come from the ARPA-E GRID DATA program and real-world industry datasets. See the Timeline document for information on dataset release.
Start Date: Fall 2018 (Projected; Subject to Appropriation of Funding)
End Date: One year after start (Projected)
Challenge 2: Challenge 2 is expected to build on the models used in Challenge 1 and may include complicating factors such as solving larger network models, optimizing power flows over both transmission and distribution systems, and/or including unit commitment.
Start Date: At the end of Challenge 1 (Projected; Subject to Appropriation of Funding))
End Date: One year after start (Projected)
All dates are approximate and subject to change. Challenge 1 and 2 are also subject to appropriation of funding.
Final rankings for Challenge 1 will be announced following the Final Event one year after Challenge 1 starts (projected).
Yes, you need to register to participate in the competition. You must register as a team, which can be comprised of an individual or more than one individual.
You must register as a team. A team may consist of one or more individuals; thus, you can be the only member of a team.
Once you have successfully registered and created a GitHub account, click on the Create Team button located on your Account View page. Follow the directions by entering a Team Name (which must be unique to the GO Competition), the GitHub username, and the ARPA-E Competition Identifier which ARPA-E has provided to you (if you don't have one, you can fill it in later from the My Team page). Skip the last step in choosing team members. Click the Save button and you should see the My Team page with only yourself as the team members.
Once you have successfully registered and created a Team GitHub account, click on the Create Team button located on your Account View page. Follow the directions by entering a Team Name (which must be unique to the GO Competition), the Team GitHub username, the ARPA-E Competition Identifier which ARPA-E has provided to you (if you don't have one, you can fill it in later after you created your team), and choose your teammates. A team may consist of one or more individuals. If you are the only person on your team, you can skip the last part; otherwise, please make sure you choose the correct individuals and they must match the team that you provided to ARPA-E on their registration form. Click the Save button and you should see the My Team page.
First you need an account on the GO Competition website. Go to the Registration Page to fill in your personal information. Once you have successfully registered, notify the team leader and s/he will add you to their team and GitHub Team repository.
You can only register with one team per challenge.
Yes, all team members must sign the required form and return it following the directions on the back of the form.
Yes. Any teams created during the Beta Testing are only for our testing period and have no implications for the competition. New teams must be created for each challenge, but you may continue to use the same name even if the membership changes.
No. Once you have registered, you cannot change the Team GitHub account username.
The competition uses GitHub to manage submitted solutions. All code submitted by a team must be stored in GitHub. You must grant read access to the GitHub account; this is accomplished with a public SSH key that you can find in your My Team summary.
You can view/download the full step-by-step instructions (with screen shots) found under Resources. A summary of the steps are:
1. Go to the ARPA-E Optimal Power Flow Competition login page and log in using the username and password associated with your account.
2. Once logged in, go to View Account under the Account menu.
3. Click on the My Team button to view My Team information.
3. In the "Team Information" section, copy the SSH Public Key information; this is the text with "ssh-rsa ... pnl.gov". You can also click the Copy SSH Information button.
4. Go to the GitHub login page and log in using the username/e-mail address and password associated with your account.
5. Once logged in, go to your submission repository.
6. Click the “Settings” option from the tab bar along the top of the page.
7. Click the “Deploy keys” option from the pane on the left hand side of the page.
8. Click “Add deploy key” button on the right hand side of the page.
9. Enter a “Title” (e.g. ARPA Competition) and paste the SSH Public Key information from step 3. Leave all other settings.
10. Click the “Add key” button to complete the process.
Congratulations! Here is how you can enter your solution for evaluation:
1. Register with the GO Competition by going to the Registration Page.
2. Create a Team GitHub account.
3. Create a team. All competition submissions must be submitted by a “team.” Teams can consist of an individual or many individuals.
Note: Team Creation requires a valid Team GitHub account.
4. Return to GitHub to establish the SSH key (in My Team view).
5. Commit (save/upload) your algorithms/optimization software to your GitHub repository.
6. Submit your algorithms/software for evaluation and scoring.
7. View your results from the Accounts Page or by clicking on the My Team button and view your "My Team Submission" panel.
The website receives event messages from the evaluation platform and assigns a date/time as they are processed. It processes the most recent message first, giving the appearance of events being out of order.
A computer algorithm will judge the submission.
The python Evaluation source code will be made publicly available through this site once the evaluation process has been finalized and approved and the code is is deemed stable and reliable.
Yes, you will get some feedback on where your code failed via a log summary. This log summary can be viewed in the submission details; your submissions can be found in the "My Team Submissions" panel; you can reach this information by going to your Team Information by clicking on My Team in View Account. Click on an individual submission and you will find the link to download log files.
The initial score is based on your submission as it compares to other submissions at that current time for the dataset that was indicated on the submission form. The ranking is based on all current submissions.
The final results will be based on unpublished datasets, so the final standings may be different. These datasets will be published after the competition and evaluation have been completed.
According to eq. 85 of the Problem Formulation document, a generator responding to a given contingency adjusts its real power output according to its predeﬁned (oﬄine) participation factor until it hits an operational bound (min or max capacity). The real power output of a responding generator g in contingency k is p + α ∆, if the generator follows its required participation factor.
Is therefore the following statement correct?
According to eq. 207 of the same document, ∆ is not in the pu-system, but in MW. In the output file solution2.txt, the delta section is also filled in MW.
The variables and parameters of the problem can be expressed in two unit conventions: a data unit convention; and a model unit convention.
The data unit convention is used for the input and output data files and is mostly MW, MVar, MVA, etc., except for voltage magnitude values which are p.u. This choice was motivated by the default unit convention of PSSE data files. We extended this data unit convention to the output data as well, i.e. solution1 and solution2.
The model unit convention is used to express the equations of the model and is exclusively p.u.
Conversions of data parameters from data units in input data files to parameters in the model and from model variables in model units to solution data in data units in solution files are given in the formulation document.
Delta is a quantity of real power; therefore, its units are MW in the data unit convention and p.u. in the model unit convention.
Consider the equation pk[g,k] = p[g] + alpha[g] * Delta[k]. This is not the same as the formulation, for it ignores pmin and pmax, but if generator g does not hit a bound in contingency k, then this equation should hold. In this equation pk, p, and Delta are quantities of real power expressed in p.u., and alpha is a dimensionless quantity. To write the solution files, pk, p, and Delta are converted to their representations pk’, p’, and Delta’ in the data unit convention, e.g. by pk’[g]=sbase*p[g]. Then the numerical values of pk’, p’, and Delta’ are written in the solution files.
Clarification about the dimension of the participation factor alpha, respectively the governor permanent droop from appendices A.4, respectively C.11. The participation factor is announced as dimensionless, and the sum of all participation factors must be one to counteract the ∆ exactly. But looking at Original_Dataset_Real-Time_Edition_1\Network_01R-10\case.inl as an example, the values are far away from 0<=alpha<=1. Is there an error in this interpretation or in the documentation? To receive valid participation factors, each alpha must be divided by the sum of all alpha. Is this true?
This is not necessarily true. Delta[k] need not be equal to the generation lost in contingency k or the change of AC power losses or any such physically meaningful value. Delta[k] is simply any quantity of real power that ensures that values of pk satisfying the real power adjustment constraints pk[g,k] = Proj_[pmin[g], pmax[g]] (p[g] + alpha[g] * Delta[k]) also satisfy the power balance constraints. If the alpha values summed to 1, then it might be possible to interpret Delta[k] in some physically meaningful way. But this interpretation is not necessary.
E.g. suppose we have 2 generators and 1 contingency, with generator 2 going out of service in contingency 1. Suppose p’ = [100.0, 100.0] (MW), alpha = [10.0, 10.0] (dimensionless), pk’ = [[200.0, 0.0]] (MW). Then we can take Delta’ = [10.0] (MW). Delta’ is not equal to the amount of generation lost in the contingency, but it is a real power quantity expressed in MW. The alpha values do not sum to 1, but they are dimensionless.
Does a generator that is Out-of-Service in a Generator-Out-of-Service contingency no longer adjusts its real power (Generator Real Power Contingency Response) and does not try to maintain the base case voltage magnitude at its bus by adjusting the reactive power output (Generator Reactive Power Contingency Response)?
A generator that is out of service in a Generator-Out-of-Service contingency must have real and reactive power output equal to 0 in that contingency, regardless of the voltage magnitude. This is contained in equations 60 and 62.