10000 `evaluate-batch` not able to match directory structure · Issue #8 · aivant/peppr · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

evaluate-batch not able to match directory structure #8

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

Closed
padix-key opened this issue Apr 7, 2025 · 4 comments
Closed

evaluate-batch not able to match directory structure #8

padix-key opened this issue Apr 7, 2025 · 4 comments
Labels
enhancement New feature or request question Further information is requested

Comments

@padix-key
Copy link
Collaborator

@padix-key I want to use batch-evaluator, and I have a directory of reference pdbs, and a directory of corresponding poses (ordered together). In my understanding, I can't run the matching right? The current system only supports one reference

Originally posted by @ssiddhantsharma in #1

@padix-key
Copy link
Collaborator Author

Could you give an example tree of your directory structure? Does it look something like

references/
|- system_0.pdb
|- system_1.pdb
|...
poses/
|- system_0.pdb
|- system_1.pdb
|...

This would mean there would be a single pose for each reference. evaluate-batch is able to handle this:

peppr evaluate-batch peppr.pkl "references/*.pdb" "poses/*.pdb"

@padix-key padix-key added the question Further information is requested label Apr 7, 2025
@ssiddhantsharma
Copy link

Hi @padix-key 8000 I tried arranging my references and poses in a format you mentioned. It worked but then when I run evaluate-batch it gives Reference and pose have different entities
This might be arising because my references are backbones that come out of RFDiffusion (having poly-G stretches) and my poses are predicted colabfold structure. I was thinking of using peppr for calculating my scRMSD

@padix-key
Copy link
Collaborator Author

Hi, The the additional stretches in the reference may be the reason, why peppr thinks these chains are different entities. If you use the Python API, you can try to reduce min_sequence_identity, but this is not supported in the CLI, yet.

I'll label this issue as enhancement, as it would be good to have the following changes in the CLI:

  • Ability to change the min_sequence_identity
  • Gracefully skip systems where evaluation fails

@padix-key
Copy link
Collaborator Author

The 'enhancement' part is solved by #15

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants
0