Challenge Overview
Project Overview
Recent studies have shown that the maximum technically recoverable energy from U.S. waves and tidal currents in approximately 1,420 terawatt-hours per year (TWh/yr). From this total, Wave Energy Conversion (WEC) devices could extract an estimated 1,170 TWh/yr along the coast of the United States. Because 1 TwH is equivalent to the energy consumed by 100,000 American homes in one year, this means that WEC devices could technically power 100 million American homes each year.
With nearly 40% of the nation's population (about 125 million Americans) living in counties directly on the United States' shoreline, this renewable energy source is worth the investment. And because an increasing portion of Americans are moving to the coast each year, accelerating the development of WEC devices could lead to a huge return on investment by providing clean, renewable power to significant portion of the U.S. population.
But there's one big problem - testing new WEC devices is currently prohibitively expensive. Developers of these devices require a software model that can simulate the movement of waves and determine the amount of power that their WEC device would output in a wave environment. This type of modeling software currently costs about $40,000 a year to use. While large corporations may be able to afford this high price tag, start-ups hoping to enter the wave energy industry cannot.
The goal of this project is to produce a customizable open-source modeling software that can be used by anyone developing WEC devices in the United States. This will lead to faster innovation so that wave energy start-ups all over the country can develop, analyze, and optimize their devices more quickly than ever before.
Contest Objective
The goal of this competition is to discover and document any issues related to the assembly deliverable.
Any issues the reviewer missed and the bugs caused by the implementation to DOE Mesh Generator application (compiling, configuration, documentation, descritptive text) are in scope.
Contest Guidelines
The guidelines for this contest are given below:
- As issues are identified they need to be logged in Jira.
- Issues must include clear descriptions, test cases and steps to reproduce and expected vs. actual results in order to be counted.
- First competitor to find an issue gets credit, duplicates will not be counted.
- Reviewers will accept, reject or mark the issues as duplicate.
- Please DO take a look at the reported bugs, duplicated bugs cost your work time and the reviewer's time.
Important Notice:
You must also be the first person to report the issue and submit it while submission phase is open. JIRA will allow you to file issues before and after the submission phase, but these will NOT be counted.
Technologies
- C++
- Fortran
Provided Resources
Documentation Provided
The following documentation will be available in the contest forum:
- The previous assembly details - http://apps.topcoder.com/wiki/display/~hello-c/Department+of+Energy+%28DOE%29+-+Mesh+Generator+Improvement+Assembly+2
- Source code - Provided in the forum
Contest Prize Eligibility
The submitter with the most accepted bugs will win the contest.
Final Submission Guidelines
Bug Report Process
Bug Report Format
For each report of a limitation or bug, we need the following information:
- Steps to reproduce, including any needed information
- Screen shots (if applicable)
- Expected results after the bug is fixed
- Current results, before the bug is fixed
Important Notice:
- If you do not properly document your bug reports, they will likely be rejected due to lack of information or documentation. Also, make sure your bug reports are reasonably general.
- If you submit the same bug that is seen in multiple screens, for instance, you will likely only get credit for the original bug report. The others will all be closed as duplicates.
Ticket Logging
You will log your tickets here: https://apps.topcoder.com/bugs/browse/DOEOW and when creating a bug you MUST select the MeshGeneratorBugHunt component. Bugs will not be counted if a selection is not made.
Scoring
The Scoring guidelines followed for the contest are given below:
- For scoring, the submitter with the most accepted bugs will win. The submitter with the second most accepted bugs will receive second place.
- For submitters who submit but don't take first or second, if they submit bugs that aren't covered in the first or second place submission, they will receive $5 for each unique bug reported up to a maximum of the 2nd place prize.
Important Notice:
If two submitters submit the same bug report, the submitter who submitted the report first into JIRA will get credit for the bug. The second submitter will not.
Tips
Some of the tips helpful for the contest are:
- Submitting what is obviously the same issue multiple times with small variations will only annoy the reviewer that has to sort through all the issues and will only count as one issue anyway. If it's less obvious if it is the same issue or not, use your best judgment and the reviewers will do the same.
- Put an eye on the issues being submitted by other members to minimize the time you may be spending on duplicate efforts. Knowing what has already been reported will allow you to better focus your time on finding yet undiscovered issues.
- Double check your steps to reproduce and test cases to make sure they are clear. Make sure your steps include creation of any necessary data.
Submission Deliverables
You need report your issues in JIRA. Please submit a text file contains the bugs you reported to OR.
Final Submission
- For each member, the final submission should be uploaded to the Online Review Tool.
- You must not include any identifying information, such as your handle, in your submission. Your submission should be anonymous and you will be scored down in screening for not complying.