-
Notifications
You must be signed in to change notification settings - Fork 2
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
Add benchmark script #81
Conversation
@kvhuguenin the times are reported, as far as i'm able to determine, per sample. however, the script allows for asynchronous dispatch, so in principle there could even be some parallelisation benefits.... maybe i should turn that off. let's have a look. |
Very nice @sirmarcel and thanks. This will be very useful. Regarding storing. I had the idea of creating an orphan branch maybe called |
benchmark/README.rst
Outdated
|
||
.. code-block:: bash | ||
|
||
pip install .[metatensor] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think also vesin
, ase
etc are needed.
benchmark/run.py
Outdated
version = { | ||
"torch": str(torch.__version__), | ||
"torch-pme-commit": torch_pme_commit, | ||
"torch-pme-status": torch_pme_status, | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe also add the torchpme.__version__
. Even though useless before we release but useful in the future.
Maybe we should also run this code somewhere in CI. Not for benchmark but just that we know we don't break anything. maybe just a subprocess call in der testsuite... EDIT. Maybe one can eve do a |
Would be nice to make this a bit more customizable - setting the devices to run on, the sizes to try, etc. We can leave all this as defaults, but e.g. if one is using this in development it makes sense to only run what's being optimized for. |
What is the status here @sirmarcel ? |
Couldn't keep up with the API changes. Do you think this is worth updating and keeping current? |
I think we kind of stabilized now. I am not aware of any API breaking changes soon. Right @ceriottm ? |
Co-authored-by: Philip Loche <philip.loche@posteo.de>
Co-authored-by: Philip Loche <philip.loche@posteo.de>
* Refactor Calculator class to include units conversion This commit refactors the Calculator class in the base.py file to include a new parameter, units, which allows for conversion of potential values to different units. The units parameter accepts values such as "Gaussian", "eV", "kcal/mol", and "kJ/mol". The commit also adds a unit conversion factor dictionary and checks if the provided units are valid. The potential_sr and potential_lr calculations in the _compute_rspace and _compute_kspace methods respectively are multiplied by the unit conversion factor. --------- Co-authored-by: Philip Loche <ploche@physik.fu-berlin.de>
--------- Co-authored-by: Philip Loche <ploche@physik.fu-berlin.de>
--------- Co-authored-by: Philip Loche <ploche@physik.fu-berlin.de>
--------- Co-authored-by: Philip Loche <ploche@physik.fu-berlin.de>
An example for a Calculator that evaluates LODE features using some of the advanced torch-pme features
* Restructure for better docs * Fixed "broken" image and removed reference to Meshlode * Add an mini-gallery to all doc pages * remove :py: prefix --------- Co-authored-by: Michele Ceriotti <michele.ceriotti@gmail.com> Co-authored-by: E-Rum <rev99@internet.ru>
Co-authored-by: Kevin Kazuki Huguenin-Dumittan <kvhuguenin@gmail.com>
--------- Co-authored-by: Michele Ceriotti <michele.ceriotti@gmail.com> Co-authored-by: Philip Loche <ploche@physik.fu-berlin.de>
* Validate consistent dtype between positions and neighbor_distances * unify `_validate_parameters` * use torch.get_default_device() * remove excessive use of double precision * update README example --------- Co-authored-by: GardevoirX <xqj.2001@outlook.com>
* Add CalculatorDipole and PotentialDipole classes with tests * Refactor PotentialDipole class to inherit from torch.nn.Module * Refactor potential calculations in CalculatorDipole and PotentialDipole classes for improved performance and clarity * Add lr_from_dist calculation to PotentialDipole class * Implement lr_from_k_sq, self_contribution and background_correction for PotentialDipole class * Finish calculator_dipole.py * Correct energy calculation in CalculatorDipole and fix smearing factor in PotentialDipole * Refactor device handling in CalculatorDipole and PotentialDipole classes; improve performance of potential calculations and enhance test coverage for magnetostatics * Enhance PotentialDipole class by allowing device parameter to accept string type; fix tensor dimension in f_cutoff method and update test assertions for clarity * Fix a bug in k_space calculator; add epsilon parameter to PotentialDipole and update background_correction method * Add dipoles test frames and enhance tests for magnetostatic Ewald calculations * Replace vesin.torch, as it doesn’t support Windows OS. * Refactor CalculatorDipole and PotentialDipole classes to remove device and dtype parameters; update tests accordingly for improved clarity and consistency. * Update __init__.py to include CalculatorDipole and PotentialDipole in exports; enhance compute_distances function to optionally return distance vectors. * restructure some files * Enhance docstrings for CalculatorDipole and PotentialDipole classes; provide detailed parameter descriptions and usage examples for improved clarity. * proofread docs --------- Co-authored-by: Philip Loche <ploche@physik.fu-berlin.de>
We now also run P3M.
Something went terribly wrong here. Closing this and re-opening. |
Fixes #17
As discussed a while ago with @PicoCentauri , this adds a benchmark script, designed to emulate a "typical" training workload. The idea is that we agree to run this before major merges, to make sure we don't cause performance regressions.
The script runs Ewald and PME, with and without Metatensor, for CsCl crystals of various sizes. The results are saved as
.yaml
, with some diagnonstic information. An example output can be seen in #80. The script already worked quite nicely to pointint that something was wrong in that case...We could consider making some additional repository for the
.yaml
and make a nice plot of performance, hopefully, increasing over time.📚 Documentation preview 📚: https://torch-pme--81.org.readthedocs.build/en/81/