Fix integer_division warnings in sf_zero.f AMACH constants

[d-diaz]

This is the first PR with a small example as part of a broader plan to help resolve the variety of warnings produced by compiling NVEL using gfortran. The intent is to submit a small fix, but also to confirm that this kind of documentation to indicate the proposed change doesn't break existing behavior is acceptable.

Summary

Fixes two -Winteger-division warnings in sf_zero.f's AMACH subroutine. No numerical change — warning cleanup only.

The warning

sf_zero.f:948:61: Warning: Integer division truncated to constant '-62' at (1) [-Winteger-division]
sf_zero.f:965:61: Warning: Integer division truncated to constant '-510' at (1) [-Winteger-division]

Both lines compute a PARAMETER (compile-time constant) by halving an integer exponent (IM12/2, IM15/2) and then using that truncated result inside a real-valued exponentiation. gfortran flags this because integer division silently truncates, and it can't tell from the expression alone whether the truncation was intended.

In this case it is intended — the surrounding comment says as much ("Weird subterfuges below are NECESSARY ... DON'T SIMPLIFY THEM"), and it exists to split an exponent into two halves without overflowing intermediate results. The fix makes the truncation explicit instead of leaving it implicit.

The fix

Before:

      PARAMETER (RM1 = (RBASE**(IM12/2)) * (RBASE**(IM12-IM12/2-1)))
...
      PARAMETER (DM1 = (DBASE**(IM15/2)) * (DBASE**(IM15-IM15/2-1)))

After:

      PARAMETER (RM1 = (RBASE**INT(REAL(IM12)/2.0)) *
     1               (RBASE**(IM12-INT(REA
...
      PARAMETER (DM1 = (DBASE**IDINT(DBLE(IM15)/2.0D0)) *
     1     (DBASE**(IM15-IDINT(DBLE(IM15)/

IM12/2 (integer/integer) and INT(REAL(IM12)/2.0) (integer→real divide, then truncate back to integer) produce the same truncated-toward-zero result for any integer IM12 — the rewrite just performs the truncation with an explicit INT/IDINT call instead of relying on gfortran's implicit truncation rule for mixed integer arithmetic. Same reasoning for DM1 with IDINT/DBLE. The expd machine-constant parameters (not runtimevalues), so this is a one-time, compile-time equivalence, not something that could vary across inputs.

Test evidence

RM1/DM1 feed directly into R1MACH(1)/D1MACH(1) (the single/double precision underflow limits). Verified bit-identical output for indices 1-5 of bor the change. No existing regression case in this codebase happens to exercise those two indices, so a new test was added in the downstream fork of this repo to check for these two indices.

Check	Result
Automated tests	14/14 passed (4 pre-existing + 10 new)
Values compared	R1MACH/D1MACH, indices 1-5, bit-identical before/after
Tolerance	Bit-exact — these are compile-time constants, not measured volumes, so no tolerance is appropriate
New test	tests/test_sf_zero_machine_constants.py — calls R1MACH/D1MACH directly and asserts bit-exact output for indices 1-5
Fork CI run	https://github.com/d-diaz/VolumeLibrary/actions/runs/30184053335/job/89745499433 — expand "Run pytest" for output from test_sf_zero_machine_constants.py specifically

How to reproduce

Confirm the two warnings above are gone:

gfortran -Wall -c sf_zero.f -o /dev/null

Additional context

• Fork development history: fix: sf_zero.f integer_division warnings d-diaz/VolumeLibrary#9 (merged)
• This PR is source-only; full baselines and regression tooling live on the fork and aren't needed to review this diff.