Skip to content

Implement an accurate and efficient spherical triangle area calculation using Eriksson’s formula #1585

Open

Description

@hongyuchen1030

Proposed new feature or change:

UXarray’s current spherical triangle area calculation uses a Quadrature-based implementation adapted from the existing TempestExtreme software.

Based on our benchmarks, the current approach has two main limitations:

  1. Its computational performance is not ideal.
  2. It remains vulnerable to numerical errors in difficult geometric configurations, despite using quadruple-precision arithmetic.

We recommend replacing the current implementation with Eriksson’s formula for calculating the area of a spherical triangle.

With an appropriate implementation, our benchmarks show that Eriksson’s formula provides:

  • better computational performance;
  • better numerical accuracy; and
  • more reliable behavior for challenging spherical triangles.

This formula has also already been adopted by YAC for its spherical triangle area calculations.

Please refer to the following section of the paper for the algorithm, numerical analysis, and benchmark results:

Page 30, Eqn (23), Spherical Excess $E$ is the area on the unitsphere.

Image

https://egusphere.copernicus.org/preprints/2026/egusphere-2026-636/

Activity

  1. added this to the Remapping milestone on Jul 17, 2026
  2. moved this from 📚 Backlog to 📝 To-Do in UXarray Developmenton Jul 17, 2026
  3. Sevans711 commented on Jul 20, 2026

    @Sevans711
    Collaborator

    Hi @hongyuchen1030, thank you for posting this and pointing me to it to take a look! Some initial thoughts:

    Would face_node_angles from #1566 possibly enable more accurate face_areas computations for all faces, not just triangles, as per @rajeeja's suggestion there to compare spherical excess with the computed areas? The process could shift from "use quadrature" to "sum angles in face, apply formula to compute face area from spherical excess."

    Alternatively, I wonder, is there any nice way to generalize Eriksson's formula to apply to non-triangles as well?

    Either way, for triangles Eriksson's formula looks more efficient than computing all the angles individually, because there is only one trig function called here.

  4. hongyuchen1030 commented on Jul 20, 2026

    @hongyuchen1030
    ContributorAuthor

    Hi @hongyuchen1030, thank you for posting this and pointing me to it to take a look! Some initial thoughts:

    Would face_node_angles from #1566 possibly enable more accurate face_areas computations for all faces, not just triangles, as per @rajeeja's suggestion there to compare spherical excess with the computed areas? The process could shift from "use quadrature" to "sum angles in face, apply formula to compute face area from spherical excess."

    Alternatively, I wonder, is there any nice way to generalize Eriksson's formula to apply to non-triangles as well?

    Either way, for triangles Eriksson's formula looks more efficient than computing all the angles individually, because there is only one trig function called here.

    @Sevans711,

    These are all great questions. I provide a more detailed discussion in Section 5.10, “Face-level: Spherical face triangulation and face area,” of my paper:

    https://egusphere.copernicus.org/preprints/2026/egusphere-2026-636/egusphere-2026-636.pdf

    To summarize the main points mentioned in the issue description above:

    1. Spherical excess is the area of a spherical polygon on the unit sphere.
    2. There are several formulas for calculating spherical excess. The most direct approach is to compute the interior angle at each vertex, which is likely the connection you noticed with #1566. However, this approach is known to have poor numerical accuracy and is therefore not commonly used in most software implementations. I discuss this issue in more detail in the paper referenced above.
    3. Quadrature is not considered a best-practice method for spherical area calculation. The current quadrature-based implementation is intended only as a placeholder.
    4. This formula applies only to spherical triangles, as does the current quadrature-based method. In computational geometry, a common approach is still to triangulate a spherical face first and then compute the area of each triangle.

    That said, it is possible to calculate the area of an arbitrarily shaped spherical face, provided that all boundary edges are great-circle arcs, using the pre-quantization method described in Theorems 3.4 and 3.5 of the paper shown below. I am including it in case you are interested. As noted in my paper, these formulas are relatively recent, and their performance and numerical accuracy have not yet been thoroughly benchmarked.
    https://epubs.siam.org/doi/full/10.1137/23M1565255
    Image

  5. Sevans711 commented on Jul 20, 2026

    @Sevans711
    Collaborator

    Thank you for these extra details!

    The most direct approach is to compute the interior angle at each vertex, which is likely the connection you noticed with 1566. However, this approach is known to have poor numerical accuracy and is therefore not commonly used in most software implementations.

    Ah, I didn't realize it had poor accuracy for these purposes, that is helpful to know.

    it is possible to calculate the area of an arbitrarily shaped spherical face, provided that all boundary edges are great-circle arcs, using the pre-quantization method described in Theorems 3.4 and 3.5 of the paper…

    The paper's notation is a bit difficult for me to parse at a glance, but it is exciting that such formulas exist! If ends up making sense to try implementing them, instead of just using triangulation plus Eriksson's formula, I would be interested to take a closer look. I will keep you posted if that ends up happening, especially if I get stuck on any parts of the paper at that point.

  6. hongyuchen1030 commented on Jul 20, 2026

    @hongyuchen1030
    ContributorAuthor

    Thank you for these extra details!

    The most direct approach is to compute the interior angle at each vertex, which is likely the connection you noticed with 1566. However, this approach is known to have poor numerical accuracy and is therefore not commonly used in most software implementations.

    Ah, I didn't realize it had poor accuracy for these purposes, that is helpful to know.

    it is possible to calculate the area of an arbitrarily shaped spherical face, provided that all boundary edges are great-circle arcs, using the pre-quantization method described in Theorems 3.4 and 3.5 of the paper…

    The paper's notation is a bit difficult for me to parse at a glance, but it is exciting that such formulas exist! If ends up making sense to try implementing them, instead of just using triangulation plus Eriksson's formula, I would be interested to take a closer look. I will keep you posted if that ends up happening, especially if I get stuck on any parts of the paper at that point.

    It would probably help streamline many things if you could take a look at the paper: https://egusphere.copernicus.org/preprints/2026/egusphere-2026-636/egusphere-2026-636.pdf

    This paper provides the most up-to-date overview of spherical geometry algorithms for geoscience regridding. It explains the definition of each geometric object and the recommended algorithms for each step. The goal is for UXarray to eventually implement all of the recommended algorithms from this paper. In other words, this paper serves as UXarray’s algorithmic documentation. And feel free to let me know if you have any problems with the paper.

    For the area calculation, I would recommend proceeding with the triangulation + Eriksson formula implementation first. Once we have more time, we can look into the more advanced pre-quantization method.

  7. added
    accuracyRelated to mathematical accuracy of operations, such as numerical precision or rounding errors
    scalabilityRelated to scalability & performance efforts
    on Aug 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    accuracyRelated to mathematical accuracy of operations, such as numerical precision or rounding errorsnew featureNew user-facing functionalityscalabilityRelated to scalability & performance efforts

    Type

    No type

    Fields

    Priority

    None yet

    Projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions