Release v3.2.1

Changelog

• Wheels for Python 3.13 🥳 Free-threaded versions of the wheels are also available on PyPI for Linux and macOS-based systems. Free-threaded builds for Windows have not yet been released.
• Starting with v3.2.1, Pre-built wheels for musllinux-systems are now available as well via PyPI
• For our C++ user base, the LOGGING_LEVEL CMake build option is now specified using natural language syntax. E.g. LOGGING_LEVEL=INFO instead of LOGGING_LEVEL= 2

Related Pull Requests

• JOSS References for README and Documentation by @schuhmaj in #41
• Python 3.13 Wheels/ Release 3.2.1 by @schuhmaj in #42

Full Changelog: v3.2.0...v3.2.1

Release v3.2.0

Changelog

No changes for end-users compared to v3.0.0!

This is the JOSS release. It fixes the Pipeline for macOS x86_64 wheels. It does not contain any other changes to the implementation but only fixes the CI/ CD.

Details

• Fix Deployment for macOS x86_64 wheels on PyPi by @schuhmaj in #40

Full Changelog: v3.1.0...v3.2.0

Release v3.1.0

Release v3.1.0

No changes for end-users compared to v3.0.0!

The tests were revised, the CI/CD was improved, and the JOSS paper was brought into its release state.

What's Changed

• Linux aarch64 Wheels in the CI/CD by @schuhmaj in #37
• Improve Test Stability & Minor fixes to documentation by @schuhmaj in #39
• Fixing syntax for one reference by @dfm in #38

New Contributors

• @dfm made their first contribution in #38

Full Changelog: v3.0.0...v3.1.0

Release v3.0.0

Key Changes

• The accelerations are now multiplied by -1.0 to follow the geodesy and geophysics sign conventions

Important

This gravity model's output now obeys to the geodesy and geophysics sign conventions.
Hence, the potential $V$ for a polyhedron with a mass $m > 0$ is defined as positive.
Accordingly, the accelerations are defined as $\textbf{g} = + \nabla V$.
The sign of the acceleration output is inverted when compared to the older version, v2.1.0, and before
Have a look at I/O Explaination

Python Interface

• The Polyhedron is now exposed to Python and enforces compliance with the gravity model preconditions about the vertex ordering. It is impossible to create an invalid Polyhedron if not explicitly specified via the __init__-method.

  • Python Polyhedron Class
  • Explanation of the mesh integrity checks

• The evaluate and GravityEvaluable do not take a polyhedral_source & density anymore. They only take a Polyhedron as an input argument

  • Evaluate & GravityEvaluable Python API

• The utility submodule was removed. This functionality is now grouped inside the Polyhedron class.

  • The read(filenames) to yield vertices and faces can be modeled by creating a Polyhedron from filenames and then effectively by accessing its vertcies and faces properties
  • The check_mesh is now effectively part of the construction of a Polyhedron. If you still require a dedicated check:
    1. Construct the Polyhedron with disabled checks (integrity_check=PolyhedronIntegrity.DISABLE)
    2. Call check_normal_orientation on the instance. It returns the majority plane unit normal orientation (INWARDS or OUTWARDS) and a set of face indices violating this orientation. So, e.g., all plane unit normals are pointing OUTWARDS except the normal at face's array index 1.
  • More details in the docs

Tip

Find more help in the updated Python Examples

C++ Library

• The Polyhedron is now exposed to Python and enforces compliance with the gravity model preconditions about the vertex ordering. It is impossible to create an invalid Polyhedron if not explicitly specified via the constructor

  • C++ Polyhedron Class
  • Explanation of the mesh integrity checks

• The evaluate and GravityEvaluable do not take a polyhedral_source & density anymore. They only take a Polyhedron as an input argument

  • Evaluate & GravityEvaluable C++ API

• When using the C++ executable - The yaml configuration file parameter check_mesh defaults now to true and will repair the mesh if possible (so basically, true/ false <--> PolyhedronIntegrity::HEAL/ PolyhedronIntegrity::DISABLE)

Tip

Find more help in the updated C++ Examples

Details

Resolved Issues & Pull Requests

• Paper writing by @gomezzz in #11
• JOSS - PRE REVIEW Changes by @schuhmaj in #18
• [JOSS Review] Fix Python syntax of minimal example by @santisoler in #20
• [JOSS Review] Minor fix to example using GravityEvaluable by @santisoler in #23
• [JOSS Review] Increase indentation of list in CONTRIBUTING.md by @santisoler in #25
• [JOSS Review] Improve Python tests and unpin Numpy version by @santisoler in #26
• Switch to GitHubPages by @schuhmaj in #35
• [JOSS Review] Bits and Pieces - Version 2.2 by @schuhmaj in #31
• Version 3 - Failsafe Polyhedral Gravity Modeling & Polyhedron Class by @schuhmaj in #36

New Contributors

• @santisoler made their first contribution in #20

Full Changelog: v2.1.0...v3.0.0

Release v2.1.0

Changelog

• Added pickle support. The gravity evaluable can now be pickled to the persistent memory (including its internal cache)
• Fixed the error message that appears when numerical instabilities might occur

New Feature: Serialization of a GravityEvaluable

import polyhedral_gravity
import pickle

evaluable = polyhedral_gravity.GravityEvaluable((vertices, faces), DENSITY)
with open("evaluable.pk", "wb") as f:
    pickle.dump(evaluable, f, pickle.HIGHEST_PROTOCOL)
    
with open("evaluable.pk", "rb") as f:
    evaluable = pickle.load(f)

Full Changelog: v2.0.3...v2.1.0

Release v2.0.3

PyPi Full Release Version

You can skip this version since it does not add anything to the program itself

• Added GitHubAction workflow, which builds wheels for all major CPython & PyPy versions on the three operating systems: Windows, MacOS, and (Many)Linux

Release v2.0.0

What's Changed

• Add Warning in case of running into floating point arithmetic issues
• Add class GravityEvaluable to cache common properties in multi-point evaluation
• Add option to disable the parallelisation (if built with any) during runtime

Details

This change included a small change to the Python API, which might break current code!

• The naming of the arguments changed
• The evaluate method takes vertices and faces as a tuple now, rather than as separate arguments

import polyhedral_gravity as model

# The "free function" evaluate has now always three arguments (or an optional fourth one)
# The keywords of the signature are now always the SAME!
# So the third argument takes computation_points or a SINGLE computation_point
# Optionally with the keyword prefix
# The "parallel" argument allows to disable the parallelization
model.evaluate(polyhedral_source=(vertices, faces), density=1.0, computation_points=[..], parallel=True)

# Removed signature (vertices and faces as separate arguments)
# model.evaluate(vertices, faces, density=1.0, computation_points=[..])

GravityEvaluable speeds up the runtime by around factor 30 if one wants to compute multiple points one by one - e.g. when propagating a trajectory.

import polyhedral_gravity as model

# Construction like above, but only with the two "persistent" arguments
evaluable = model.GravityEvaluable((vertices, faces), density)

for i in range(N):
   # The second argument is optional and defaults to True
    evaluable(computation_points[i], parallel=True)

Results from comparing the old & new interface (N=1, so small runtime differences are not really expressive)
1000 random sampled points around Eros using Apple Clang 14, M1 Pro and the TBB Backend.

######## Old Single-Point ########
--> 1000 times 1 point with old interface
--> Time taken: 7862.830 microseconds per point
######## Old Multi-Point ########
--> 1 time N points with old interface
--> Time taken: 271.561 microseconds per point
######## GravityEvaluable (Single-Point) #########
--> 1000 times 1 point with GravityEvaluable
--> Time taken: 331.350 microseconds per point
######## GravityEvaluable (Multi-Point) ########
--> 1 time 1000 points with GravityEvaluable
--> Time taken: 255.692 microseconds per point

Full Changelog: v1.2.1...v2.0.0

EDIT: This is a re-release including fixes for the conda-deployment

Release v1.2.1

Changelog

• FIXED: Build Issues on conda for OSX Toolchain (version 10.9 does not support C++ 17's optional)
• Use spdlog v1.11

v1.2.0

What's Changed

• Added (optional) mesh sanity checks:
  • Check if normals are pointing outwards (uses Möller–Trumbore intersection algorithm)
  • Check if triangles are degenerate
• Updated the documentation accordingly
• Simplified CMake Parallelization setup (the old system was quite misleading with two variables)
• Exposed certain previously exclusive C++ functions into a Python submodule utility

Release v1.1.6

• Removed yaml-cpp from Python interface dependencies
• Revamped CMake extensively