mark analysis.atomicdistances.AtomicDistances as not parallelizable

[talagayev]

Fixes #4662

Changes made in this Pull Request:

• atomicdistances.AtomicDistances explicitly marked as not parallelizable
• Addition of tests to test_atomicdistances.py to assert serial backend

Reason why atomicdistances.AtomicDistances is not parallelizable:

• Currently Results uses UserDict as input, while atomicdistances.AtomicDistances outputs an numpy.ndarray
  so it would require the modification of the output or modification of Results to make it parallelizable

PR Checklist

• Tests?
• Docs?
• CHANGELOG updated?
• Issue raised/referenced?

Developers certificate of origin

• I certify that this contribution is covered by the LGPLv2.1+ license as defined in our LICENSE and adheres to the Developer Certificate of Origin.

---

📚 Documentation preview 📚: https://mdanalysis--4808.org.readthedocs.build/en/4808/

[pep8speaks]

Hello @talagayev! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

There are currently no PEP 8 issues detected in this Pull Request. Cheers! 🍻

Comment last updated at 2024-11-27 16:16:07 UTC

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 93.66%. Comparing base (abc9806) to head (ab86552).
Report is 14 commits behind head on develop.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #4808      +/-   ##
===========================================
- Coverage    93.68%   93.66%   -0.03%     
===========================================
  Files          177      189      +12     
  Lines        21742    22809    +1067     
  Branches      3055     3055              
===========================================
+ Hits         20368    21363     +995     
- Misses         927     1000      +73     
+ Partials       447      446       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[orbeckst]

You're right — but the issue is really that we somehow never upgraded this analysis class to use Results. I am not sure how this slipped through. I raised #4819.

Even though your PR looks fine, I'd prefer to fix #4819 and then parallelize the class because from the outside it makes no sense that such a simple calculation "cannot be parallelized". This would not look good.

Until we decide what to do with #4819, this PR should be on hold.

[talagayev]

You're right — but the issue is really that we somehow never upgraded this analysis class to use Results. I am not sure how this slipped through. I raised #4819.

Even though your PR looks fine, I'd prefer to fix #4819 and then parallelize the class because from the outside it makes no sense that such a simple calculation "cannot be parallelized". This would not look good.

Until we decide what to do with #4819, this PR should be on hold.

Yes that sounds reasonable, since if #4819 is adressed, than it should not be a problem to implement the parallelization here with some quick adjustments

[orbeckst]

@talagayev I am closing this PR — one way or another, we'll decide on PR #4822 how to continue.

[talagayev]

@talagayev I am closing this PR — one way or another, we'll decide on PR #4822 how to continue.

Yes, sounds good by me :) I can just create a new PR as soon as the decision is done for PR #4822. Adding
the parallelization in #4822 would also not be a problem.