Added parameter atoms_batch_size - #21
Conversation
…en computing constraints.
|
Thanks for the PR. Some time ago I made a PR to add a batching parameter to the distance function in aggforce . I think it would be cleaner to use that in conjunction to your new argument in a yaml instead of adding all of the code for the explicit constraint finding in batches here in mlcg-tk. |
|
After an IRL discussion we agreed on keeping this change but adding some documentation to explain some more things. Also, the examples and the readme needs to me modified to explain how to use this parameter in the yamls. |
|
I've tested the PR for the 1L2Y at both 5-bead and CA resolution, and it seems to give consistent results when compared to the base branch. @EdoardoRolando has also tested this for other small proteins and for the large system he is handling, so I will be merging this. |
| # Cross-batch constraints | ||
| # To significantly reduce computational cost, we assume residues are ordered in the structure. | ||
| # Therefore, we only compute constraints between consecutive batches, rather than all pairs of batches. | ||
| # For even greater efficiency, one could restrict this to just the first and last (e.g., 30) atoms of each batch, |
There was a problem hiding this comment.
It would be great to have a sentence here saying that constraints between batch i and batch i+2 are skipped
Summary:
This PR adds batching support to the constraint inference logic used in mlcg-tk. A new optional argument atoms_batch_size allows the system to process atomistic sites in manageable chunks, improving scalability for large molecular systems.
When batching is enabled:
Constraints are computed within each batch.
Additional cross-batch constraints are computed between consecutive batches, assuming atoms/residues are ordered.
If atoms_batch_size is not specified or larger than the number of atoms, the original (non-batched) behavior is preserved.
Notes:
Residues are assumed to be sequentially ordered in the input coordinate array, so that cross-batch comparisons are limited to consecutive batches, which balances accuracy and speed.
Existing behavior is unchanged for smaller systems or when batching is not enabled.
This requires a small, backward-compatible change in aggforce, for which I have already opened a pull request.