fixup some links caught by lychee

tomeichlersmith · tomeichlersmith · commit 6ee5c8da2ef0 · 2025-03-05T12:41:01.000-06:00
diff --git a/src/dev_image_refman.html b/src/dev_image_refman.html
@@ -10,9 +10,9 @@
       of putting other software manuals in their own GitHub pages and then linking them here
       like this.
     -->
-    <meta http-equiv="refresh" content="0; url='dev-build-context/index.html'" />
+    <meta http-equiv="refresh" content="0; url='https://ldmx-software.github.io/dev-build-context/index.html'" />
   </head>
   <body>
-    <a href="dev-build-context/index.html" target="_blank">Click here to go to Image Manual</a>
+    <a href="https://ldmx-software.github.io/dev-build-context/index.html" target="_blank">Click here to go to Image Manual</a>
   </body>
 </html>
diff --git a/src/developing/Contributing-to-ldmx-sw.md b/src/developing/Contributing-to-ldmx-sw.md
@@ -16,7 +16,7 @@ If you don't already have SSH keys configured, look at the [GitHub directions](h
 
 We prefer that any code contributions are submitted via [pull requests](https://help.github.com/articles/creating-a-pull-request/) so that they can be reviewed before changes are merged into the master.
 
-Before you start, an [issue should be added to the ldmx-sw issue tracker](https://github.com/LDMXAnalysis/ldmx-sw/issues/new).
+Before you start, an [issue should be added to the ldmx-sw issue tracker](https://github.com/LDMX-Software/ldmx-sw/issues/new).
 
 ### Branch Name Convention
 Then you should make a local branch from `trunk` using a command like `git checkout -b iss1234-short-desc` where _1234_ is the issue number from the issue tracker and `short-desc` is a short description (using `-` as spaces) of what the branch is working one.
@@ -29,7 +29,7 @@ If you plan on starting a major (sub)project within the repository like adding a
 
 ### Coding rules and conventions
 
-Please read the [Coding rules](developing/coding-rules.md)
+Please read the [Coding rules](coding-rules.md)
 
 ### After Opening a PR
 After opening a PR, several different tests are run using [our GitHub Actions](https://github.com/LDMX-Software/ldmx-sw/actions). One of these tests, the "Recon Validation" takes about three hours to run, so it shouldn't be run on every commit pushed to a pull request. Instead, it is run when the PR is created or when marked "Ready for Review". This enables the following workflow for validating PRs.
diff --git a/src/developing/coding-rules.md b/src/developing/coding-rules.md
@@ -30,7 +30,7 @@ When developing code in ldmx-sw please follow the following best practises and s
 5. Do not inline virtual functions
 6. Do not let const member functions change the state of the object
 7. Keep the ordering of methods in the header ﬁle and in the source ﬁle identical.
-8. Move `cout`-s to the ldmx logging system, see [Logging](developing/Logging.md)
+8. Move `cout`-s to the ldmx logging system, see [Logging](Logging.md)
 9. Delete commented out code, or move them to `ldmx_log(trace)` if you think it's helpful for a future developer
 10. When updating code, be sure to update and revise comments too
 11. Set all parameters to be `const` that do not need to be non-const.
diff --git a/src/developing/getting-started.md b/src/developing/getting-started.md
@@ -1,7 +1,7 @@
 # Getting Started Developing ldmx-sw
 
 ~~~admonish warning title="Warning"
-This guide assumes familiarity with the [first-time using guide](using/getting-started.md)
+This guide assumes familiarity with the [first-time using guide](../using/getting-started.md)
 and with the terminal.
 ~~~
 
@@ -59,7 +59,7 @@ curl --proto '=https' --tlsv1.2 -sSf https://just.systems/install.sh |\
   bash -s -- --to ~/.local/bin
 ```
 
-If the above does not work on your operating system, you can see system specific instructions [on the just website]( https://just.systems/man/en/packages.htm)
+If the above does not work on your operating system, you can see system specific instructions [on the just website]( https://just.systems/man/en/packages.html)
 
 You probably want to enable [shell tab-completion](https://just.systems/man/en/shell-completion-scripts.html) with `just`
   which only needs to be done once per installation but will help save typing.
diff --git a/src/python_refman.html b/src/python_refman.html
@@ -10,9 +10,9 @@
       of putting other software manuals in their own GitHub pages and then linking them here
       like this.
     -->
-    <meta http-equiv="refresh" content="0; url='ldmx-sw/python/index.html'" />
+    <meta http-equiv="refresh" content="0; url='https://ldmx-software.github.io/ldmx-sw/python/index.html'" />
   </head>
   <body>
-    <a href="ldmx-sw/python/index.html" target="_blank">Click here to go to Python Manual</a>
+    <a href="https://ldmx-software.github.io/ldmx-sw/python/index.html" target="_blank">Click here to go to Python Manual</a>
   </body>
 </html>
diff --git a/src/using/dark-brem/intro.md b/src/using/dark-brem/intro.md
@@ -10,7 +10,7 @@ Following conventions done by collider experiments, I usually call stage one "ge
 To make this even more complicated, LDMX has two different methods to perform the DB simulation. This has led to some confusion within the collaboration and so this document explains both (even though only one is suggested for future use).
 
 ### Historical Method
-The "historical" method is the one that was first done and is a valid approximation for the O(90%) of electrons that arrive at the target undisturbed by the upstream detector components (tagger tracker and trigger scintillator). Generation is done by using MadGraph at a _single_ beam energy such that a _single_ LHE file is output. This LHE file is then given to the [LHEPrimaryGenerator](Configuring-the-Simulation.md) to setup the electron and A' as primaries. The vertex of the primaries imported from the LHE files would be smeared around the target, but the electron's energy would stay fixed at the energy simulated for the LHE files.
+The "historical" method is the one that was first done and is a valid approximation for the O(90%) of electrons that arrive at the target undisturbed by the upstream detector components (tagger tracker and trigger scintillator). Generation is done by using MadGraph at a _single_ beam energy such that a _single_ LHE file is output. This LHE file is then given to the [LHEPrimaryGenerator](../sim/configuring.md) to setup the electron and A' as primaries. The vertex of the primaries imported from the LHE files would be smeared around the target, but the electron's energy would stay fixed at the energy simulated for the LHE files.
 
 As mentioned, this is a good approximation for a vast majority of electrons when looking a DB _in the target_. It is not a helpful method if we wish to include the complexities of the tagger tracker and trigger scintilator or if we wish to look for DB in other parts of the LDMX detector (like in the ECal).
 
diff --git a/src/using/sim/generating.md b/src/using/sim/generating.md
@@ -1,6 +1,6 @@
 # Generating Simulation Samples
 
-The generation of simulation samples is done mainly by the Geant4 package with several additions stored in the `SimCore` module of ldmx-sw. However, you do not need to know the simulation to this level of depth. The `Simulator` producer in the `SimCore` module is your messenger to run the simulation. Here, I will go through its basic usage. For more information about _all_ of the available parameters, please see the documentation on [Configuring the Simulation](Configuring-the-Simulation.md).
+The generation of simulation samples is done mainly by the Geant4 package with several additions stored in the `SimCore` module of ldmx-sw. However, you do not need to know the simulation to this level of depth. The `Simulator` producer in the `SimCore` module is your messenger to run the simulation. Here, I will go through its basic usage. For more information about _all_ of the available parameters, please see the documentation on [Configuring the Simulation](configuring.md).
 
 ### Basic Usage
 Running the simulation is just like any other producer in ldmx-sw. In your python configuration script, it is _required_ that you have the following lines (or equivalent):
@@ -13,7 +13,7 @@ You can write your own detector description in the gdml format (if you want), bu
 mySimulator.setDetector( 'ldmx-det-v12' )
 ```
 Okay, `mySimulator` now is created and has been given a path to an LDMX detector description.
-What else is needed? Well, we need _at least_ one more thing. We need to tell the simulation _how_ to start the simulation. In Geant4 speak, this is called a "Primary Generator". In ldmx-sw, we already have several generators defined (more details on [Configuring the Simulation](Configuring-the-Simulation.md)), but for this simple example, we will just import a standard generator.
+What else is needed? Well, we need _at least_ one more thing. We need to tell the simulation _how_ to start the simulation. In Geant4 speak, this is called a "Primary Generator". In ldmx-sw, we already have several generators defined (more details on [Configuring the Simulation](configuring.md)), but for this simple example, we will just import a standard generator.
 ```python
 from LDMX.SimCore import generators
 mySimulator.generators = [ generators.single_4gev_e_upstream_tagger() ]
@@ -33,7 +33,7 @@ p.outputFiles = [ "mySimulatorOutput.root" ]
 ```
 
 Run: `denv fire myConfig.py`
-(or some [other prefix](http://127.0.0.1:3000/users/config/intro.html#admonition-other-prefixes-besides-denv) running `fire` within the ldmx-sw environment)
+(or some [other prefix](../config/intro.html#admonition-other-prefixes-besides-denv) running `fire` within the ldmx-sw environment)
 
 ### Other Available Templates
 There are a lot of commonly used aspects of the simulation, so we have incorporated these common "templates" into the python interface for the simulation. 
@@ -42,7 +42,7 @@ This section is focused on listing these available templates and how to access t
 #### Generators
 Access with: `from LDMX.SimCore import generators`.
 
-This module contains functions that produce each of the generators. You should _always_ use these helper functions because sometimes the underlying naming conventions may change in future developments. More detail about the generators is in the Generators section of [Configuring the Simulation](Configuring-the-Simulation.md).
+This module contains functions that produce each of the generators. You should _always_ use these helper functions because sometimes the underlying naming conventions may change in future developments. More detail about the generators is in the Generators section of [Configuring the Simulation](configuring.md).
 
 #### Biased Simulations
 Several simulations with biased processes have been used frequently in the past, so we have written templates for using simulations with reasonably-defined defaults.
@@ -59,7 +59,7 @@ Function | Description
 ---|---
 `photo_nuclear(detector,generator)` | PN process biased up and filtered for in (ecal or target)
 `electro_nuclear(detector,generator)` | EN process biased up and filtered for in target
-`dark_brem(massAPrime,lheFile,detector)` | Sets A' mass to massAPrime (in MeV) and uses the input LHE file as vertices for the dark brem simulation [more detail here](Dark-Brem-Signal-Process.md)
+`dark_brem(massAPrime,lheFile,detector)` | Sets A' mass to massAPrime (in MeV) and uses the input LHE file as vertices for the dark brem simulation [more detail here](../dark-brem/intro.md)
 
 ### More Advanced Details
 As I said earlier, you can definitely see all of the capabilities of `Simulator` by looking at the parameters that are available in the documentation (linked above). Two parameters that I would like to point out is `preInitCommands` and `postInitCommands`. These parameters are given directly to the Geant4 UI as a string, so you can still access Geant4 directly using these commands.
