Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

2020 Development Roadmap #1091

Merged
merged 29 commits into from Nov 6, 2019

Conversation

@JustinSGray
Copy link
Member

JustinSGray commented Oct 24, 2019

No description provided.

ROADMAP.md Outdated Show resolved Hide resolved
Copy link
Contributor

DKilkenny left a comment

Bullet and dashed points go in and out of capitalization through out. Might want to standardize and go with capping the first letters of all bullet points or not

ROADMAP.md Outdated Show resolved Hide resolved
Copy link
Contributor

swryan left a comment

suggestions to be a bit more formal rather than notes-like...
might want to use complete sentences rather than fragments

ROADMAP.md Outdated Show resolved Hide resolved
ROADMAP.md Outdated Show resolved Hide resolved
ROADMAP.md Outdated Show resolved Hide resolved
ROADMAP.md Outdated Show resolved Hide resolved
ROADMAP.md Outdated Show resolved Hide resolved
ROADMAP.md Outdated Show resolved Hide resolved
ROADMAP.md Outdated Show resolved Hide resolved
ROADMAP.md Outdated Show resolved Hide resolved
ROADMAP.md Outdated Show resolved Hide resolved
ROADMAP.md Outdated Show resolved Hide resolved
ROADMAP.md Outdated Show resolved Hide resolved
ROADMAP.md Outdated Show resolved Hide resolved
ROADMAP.md Outdated
## 3) Establishing a formal OpenMDAO plugin system
- To go alone with the POEM process,
we need a method for users to add functionality without merging their code to core codebase.

This comment has been minimized.

Copy link
@bollwyvl

bollwyvl Oct 25, 2019

Contributor

Hooray extensions! I learned a lot from watching this talk.

Since then, we've built a couple such systems: getting it wrong is worse than not having it, as forcing people to contribute to the core, where everything can be tested and released together, has a tyrannical elegance to it. But if plugins are The Future, having them be robustly verifiable, testable, documented, and dogfooded can work.

Some ideas (maybe for here, maybe as POEM, which I can't guarantee being able to shepherd):

  • for each thing to make pluggable (it doesn't have to be one big PR)
    • introduce a versioned entry_point which an extension author can implement in setup.(py|cfg), e.g.
      [options.entry_points]
      openmdao_solver_v0 = 
          foo_package_foo_solver = foo_package.solver:FooSolver
          # or
          foo_package_solver_foo = foo_package.solver:get_solver
      • there are other approaches, but this one's built-in
    • refactor all existing implementations of the current pluggable to also use those entry_points e.g.
      [options.entry_points]
      openmdao_solver_v0 = 
          openmdao_solver_scipy_krylov = openmdao.solvers.linear.scipy_iter_solver.ScipyKrylov
          openmdao_solver_newton = openmdao.solvers.nonlinear.newton.NewtonSolver       
          ... 
      • this is important, if only for there to be non-trivial examples
    • hoist the base that FooSolver would implement to api.py with implementation-free, heavily documented, versioned ABCs, e.g. so Solver(SolverABC0)
      • better than "just" more docs are PEP 484 annotations
        • ...but only if tested in CI
    • add a (tested) tutorial documentation for each plugin type
    • at runtime, load them all with pkg_resources.iter_entry_points
      • this is a little slow
      • using entrypoints is slightly faster
    • consider getting a versioned trove classifier for pypi, and encourage developers and end users to use it
ROADMAP.md Outdated
### Potential Challenges:
- Current user interface is stretched to its limit, and can't
integrate any expanded navigational features. We'll need a new concept
for the UI

This comment has been minimized.

Copy link
@bollwyvl

bollwyvl Oct 25, 2019

Contributor

Proposed: JupyterLab extension. Some options exist:

  • the ipywidgets road, a la cadquery which would work with more clients
  • a more "native" integration (not many public examples of really extreme customization... yet)

The end-user nodejs dependency can be avoided by distributing a CI-built (and tested) jupyterlab application on pypi/conda, either as part of the core, wholly-separate as openmdaolab, or half-way (for pip) with openmdao[lab]. We stopped just short of doing pypi releases of robotlab, but then went and built 700mb installers. Having full working installers with all the bells and whistles is not a terrible idea, but just-the-lab is likely more useful in this case.

ROADMAP.md Outdated
- Make it simpler for users to inspect, navigate, and plot data from the case recorder

### Potential Challenges:
- Going to be a separate stand-alone application. Will users be willing to download separate app?

This comment has been minimized.

Copy link
@bollwyvl

bollwyvl Oct 25, 2019

Contributor

See Lab comment above.

ROADMAP.md Outdated
# Model & Data Visualization

Motivation: Provide tools that make it easier to quickly build and debug complex
models with 100's of components organized into 10's of groups in 10's of hierarchy layers

This comment has been minimized.

Copy link
@bollwyvl

bollwyvl Oct 25, 2019

Contributor

Proposed: cytoscape+elk, potentially running in JupyterLab (comment). Example with a linked data grid viewer.

ROADMAP.md Outdated
This update will **NOT** represent significant change to the codebase or functionality,
but will include several small but important practical changes:

## 1) Dropping support for Python 2.0 and supporting only Python 3.6 and greater

This comment has been minimized.

Copy link
@bollwyvl

bollwyvl Oct 25, 2019

Contributor

Proposed: add PEP 484 typing, and test in in CI. Can play nice with sphinx, actually reducing docs burden.

JustinSGray added 2 commits Oct 25, 2019
suggested edits to roadmap
@hschilling

This comment has been minimized.

Copy link
Member

hschilling commented Oct 25, 2019

Change

Dropping support for Python 2.0

to

Dropping support for Python 2.X

JustinSGray added 5 commits Oct 25, 2019
2.x
@swryan
swryan approved these changes Nov 4, 2019
=================================

Author: Justin S. Gray
Date: 2019-10-24

This comment has been minimized.

Copy link
@swryan

swryan Nov 4, 2019

Contributor

should this date be changed to reflect that it's post-workshop?
(or an additional revision date)

- This process is loosely based on the model used by cPython project (the PEP process).
- A new repository has been created for tracking POEMs (http://github.com/openmdao/POEMs).
- We are planning to work the POEM process on PR 1086 (https://github.com/OpenMDAO/OpenMDAO/pull/1086).

This comment has been minimized.

Copy link
@Kenneth-T-Moore

Kenneth-T-Moore Nov 4, 2019

Member

Do we need to work a poem on something that is destined to be a plugin? (or perhaps it isn't)

- Provide forward and reverse mode AD that works for a wide variety of general use cases including
with many numpy functions.
- AD should have relatively good performance compared to hand differentiation.

This comment has been minimized.

Copy link
@Kenneth-T-Moore

Kenneth-T-Moore Nov 4, 2019

Member

compared -> comparable (i assume you are saying that AD will almost be as fast as hand differentiation, not that AD will be faster.)

@swryan swryan merged commit 32ed4f6 into OpenMDAO:master Nov 6, 2019
2 checks passed
2 checks passed
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.