nanomfg / velp

Virtual Exfoliation in Liquid Phase

MA-VELP

Machine-learning Assisted Virtual Exfoliation via Liquid Phase

Python codes are located in the src/mavelp directory:

1. data_tool.py : manages file reading and data management
2. gui.py : graphical user interface supports user interface and communication between various codes
3. kernel_method.py : kernele ridge regression is implemented for MAVELP dataset and used for fitting, prediction and score, additionally it supports optimization
4. neural_network.py: neural network based regression is implemented to train NN for MAVELP dataset, addtionally it supports optimization of solvent composition

Data are located in the data directory:

1. data.dat : data for MA-VELP

Usage:

• Access the live application at https://nanohub.org/tools/mavelp
• To install locally, see Installation (below)
• Launch MA-VELP-App.ipynb to have access to the GUI

Future Release Note:

• We might move optimization to a separate code
• Pip installation seems like a good option
• Python test

Installation

Manual python install for testing

pip install -e .

Jupyter Notebook Testing

• clone or otherwise upload the repo to you nanoHUB workspace. Be sure to checkout the appropriate branch.
• Run make install in /src directory
• Launch the Jupyter Notebook tool: https://nanohub.org/tools/jupyter
• open MA-0VELP_App.ipynb in /bin.

nanoHUB Testing (Workspace)

Install to ./bin using makefile in ./src

$ cd src
$ make distclean
$ make install

Test by launching the jupyter notebook tool on nanohub.

Versioning

Version numbers are based on the SemVer versioning convention. For the versions available, see the tags on this repository.

Versions are incremented each time the devel branch is merged to master and/or anytime a development release is desired for testing. Increment versions using a dedicated git commit of bumpversion changes.

All bumpversion commands run from the top directory of this repo.

Show current version setting:

$ cat VERSION
$ 0.0.0

Increment a "build" release: 1.0.0-dev0 -> 1.0.0-dev1:

$ cat VERSION
$ 0.0.0
$ bumpversion build

Bump2version is used to increment the version and apply tags. The basic setup used here follows the guidlines illustrated here. All version bumps should happen on a clean working copy of the repository, after the last commit for that version has been pushed. The push of the the bump2version changes will comprise the version. Relavant files

.bumpversion.cfg
VERSION
src/gsaraman/__init.py
setup.py

examples Create initial testing release for upcoming #.#.# :

velp's Issues

Document System Environment and Known Constraints

Summary

Identify the relevant factors that will affect your software on in the target environment. Update section 2.3 with any new constraints.

Details

Use this activity to review and accumulate knowledge about the target environment.

• Known constraints of the target operation environment (nanoHUB)
• Factors affecting installation, runtime behavior etc.

References

None yet.

Abstract

Darren, where should I write the abstract? @dadamsncsa

Complete Phase 2 Planning

Summary

Track progress on Phase 1 activities here. Submit SPD for review when completed

Details

Note, To see enhanced features for this (and other) issues refer to the Zenhub documentation link below.

• Submit SPD draft with all phase 2 activities.

References

Instructions to Create SPD from Template
Submitting SPD Updates for Review
Adding ZenHub Extensions

Add License Documents

Summary

The nanoMFG node encourages contributions to the open source community. Open source contribution give our project a chance to have a larger impact and build a community of users and contributors. A first step in preparing for an open source release is to choose a license add the necessary documentation to your project.

Details

Apache 2 is the default license choice for nanoMFG projects.

• Choose an open source license. Add a LICENSE file to your project using the GitHub interface.
• Add a COPYRIGHT file.
• Add an AUTHORS file
• Update License section of Project README.md

References

starting and open source project
adding a license to a repository

Identify Potential Users

Summary

Identify classes (types) of users that you anticipate will use the product and document them in section 3.1 of the SPD. Provide any relevant context about each class that may influence how the product is used.

Details

Consider the following criteria when classifying potential users:

• The tasks the class of users will perform
• Access and privilege level (if relevant).
• Features used
• Experience/knowledge level
• Type of interaction (education, research, other...)

Provide links to and/or summaries of any user surveys, questionnaires, interviews, feedback or other relevant information.

References

Create Issues for Planned Activities

Summary

Develop a set of issues needed to complete the activities planned in Phases 1 and 2. Add these issues to the Complete Phase 3 Activities Epic issue.

Details

Document the work that needs to be done including:

• Code development
• Writing Tests
• User outreach
• Documentation
• Other

Add finishing touches to your issues:

• Apply appropriate labels for each issue (create new ones for your project if needed).
  • This could include a "help wanted" label and/or @mentions to solicit help from others in the node.
• Assign issues to the right people
• Use task lists to detail more granular steps to complete the issue

Organize your Board

• Once issues are ready to go, drag them into your Backlog pipeline.
• Order by priority
• Use a milestone to set target completion dates for sets of issues
• Assign and drag to In Progress.

References

Update Project Goals and Mission Statement

Summary

Develop or review your project goals and mission statement in sec 1.1 of your SPD draft.
.

Details

Add a concise mission statement and summarize your project goals

• Why are we building this tool?
• What is the key benefit?
• How does this tool relate to existing tools and existing software?
• How does it fit into the overall objectives for the nanoMFG node?
• Who will use it?

References

Provide Summary and Team Info for Next Release

Summary

Begin a Software Planning Document (SPD) and provide project information for the next upcoming release. The preliminary project information described in the checklist below should go into the subtitle and section 1 of the SPD. In this planning task you will:

• Create a draft SPD from the SPD template.
• Add requested information and commit a new document to a separate branch of your project repository.
• Open a pull request to merge your new document into doc/SPD on your project repository's planning branch.

Details

Only the following SPD items are required for this issue:

• Title and (short)name for the software project (tool).
  • The "short name" should be the same as will be used for short name on nanoHUB tool page.
• Documentation for team members
  • Please provide names platform usernames, project roles and current status for all team members
  • Use the provided table in the SPD template to document members of your development team.
• Version number to be used for the next release(eg 1.0.0) and an approximate target date for the release.
• GitHub nanoMFG org. team names.
• nanoHUB group names (if applicable).
• Brief synopsis/abstract to outline this release under "Introduction".

Once a pull request is opened, the nanoMFG @dev-review team will review the document and issue any feedback to the pull request and/or this issue. Refer to the links in the references below for detailed instructions on creating and submitting an SPD revision.

References

Instructions to Create SPD from Template
Submitting SPD Updates for Review

Complete Phase 3 Activities

Summary

Use this issue as a container for all planned phase development activities planning in phases 1-3. In addition to nanoMFG activities, add your planned activities to this Epic. Upon completion, update section 2.2.2 "Release Notes" of the SPD with the version # and completed activities, then submit for review.

Details

• If this issue is used as a tracking (Epic) issue, you can just add a link to this issue in the SPD, along with notes on any other relevant activities or features added.
• Submit the updated SPD wit hrelease notes for reveiw:

References

submitting SPD updates for review
getting started with Epics

Develop a Testing, Verification and Validation Plan

Summary

Develop or revise a set of planned activities for testing validation and verification of the application in sec 4.3 of the SPD. If no testing activities are planned for this release, indicate as such in sec 4.3 and provide any context/status and/or future plans/timelines.

Details

Each tool is required to (at a minimum) develop tests to verify the correct functionality of core functions and/or the entire application and provide documentation on how to run them.

Create an issue for each planned activity in your repository and provide a list of links to them in sec 4.3 of the SPD along with any other relevant context and/or explanation. Use task lists in the issue to list more granular sub-tasks.

Planned activities may include (but are not limited to):

• Identify data sets to serve as validation and/or verification
• Identify critical functions to be tested
• Implement specific tests
• Refactor application code to allow testing
• Collect validation data
• Document inputs and expected outputs for validation
• Adopt a unit test framework
• Integrate Travis CI automation

References

PyUnit
python testing style guidelines

Develop a Documentation Plan

Summary

List the planned components of the documentation for your project in section 3.4 of the SPD. If already completed, indicate version in which it was completed. Revise if necessary.

Details

List planned documents and develop conventions for maintaining them. Update you CONTRIBUTOR guidelines if needed to communicate desired documentation practices with your team
Some Documents include:

• In code documentation conventions and requirements
• In-app documentation for users
• Web documentation
  • nanoHUB web page
  • GitHub README.md
  • other webpage (github pages etc.)

Create issues for any specific documentation tasks using the documentation issue template.

VELP crashes when I try to run it.

Describe the bug
I get a python error when I run - see screenshot below.

To Reproduce

1. launch code from main page
2. go with default materials (cations: BPY; anions: TF, TFSI), and click 'click after materials selection'
3. keep default methods on 'Methods' tab (no changes)

4. on design tab, stick with defaults and click submit.

Expected behavior
I'm not sure exactly what should happen, but pretty sure it is not this!

Screenshots
See attached

Additional context

• I don't think the problem is that I'm not choosing the right number of anions -- there are two selected, as far as I can tell.
• Even if I am incorrectly setting the simulation parameters, the user should see a warning message and be asked to fix their selection -- not crash out.

Complete Phase 1 Planning

Summary

Track progress on Phase 1 activities here. Submit SPD for review when completed

Details

Note, To see enhanced features for this (and other) issues refer to the Zenhub documentation link below.

• Submit SPD draft with all phase 1 activities.

References

Instructions to Create SPD from Template
Submitting SPD Updates for Review
Adding ZenHub Extensions

Draft and Update User Requirements

Summary

Develop and/or revise the set of user requirement issues for your project. List links to the issues in sec. 3.3 of the SPD. A template to create a user requirement issue has been added to your repository. A well written user requirement should be easy to justify (Rational) and should be testable.

Details

User requirements should be "user facing" and serve as top-level drivers for other development your project. Not all iterations through the development phases will generate additional user requirements. A good strategy for the first planning pass is to determine a set of user requirements that comprises a minimum viable product (MVP) and label them as must have.

• Create issues for each use case using the User Requirement issue template.
• Review draft use case with your team and refine their descriptions.
• Label each issue to indicate the priority as either: must have, should have or nice to have.
• Update section 3.3 of your SPD with a list of links to each issue.

Note: If no user-facing updates are planned for this iteration indicate as such in Sec 3.3.

When planning specific development activities, refer back to user requirements when appropriate.

References

Requirements Checklist

Review GitHub Accounts and Team Membership

Summary

Review GitHub account details for team members and create a project development team. A GitHub team should to be created for each group of collaborators developing one or more nanoHUB tool(s).

Details

Note: this is best completed by the project PI and/or repository admin (creator).

• If possible, ask all of your team members to update their GitHub profile to include: full name, email and home institution.
• Create a GitHub team using all of your project team member's GitHub accounts (including the PI's) in the nanoMFG organization (see below).
• Add your project repository to the team.

References

Here are GitHub's docs on teams:

• about teams
• creating a team
• team access to repositories

Exception thrown on prediction run

Describe the bug

Tool crashes when "prediction of solvent performance" "run" button is clicked using default parameters
To Reproduce

• Keep default parameters
• run jupyter notebook and run predict model
  Expected behavior

Exception thrown:

Molar frac. :  1.0 

---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
~/devel/VELP/bin/mavelp/gui.py in click_button(b)
    474                         if Materials[i][:-1] ==self.AnionCell.value[cnt]:
    475                              x[i] = np.round(self.Prediction_Box[cnt+len(self.CationCell.value)].value/sum_molar_an,3)
--> 476                 print(" Predicted PMF : ", self.ml.kr_func(x)[0][0])
    477 
    478         self.Prediction_Box[-1].on_click(click_button)

AttributeError: 'tabs' object has no attribute 'ml'

Screenshots

Additional context

Develop Contributer Guidelines and Procedures

Summary

Develop or revise your project's set of Contribution guidelines, standards and procedures. Indicate any applicable activities as comments below, and/or reference this issue in any relevant commits before closing this issue.

Details

Update policies and guidelines in a file named : CONTRIBUTING.md and link to this document somewhere in README.md. Review and/or update these practices with your team as you begin this iteration coding and construction activities.

• Version control practices
  • Conventions on using branches and pull requests
  • Issues and issue tracking for your project

•Conventions for using issue tracking

• Explanation of use of labels
• Description of Issue Templates or kind of issues to submit

•Coding conventions including style guidelines for each relevant programming language

• Conventions for writing and running tests
• Conventions for documenting new features
• Acceptance criteria for API changes

References

More to come...

calculate accuracy of predicted parameters for reproduction of structure

Description

In order to evaluate the predictive capability of a deep learning network , as force field developer, I want to calculate accuracy of predicted parameters for reproduction of structure.

Rationale

Receive feedback for model system to direct future development.

Test Criterion

Compare target and output RDFs.

Additional Notes:

Attach a requirement type label and priority label and add notes/questions here.

Plan User Outreach Activities

Summary

Determine efforts directed at eliciting user feedback. Update section 3.5 of the SPD with planned activities.

Details

As for other activities, create issues for specific activities. For other, more general efforts document the plan in section 3.5.

• Reaching out to specific lists of users
• Conducting surveys
• Data collection (eg. for validation)

References

Document Software and Architecture Components

Summary

Identify the major components of your system whether they be functions, databases, models, etc. Provide and overview as an introduction to section 2 of the SPD

Details

A good way to document this is with a flowchart or high level diagram. Add a brief synopsis of how that major planned activities fit into this architecture.

References