Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Have CLI place generated YAML file into the perses calculation directory #998

Closed
jchodera opened this issue May 8, 2022 · 7 comments · Fixed by #1052
Closed

Have CLI place generated YAML file into the perses calculation directory #998

jchodera opened this issue May 8, 2022 · 7 comments · Fixed by #1052

Comments

@jchodera
Copy link
Member

jchodera commented May 8, 2022

Currently, the CLI generates a YAML file with the updated overridden fields, but it places it into a file like

parsed-2022-04-18-20:51:55-my.yaml

rather than actually putting it in the perses calculation output directory where it would be useful.

We should fix this so that we can pull useful information from it, like what calculation was actually performed to generate all the files in this directory.

@jchodera
Copy link
Member Author

jchodera commented May 8, 2022

To be completely clear, I'm recommending that instead of this:

├── parsed-2022-04-18-20:51:55-my.yaml <--- it's currently here
├── long_run_lig0to8
│   ├── atom_mapping.png
│   ├── out-complex_checkpoint.nc
│   ├── out-complex.nc
│   ├── out-complex.pdb
│   ├── out-complex_real_time_analysis.yaml
│   ├── out-hybrid_factory.npy.npz
│   ├── out-solvent_checkpoint.nc
│   ├── out-solvent.nc
│   ├── out-solvent.pdb
│   ├── out-solvent_real_time_analysis.yaml
│   ├── out-topology_proposals.pkl
│   └── xml
│       ├── complex-hybrid-system.gz
│       ├── complex-new-system.gz
│       ├── complex-old-system.gz
│       ├── solvent-hybrid-system.gz
│       ├── solvent-new-system.gz
│       └── solvent-old-system.gz

we want something like this:

├── long_run_lig0to8
│   ├── perses-cli.yaml <----- we want it here
│   ├── atom_mapping.png
│   ├── out-complex_checkpoint.nc
│   ├── out-complex.nc
│   ├── out-complex.pdb
│   ├── out-complex_real_time_analysis.yaml
│   ├── out-hybrid_factory.npy.npz
│   ├── out-solvent_checkpoint.nc
│   ├── out-solvent.nc
│   ├── out-solvent.pdb
│   ├── out-solvent_real_time_analysis.yaml
│   ├── out-topology_proposals.pkl
│   └── xml
│       ├── complex-hybrid-system.gz
│       ├── complex-new-system.gz
│       ├── complex-old-system.gz
│       ├── solvent-hybrid-system.gz
│       ├── solvent-new-system.gz
│       └── solvent-old-system.gz

@jchodera
Copy link
Member Author

jchodera commented May 8, 2022

We could store the metadata currently stored in the filename (such as timestamp the file was generated) inside the YAML file it generates.

@jchodera
Copy link
Member Author

jchodera commented May 8, 2022

It would also be useful to store the molecule titles (molecule names) from the SDF file corresponding to the initial and final ligands, since we need to use these in constructing the overall transformation network for analysis and plotting.

@mikemhenry
Copy link
Contributor

We have moved the parsed yaml into the calculation directory but I'm going to keep this issue to track:

  • store the metadata currently stored in the filename (such as timestamp the file was generated) inside the YAML file
  • store the molecule titles (molecule names) from the SDF file corresponding to the initial and final ligands

I think that it makes to add basically two sections to the yaml, one section that has all the parsed options/defaults, and another section that has metadata, like the GPU used, the time created, hostname the system was ran on, ligand name (not just index) stuff like that.

@ijpulidos
Copy link
Contributor

ijpulidos commented May 11, 2022

The first part is solved via #972. I'm creating a new issue with the second part for the molecules titles.

@ijpulidos
Copy link
Contributor

Oh my bad, the tab didn't update itself and I missed @mikemhenry comment. Sorry! Will reopen.

@ijpulidos ijpulidos reopened this May 11, 2022
@mikemhenry
Copy link
Contributor

No worries, when I saw it was closed I thought "wow I can't believe Iván got those two things done already"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants