docs(release): fix release notes (use scientific notation) (#1881)

Use proper scientific notation via siunitx to fix failing CI and nightly build (previously carets were not escaped). Also test building the PDF file from LaTeX files in docs.yml (previously only tested in ci.yml which is not triggered when a changeset touches only docs files). This should help catch LaTeX syntax errors like this.

.github/workflows/docs.yml

@@ -83,16 +83,24 @@ jobs:
       - name: Install TeX Live
         run: |
           sudo apt-get update
-          sudo apt install texlive-latex-extra texlive-science texlive-font-utils
+          sudo apt install texlive-science \
+            texlive-latex-extra \
+            texlive-font-utils \
+            texlive-fonts-recommended \
+            texlive-fonts-extra
 
       - name: Install USGS LaTeX style files and Univers font
         working-directory: usgslatex/usgsLaTeX
         run: sudo ./install.sh --all-users
 
-      - name: Test building files from dfn's for LaTeX
+      - name: Test building MF6IO LaTeX from DFNs
         working-directory: modflow6/distribution
         run: pixi run pytest -v build_docs.py::test_build_mf6io_tex_from_dfn
 
+      - name: Test building PDFs from LaTeX
+        working-directory: modflow6/distribution
+        run: pixi run pytest -v build_docs.py::test_build_pdfs_from_tex
+
       - name: Setup ${{ env.FC }} ${{ env.FC_V }}
         uses: fortran-lang/setup-fortran@v1
         with:

doc/ReleaseNotes/ReleaseNotes.tex

@@ -13,6 +13,7 @@
 \usepackage{bibentry}
 \usepackage{graphicx}
 \usepackage{longtable}
+\usepackage[tight-spacing=true]{siunitx}
 
 \usepackage[T1]{fontenc}
 

doc/ReleaseNotes/develop.tex

@@ -22,7 +22,7 @@
 	\begin{itemize}
 		\item With the LOCAL\_Z option enabled, the PRT model's PRP package attempted to check that a particle release point's z coordinate fell within the grid's vertical extent before converting the coordinate from local (normalized on the unit interval) to a global (model) coordinate. This bug was fixed by converting coordinates before conducting checks.
 		\item The PRT model could hang upon particle termination due to no (sub)cell exit face. This occurred because a flag signaling particle advance was not set in the proper location.
-		\item Entangled with the previous issue, the ternary method could erroneously terminate a particle and report no exit face (before now this would hang) due to precision error in the exit time/position calculation. This could happen when two conditions are both met: the particle enters the subcell very close to one of its vertices, and flow very nearly parallels one of the subcell's faces. We have encountered similar situations before, solved by nudging the particle a small distance into the interior of the subcell before applying the tracking method. This particular case is resolved by increasing the padding distance from machine precision * 10^2 to machine precision * 10^5.
+		\item Entangled with the previous issue, the ternary method could erroneously terminate a particle and report no exit face (before now this would hang) due to precision error in the exit time/position calculation. This could happen when two conditions are both met: the particle enters the subcell very close to one of its vertices, and flow very nearly parallels one of the subcell's faces. We have encountered similar situations before, solved by nudging the particle a small distance into the interior of the subcell before applying the tracking method. This particular case is resolved by increasing the padding distance from $\sisetup{input-digits = 0123456789\epsilon} \num{\epsilon e+2}$ to $\sisetup{input-digits = 0123456789\epsilon} \num{\epsilon e+5}$, where $\epsilon$ is machine precision.
 		\item For ASCII input files erroneously containing a mix of line endings, MODFLOW would sometimes proceed with unexpected results. The program was corrected to stop with an error message if an input line contained both carriage returns and line feeds.
 	%	\item xxx
 	%	\item xxx