The 2020 OpenMDAO workshop will be a reverse hackathon, that will be held October 19 – 30. This will be a virtual, asynchronous event, with no cost to anyone who wants to participate.
Check out the github repo for the event, to submit your ideas
Our goal for this event is to spur the adoption of the most advanced features in OpenMDAO by the broader user community, so we are explicitly offering to help you upgrade your models!
What is a reverse hackathon?
In a normal hackathon, the organizers pose the problems and the participants solve them. We’re flipping that around.
You pose challenge problems to the OpenMDAO dev team. We’ll solve as many of them as we can for you! On top of that, we’ll give a write-up on our solution with important details about what we did and why.
While we’re in the middle of solving your problems, we’ll likely have lots of questions. So we expect there to be lots of discussion back and forth.
Critical Dates:
- Initial Project Submissions Due: October 1st, 2020
- Final Project Submissions Due: October 19th, 2020
- RevHack 2020 Presentations: October 30th, 2020
Besides the due dates for project submissions, the other date to note is the 30th. That’s when we’ll be posting some talks on important topics for the community, including a summary of the most important new features developed in 2020 and the 2021 development roadmap.
How will the devs pick which ones to work on?
It is critical that your problem is scoped so it can be tackled within the two week window. It can certainly be shorter than 2 weeks (we’re totally fine solving smaller problems!) but it can’t be longer than that. That’s not a lot of time, so we’re stipulating that we won’t add any new features to OpenMDAO. You must submit a problem that can be solved with current features!
We’re also asking for a well defined request such as:
- Convert the provided code to an OpenMDAO component/model
- Differentiate the given component
- Profile and speed up a given model
- Stabilize an optimization problem so it finds a solution more robustly
- Generate a data-post processing script (e.g. plots Y vs X over the entire iteration history) for a model that is being executed in a strange way
If you have an interesting problem that you would like to work on, but you’re not totally sure what the best request to make would be, that’s ok! You can submit a less well defined idea and we’ll try to work with you to narrow it down a bit.
Here are some suggestions to get you started here are a few broad ideas:
- Pushing the boundaries: a problem where the solution will extend the capabilities of OpenMDAO by creating a new technique for using the framework
- Software design: finding the best way to integrate a modular analysis into OpenMDAO or convert a non OpenMDAO analysis into an OpenMDAO component
- Derivatives: Differentiating a tricky component, or speeding up the performance of your existing derivatives implementation with advanced coloring features.
- Performance: Identifying bottlenecks and speeding up code that is already implemented in OpenMDAO
- Numerical Stability: Improving the robustness of a nonlinear solve or optimization so that it gets a converged answer more frequently
Problem Requirements:
Open Source: The number one most important requirement is that all the code associated with the problem needs to be open source. That includes any and all dependencies that your code has. It’s ok if you need a few external libraries as long as they are open source!
Concise: Please keep your code as short as possible. We suggest a soft limit of 1500 lines of code (excluding external dependencies). We won’t automatically reject the problem if there is too many lines, but we’ll be hesitant. We’re asking you to put some effort into crafting a concise chunk of code for us to work with and others can relatively easily digest.
Tests: Your submission should include some tests that show us how to run your code and what the expected answer should be (even if its not currently getting the right answer).
How do you submit a problem?
You submit a pull request to the RevHack2020 repository. Add a new folder, and in it include whatever code is needed along with a readme file that describes the code and the specific, well defined request you have.
It’s ok if your initial pull request isn’t fully baked. The code doesn’t need to be there at first. You could have only a readme that spells out what you’re thinking. The devs will review your PR and respond, asking questions or making suggestions.
We’ll we’re likely to pick your project to work on, or if we think your proposal is too narrowly focused and won’t offer enough value to the broad community. Preparing a good problem that is concise, but has the details necessary will takes time. We’re happy to give you a strong indication of whether your time will be well spent or not.
Want to do some of the hacking yourself?
Think you have what it takes to tackle one of the submitted problems yourself? You’re more than welcome to! You can comment on the PRs with the proposed problems just like the devs will. The more the merrier!
