[ET Trac] #2912: Inconsistent computation of the volume form in Coordinates (llama) between Thornburg04/13 and default behavior

Jordan Nicoules trac-noreply at einsteintoolkit.org
Tue Jan 20 03:14:33 CST 2026


#2912: Inconsistent computation of the volume form in Coordinates (llama) between Thornburg04/13 and default behavior

 Reporter: Jordan Nicoules
   Status: submitted
Milestone: 
  Version: 
     Type: bug
 Priority: major
Component: EinsteinToolkit thorn

For reference, thread on the users mailing list: [https://lists.einsteintoolkit.org/pipermail/users/2026-January/009852.html](https://lists.einsteintoolkit.org/pipermail/users/2026-January/009852.html)

The issue originates in trying to compute volume integrals in an analysis thorn, by using the volume form computed by Coordinates in a Llama grid.

‌

In simulations using Llama, different patch systems don’t compute the volume\_form grid function in the same way \(when requested by parameter store\_volume\_form. More precisely, the default behavior is \(inverse-jacobian.F90\):

```
volume_form(i,j,k) = detJ
```

‌

Meanwhile, patch system Thornburg04 has a dedicated routine because it needs to compute weights to account for overlapping patches. But even in the non-overlapping spherical part of the grid, it computes the volume form as \(thornburg04.cc\):

```
// set volume form to deterimant of Jacobian
    const CCTK_REAL det =  fabs((  J11[ijk] * J22[ijk] * J33[ijk]
              + J12[ijk] * J23[ijk] * J31[ijk]
              + J13[ijk] * J21[ijk] * J32[ijk]
              - J11[ijk] * J23[ijk] * J32[ijk]
              - J12[ijk] * J21[ijk] * J33[ijk]
              - J13[ijk] * J22[ijk] * J31[ijk]));

volume_form[ijk] = h[0]*h[1]*h[2]/det;
```

where h is the spacing computed before in the function.

‌

This leads to, in particular, different behaviors for the volume form between Thornburg04 and Thornburg04nc.

‌

For consistency of treatment and agnosticity of thorns that would rely on the volume form \(assuming they know Llama is being used\), I would suggest to homogenize the computation of volume form. Here are a few suggestions, given that my tests were limited only to Thornburg04 and Thornburg04nc.

* Leave it to each patch system to compute the volume form, and have an error/warning as default \(but they should still be somehow consistent, to avoid having to check for the patch system in a user thorn.
* \(preferred, but not tested on my side with other patch systems\) Replace the default computation by something similar to Thornburg04:

    ```fortran
      CCTK_INT map, ierr
      CCTK_INT, PARAMETER :: dimensions = 3
      CCTK_REAL, dimension(dimensions) :: physical_min, physical_max, interior_min, interior_max, exterior_min, exterior_max, h  
      map  = MultiPatch_GetMap(cctkGH)
      ierr = MultiPatch_GetDomainSpecification( map, dimensions, &
          physical_min, physical_max, &
          interior_min, interior_max, &
          exterior_min, exterior_max, &
          h )
    ```

    ```fortran
    volume_form(i,j,k) = h(1)*h(2)*h(3) / abs(detJ)
    ```

Also note the absolute value here, as I’ve encountered negative values of the determinant in tests.

--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2912/inconsistent-computation-of-the-volume
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.einsteintoolkit.org/pipermail/trac/attachments/20260120/d4a0e93f/attachment.htm>


More information about the Trac mailing list