openfreeenergy / openfe Goto Github PK

As discussed with @dwhswenson the current visualization for atommappings fits our purpose but could probably be spruced up.

Potential things we should look into doing:

• add a py3dmol backend so we can see atom mappings more easily
• reformat the unique atoms / elements lists so they can be used by other backends
• rename the d2d arguments as necessary

Holds 2x Molecule and 1x AtomMapping

As far as I understand mcs.all_atom_match_list currently dumps out a "list-as-a-string" which we are having to turn into a dictionary internally.

I think for the sake of "making things better for folks that might use lomap" we can just upstream that?

It would be a lot easier to just let versions be handled automatically, how do we feel about setting up versioneer?

Current atom mappings are probably heavy atom only, create a method which creates a new AtomMapping with hydrogens included (and reverse route, drop hydrogens)

I think we should follow NEP 29 when we can (I know a lot of upstream packages are slow on the 3.10 support) but it would be nice to not have to support anything older than python 3.8. I'd also like to avoid support windows if we can, and just focus on Linux and OSX support.

Should be a read only simple data class holding enough information for mapping two sets of ints (atom indices) to each other...

class AtomMapping:
    AtoB : dict[int, int]
    BtoA : dict[int, int]

Lomap outputs a file, we should convert from that into a Network as best as possible.

There's some nice test data sets in Lomap and it's MIT licensed too. Let's go nab them, and have a quick readme on what's inside.

Should eventually have a build on the CI which is only required dependencies (i.e. no oechem, but things still work)

depends on #20

Create a basic CLI framework that can be used with subcommands.

Would be nice to be able to ingest an AtomMapping object from perses

m = openfe.AtomMapping.from_perses(perses_atommapping)

Essentially we'd want our own version of what perses does here: https://github.com/choderalab/perses/blob/a8b490af0e4682082dfa442717ef45c1bd61f538/perses/rjmc/atom_mapping.py#L183-L310

See here for perses notebook: https://github.com/choderalab/perses/blob/master/examples/atom-mapping/Atom-mapping.ipynb

Use case: "I'm sitting in a notebook and I want to cycle through my atom map and see what's going on in each edge".

Scorers from lomap.mcs.MCS to port:

• mcsr
• mncar
• tmcsr
• atomic_number_rule
• hybridization_rule
• sulfonamides_rule
• heterocycles_rule
• transmuting_methyl_into_ring_rule
• transmuting_ring_sizes_rule
• the matrix score, which is a product of all(?) of the above

Note, Lomap uses a score where 1.0 is "good"/viable and 0.0 is bad. We use weights where 0.0 is good and larger scores are less good. Can use 1 - lomap to get same effect?

Please add as desired / tick off as sorted out

We need:

• basic setup.py / setup.cfg / pyproject.toml
• basic directory structure
• license (thanks @richardjgowers !)
• README.md
• environment.yaml?
• dummy workflow in .github folder? (just an action that tests nothing should be fine?)
• pep8speaks?
• coverage / codecov
• linters? (linting will be kept local for now)
• CONTRIBUTING

From a Network containing ligands, add a protein and solvent to get out a network description.

Waiting on #89

The task of generating a mapping between two ligands is done by an AtomMapper which generates an AtomMapping

There is an abstract base class for defining how an Atom Mapper should function here:

https://github.com/OpenFreeEnergy/openfe/blob/main/openfe/setup/ligandatommapper.py#L10

There is an Atom Mapper in perses here we could assimilate:

https://github.com/choderalab/perses/blob/main/perses/rjmc/atom_mapping.py#L543

Follow-up from #19

This will need working upstream with the OMSF folks, we'll probably need to consider things like CLA and maybe an OMSF-wide CoC policy?

Sorry don't have time to get the full trace again, but this throws some index errors in the visualisation code paths:

# load a new network from this graphml representation
with open('network_store.graphml', 'r') as file:
    network_data = file.read()
    
new_network = Network.from_graphml(network_data)

# should trigger a display of the first edge
[edge for edge in new_network.edges][0]

In discussions, we've agreed that we want a documentation setup that is mostly based on Jupyter notebooks, with some room for additional RST files and the ability to get good autodoc API generation. A lot of this can be seen in the documentation for Contact Map Explorer, source here. Most of the hard work is done by nbsphinx.

The tricky part: notebooks need to be in the sphinx docs/ directory

We need to get the notebooks into the right place in the docs tree, so that nbsphinx can find them. In contact_map, the notebooks are in the repository, and this is done by copying with shutil in the conf.py. However, we don't want to include the notebook repo with the main code.

In OpenPathSampling, I wrote a script to copy files into the sphinx docs directory from any of local file, GitHub repos, or GitLab repos. It is based on a YAML input file, and so requires pyyaml to be installed in the doc building environment. It also must be run as a script before building the docs.

Neither of these are perfect for us, but I think that together they can be pieced into a good solution. Ideally, our solution would:

1. Copy the files over from another GitHub repo.
2. Run when conf.py is run, instead of in a separate script.

Other things that might be useful

• Autogenerate binder links. Credit to my co-dev on contact_map for this work.
• Getting version from installed code. I don't think this is default Sphinx, but since I usually need the code I'm documenting installed (for autodoc), I figure you might as well get the version from the installation.

So something that seems to be happening a lot with both drawing out mappings & using the mappings downstream is that we need to have access to:

• mol2_to_mol1_map
• mol1_unique_atoms (i.e. not in the map)
• mol2_unique_atoms (i.e. not in the map)
• atoms in the mapping that change elements

I'm opening this issue so we can consider potentially adding a couple of small methods to AtomMapping to make getting these out more easily.