2020-09-23 Wagner Thompson BSSW planning Meeting notes

Rubric?

• Starting point: https://bssw.io/pages/apply-for-the-bssw-fellowship-program

  • an activity that promotes better scientific software.

  • We encourage emphasis on activities with a view toward broad impact, with some element that could serve more than a single set of people attending a single event

• Who should apply:

  • Passionate about scientific software.

  • Interested in contributing powerful ideas, tools, methodologies, and more that improve the quality of scientific software.

  • Able to use the fellowship to broadly benefit the scientific software community.

  • Willing to participate as an alum in subsequent years to guide selection of future fellows and promote better scientific software in their community.

  • 1 application/person (no teams)

• Review Criteria

  • The proposed work is relevant to scientific software and can benefit the DOE, ECP, and broader HPC and CSE communities

    • https://bssw.io/communities/exascale-computing-community

    • https://bssw.io/pages/intro-to-hpc

    • https://bssw.io/pages/intro-to-cse

  • The proposed work is well-scoped and likely to be accomplished

  • The proposed work has broad impact that spans beyond a single community/event and is sustainable beyond the fellowship period of performance

  • The proposer has a passion for scientific software and the relevant background to accomplish the proposed work

  • The proposer will be a long-term advocate for better scientific software beyond the fellowship period of performance

• MT – “Interesting that ultimate granting agency is DOE”

Who?

• Should we both apply?

  • JW – Would be happy to have accolades under my name on my CV, and do most of the work

  • MT – I’d be happy to submit an application, especially if it increases our chances of landing the award for our org

• How distinct should applications be?

  • What happens if two identical or similar applications are sent in? Bad or “bad but everybody does it?”

  • JW – We should prepare applicaitons effectively in isolation from each other, though we may overlap if we both copy the “purpose” paragraph from website.

Which projects?

(bolded are the top 5, numbers are rough grades out of 10)

• CMILES webserver / QCSubmit advertisement (basically things that improve QCF usability in our subfield) 8

  • Offer to TG / DD, somehow loop in JH / HJ?

• Expanding QCF out of just QC, i.e. DFT, MM, ML 9

  • Same as above

• Automated detection of “bad” parts of force fields / Really robust FF comparisons/benchmarking 8

  • Same as above

  • JW – A bit limited in scope – might be seen as too SMIRNOFF specific

  • MT – If the format becomes popular, this scope naturally widens.

• Some sort of fitting infrastructure (performance optimization of or alternative to forcebalance) 5

• Grander build/release/testing automation for conda-reliant infrastructure 6

• “grading” of automated docs, via assessing completeness, linting, etc. 3

• Something clobbering of of MD operations onto a NumPy-like API so other packages can “get MD for free” once potentials are defined

• Better tutorials for intaking ligand+protein structures 9

  • Broadly applicable – Find conda installable tools + pathways to prepare simulations and correct a variety of info content / format problems

  • JW will do this

• Broad advertisement of System object for interoperability 7

  • Some docs, some outreach, money will go toward formally engaging other simulation communities. Effectily, in return for the money, this will dedicate 25% of one year time for documentation/examples

  • MT will do this

• Something about growing contributor community, in the face of secrets like OE license and steep learning curves 6

  • Use 25k to “subcontract”/”bounty” features?

  • Methods for onboarding new remote contributors from earlier in the education pipeline or from different economic circumstances in a mutually beneficial way

• Guide to SMARTS based FFs / slots / how to add parameters etc 5

• “Lessons learned” series about academic/industry consortium 7

• Broaden adoption of CI/CD/MolSSI cookiecutter 3

• Something about API stability, internal file versioning, holding to “contracts” with users, best practices for releasenotes about API breaks/behavior changes 6