We want to be able to connect to a specified Open Chemistry server using the server URL for public API/searches, and a username/API key for privileges endpoints. This can be used with a local JupyterLab instance, or central resources such as those provided at NERSC.

The current state is that endpoints such as molecules, calculations will return all elements in the database which will not scale, or they can search on name, inchi etc. Our search capabilities are also quite limited at present. I would say on the backend we want to support search with some common features across our different collections/endpoints:

• Automatically limit to 25 search results
• Ensure returned data is useful, but not too big
• Support for changing the limit
• Support for specifying an offset
• Support for ordering by parameters (default to most recent first)
• Support for changing the sort order/direction

The returned data should follow a similar pattern too, with a JSON object containing high level summary of the results, and a results array containing result objects:

{
  "matches": 42,
  "limit": 2,
  "offset": 0,
  "results": [ { ... }, { ... } ]
}

I think we need to work on extending our concept of users to include some useful data such as ORCID, Twitter username, etc that can be set publicly so that you might search on a name, ORCID, etc to see results for that person in molecules, calculations, ... There are a few things we should try and get working in search too, including queries like USER AND heavy atom count = 10, > 10, etc. Same for molecular weight, formula, InChI, InChI key, SMILES.

I think starting with molecules search is good as it is simpler, then calculations doing things like calculations run by Marcus using NWChem or Psi4 sorted by most recent would be good to think about. These should come after the card stuff, and it likely needs further discussion but writing down some ideas.

Previous work featured a card view:

and a table view:

We need some equivalents for displaying results to searches, and should look at possibilities for 3D structures that summarize a sequence of results. I think we need to think about this for the single page interface, and also what we can do within Jupyter.

JSON object communicating high level success/failure. Access to errors, warnings, etc from the Jupyter Python kernel APIs.

Inputs, APIs, and data flow for machine learning tasks.

Export triples for InChI, energy, SMILES, push to Jena triple store, expose as an endpoint.

In order to be able to do this, I think we will need to modify a little bit of our calculation workflow. @alesgenova can correct me if I'm wrong about any parts, but I think this is what happens:

1. Before the docker container runs, a calculation is posted to the calculations collection. This calculation contains a single molecule ID and most of the needed input. It is considered to be a pending calculation.

2. A taskflow is created using information from this calculation. It gets the molecule information via the molecule ID, converts it to the format needed by the docker container, and also gets the input from the calculation. The docker container is then ran for this single molecule.

3. When the docker container is finished, the output is written to the calculation and then put back into the database (overwriting the original calculation used for the input).

4. When a user tries to run a calculation in the future, it checks to see if a calculation already exists that used that moleculeId, input parameters, and docker image (to avoid re-running the same calculation).

In order to, in general, be able to run multiple calculations in a single docker container (such as running multiple SMILES through chemml), I think we'll need to modify this workflow.

How? I'm not quite sure yet. But I have one proposal at least: what if we make it so that a calculation can have a list of molecule IDs instead of just a single molecule ID? And then the single docker container can run the same input parameters on all of the molecules in the list in one go.

Thoughts, @alesgenova, @cjh1, and @cryos?

I was just taking a look at the new deployment, and thought I would point out a few issues I saw as I was using it.

• Pasting in a link from a view I was looking at results in a 404, e.g. here
• The menu on the visualization for that page (or any of the menus on the visualization widget) is broken, just shows text but no actual menu
• Need user API key management piece

I think that is all I have for now, it would be good to get both working soon.

This collection would always have a parent molecule, and have one geometry, with optional provenance, i.e. from calculation a, generated from InChI using Open Babel, from structure resolver, etc.

Plotly and bqplot offer significant out of the box functionality for standard plots in notebooks. We should integrate some examples of their use, especially for simple plots where we just want to display scatter plots, bar charts, etc. This likely involves adding some optional dependencies, and ensuring they are present in our demonstration installation.

Adding new API to input SMILES, InChI, upload geometry from the single page web interface, or from an Avogadro plugin.

Add new collection for experimental spectra, and visualization comparing simulation with experimental.

Thinking about what the execution of jobs should look like, specifying that out and linking to the relevant pull requests.