All the metrics for the reference set so that analysis can be performed using external software

Check to see that the structure file that was submitted contains valid input for the various programmes. @MichaelJamesStam has started this with the find_disallowed_monomers function in big-structure/src/destress_big_structure/analysis.py.

Maybe this is the wrong approach and we should return what type of molecules are in the PDB rather than to exclude everything except protein.

The plan for the open beta is not to have server side storage of designs. A limitation of this approach is that you can't share design metrics very easily. A solution to this is the ability to export design data to a text file. There's a couple of varieties of export that I'm interested in:

1. A text dump of the designs that can be loaded back into another instance of the application.
2. Nicely formatted data on the designs/reference sets that enables people to creat plots in external software.

We haven't added the new metrics as optional requirements in specifications. This will need to be done retrospectively for EvoEF2, but should be incorporated into the PRs for the other methods (#28, #29, #30).

In summary:

• docker compose instead of docker-compose
• docker container created by docker compose is named "de-stress-big-structure" not "de-stress_big-structure"
• wrong .env file given in the last docker run command

Leading to fixed commands:

1. docker compose -f headless-compose.yml build
2. docker run -it --rm -v /absolute/path/to/de-stress/dependencies_for_de-stress/ de-stress-big-structure:latest sh build_dependencies.sh
3. docker run -it --rm --env-file .env-headless -v //absolute/path/to/de-stress/dependencies_for_de-stress/:/dependencies_for_de-stress -v /absolute/path/to/input_path/:/input_path de-stress-big-structure:latest poetry run headless_destress /input_path

I think that this would be useful when creating more complex specification, to have some simple specifications that you can combine into more complex specifications.

I converted the composition plot to stacked bar charts to save space without realising that the results would be aggregated.

EvoEF2 hangs for two PDB files, 2ht0.pdb and 4dyq.pdb. For 2ht0.pdb, some nan values are returned when running EvoEF2 from the command line. This could potentially be causing a problem as DE-STRESS hangs on "Job is running on server". On the other hand, running EvoEF2 on the file 4dyq.pdb from the command line, causes a segmentation fault. On DE-STRESS, it hangs on "Job submitted to server".

We currently have issues with the Vega Lite plots not rendering correctly. I think that there are a couple of routes to fixing this:

1. Change the VL javascript code to be a custom element that manages it's own state and updates automatically based on changes in Elm.
2. Use another library for plotting, preferably one that is Elm native.

I think that option 2 is probably more future proof and will enable tighter integration between the plots and the application, more control over the formatting of the plots and clearer code, mainly due to not having to use Vega's DSL to create plots. The disadvantages are that we're duplicating work we've already done, but we have a fair amount of overhead fixing these plots after every update.

A ValueError keeps getting printed to the console every time the web socket is checked. I am not sure what is causing this but it could be related to the recent changes in the pull request Fix: Changes the way that WSs are polled to fix timeouts. #15.

Generate plots comparing a whole batch of designs and the reference set in a separate page.

In a previous update I added webpack to bundle our javascript resources, but really slows down the page load. I'm going to move back to getting the JS dependencies from a CDN.

These can then be incorporated into Github actions so that the automatic tests can work.

A function in analysis.py needs to be added to run the DFIRE2 energy function on pdb files.
An object needs to be added to elm_types.py and big_structure_models.py.
The schema.py needs to be updated and create_entry.py.
Finally, Metrics.elm and Uuid_String.elm need to be updated to display the energy values.

It is currently full width.

• Resolution for big structure
• SS proportion
• Radius of gyration or some shape information
• BUDE-FF

As we're getting closer to release, we need to try to deploy the application on production hardware. To do this, we need to:

• Remove the usage of Debug from the Elm code so that we can compile with --optimize
• Set-up Nginx reverse proxy
• Setup static file server for the front end
• Create deployment script

Currently there is only summary level data that is shown for aggrescan3d but residue level data is captured as well. We could make a plot to show residue number vs aggrescan3d score to show these results to the user.

We need to purchase a shorter domain name before publication, maybe de-stress.app. The default domain is pragmaticproteindesign.bio.ed.ac.uk/de-stress and the new domain will just forward to this location.

We're downloading more data than we need for the reference sets, we probably don't need any of the log information or even the detailed score breakdown. If we remove these fields, we should be able to have much larger reference sets. Another thing we should do is download data to create a reference set in batches, so that the http request does not time out.

We should make the logging on the server a bit more deliberate. Switching from print statements over to using the logging module is a good idea. This article gives a nice overview: https://towardsdatascience.com/stop-using-print-and-start-using-logging-a3f50bc8ab0

Currently, if you click a reference set, there isn't much information about it contained in the page. I'd like to add:

• Overview plots
• Information about the number of designs
• A way to view the names of files in the reference set
• A way to export the stats of the reference set

DE-STRESS UI and headless

Using the selection tools, it is possible to make a new reference set from the structures uploaded by the user, enabling them to use unpublished PDB files.

A function in analysis.py needs to be added to run the Rosetta energy function on pdb files.
An object needs to be added to elm_types.py and big_structure_models.py.
The schema.py needs to be updated and create_entry.py.
Finally, Metrics.elm and Uuid_String.elm need to be updated to display the energy values.

I broke this a while back in the design detail pages, I need to fix it before release.

We recieved comments from the reviewers of the DE-STRESS submission to PEDS that we need to have a clear glossary of the metrics used in the application.

Currently the 1th biological unit is labelled as preferred if none is defined, and it should be the 0th.

I was uploading some pdb files of antibody structures to DE-STRESS and noticed that a fair few gave the error "Server error while creating metrics: The job failed to run: None". I checked the log and it looks like a key error with DSSP and maybe happening in ampal/assembly.py. The PDB file 5XRQ.pdb gives the key error 'AA' while the pdb file 5UBY.pdb gives the key error 'AH'.

We're using collapsible sections in a couple of places now (/designs and EvoEF2 results on /designs/uuid-string), so it makes sense to make these have consistent formatting and replace the temporary styling. The generic code should be moved to Style.elm.

One of the most obvious requirements that someone would want to set is to say that a metric must be within a given range relative to a reference set. A couple of thoughts on this:

• Should be able to set in std devs or %age
• Should convert to a raw value so there is no dependency on the reference set after the specification is created

Would be good to thank the authors of the tools too

Some of the basic metrics like hydrophobic fitness and the secondary structure assignment don't have any explanations or pop ups at the moment. We need to provide a bit of info to explain to the user what these fields mean.

I don't think that this is working at the moment, I'm not sure if the reference set is being used to calculate it.

The automated testing is currently broken, although the Python tests are passing on my system when running in the big-structure Docker container. The elm tests are also failing. After this fix, no PR that fails the tests should be merged.

Currently, a user could dump 1,000 structure files with 1,000,000 residues each into de-stress and the server would fall over. Although I trust our future users, it's probably not ideal behaviour. There are a few ways that we can tackle this:

1. Limit the number of files that can be running on the server for an individual session
2. Limit the number of residues allowed in a structure file
3. Add a time limit to individual jobs running on the server

These are not mutually exclusive and I think we should probably use all of these.

A function in analysis.py needs to be added to run Aggrescan3D on pdb files.
An object needs to be added to elm_types.py and big_structure_models.py.
The schema.py needs to be updated and create_entry.py.
Finally, Metrics.elm and Uuid_String.elm need to be updated to display the output.

All errors that should be displayed to the user should be routed through Shared.elm and displayed at the top level.

The sequence view on Designs/Dynamic does not show non-canonical amino acids. This must be a server side problem as the front end does not determine the sequences, they are returned with the design metrics.

Once the metrics for the beta have been finalised, we need to build the full version of big structure on lilis.

The BUDEFF record does not return any information on fail. It would be nice to return something to the user!

These files don't load but there is no message to the user to tell them what has happened.

These pop ups will be useful to provide extra details about the energy values from EvoEF2 and Rosetta. At the moment they have more human friendly names, but we should allow the user to see the original names from the energy function output.

EvoEF2 produces a file called _weights.txt as it is running, what is this for? Do we need to return it to the user? Is it used as a cache?

I imagine that lots of people will test it, or include, structures from the PDB. As all the metrics have been precalculated and cached for these structures, it makes sense to have a separate input method for these so that we don't recompute them every time. I don't think this is super high priority, so I'm not putting it into the v0.1.0 milestone.

.env-headless file needs HEADLESS_DESTRESS_BATCH_SIZE defined. E.g.:

POSTGRES_PASSWORD=testpassword

GUNICORN_WORKERS=2
APP_PORT=8181

EVOEF2_BINARY_PATH=/dependencies_for_de-stress/EvoEF2/EvoEF2
DFIRE2_FOLDER_PATH=/dependencies_for_de-stress/DFIRE2-pair/
ROSETTA_BINARY_PATH=/dependencies_for_de-stress/rosetta_src_2020.08.61146_bundle/main/source/bin/score_jd2.linuxgccrelease
AGGRESCAN3D_SCRIPT_PATH=/dependencies_for_de-stress/Aggrescan3D/aggrescan3D_cli_run.py

RQ_DASHBOARD_REDIS_URL=redis://redis:6379
RQ_DASHBOARD_PORT=8182

MAX_RUN_TIME=200
HEADLESS_DESTRESS_WORKERS=3
HEADLESS_DESTRESS_BATCH_SIZE=10