Register
Submit a solution
The challenge is finished.

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 yearthis 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:

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.

Review style

Final Review

Community Review Board

Approval

User Sign-Off

ID: 30041196