Persist ldmx-sw version and sha in run header

[tvami]

I am updating ldmx-sw, here are the details.

What are the issues that this addresses?

This resolves #1538

Check List

• I successfully compiled ldmx-sw with my developments
• I ran my developments and the following shows that they are successful.

I ran

just setenv LDMX_NUM_EVENTS=1
just setenv LDMX_RUN_NUMBER=1
just fire  .github/validation_samples/inclusive/config.py

and then

just fire my_ana.py events.root 

and got

[tamasvami@sdfiana007 ldmx-sw]$ just fire my_ana.py events.root 
denv fire my_ana.py events.root
---- LDMXSW: Loading configuration --------
['events.root']
---- LDMXSW: Configuration load complete  --------
---- LDMXSW: Starting event processing --------
ldmx-sw version = v4.2.5
ldmx-sw sha = 0987a39511a7a1a70ec2d11c53521468ba805182

Where my_ana.py and MyAna.cxx are in the details below.

import os
import sys
fileIn = sys.argv[1:]
fileName =  " ".join(sys.argv[1:])

from LDMX.Framework import ldmxcfg
p = ldmxcfg.Process('myAna')

import LDMX.Ecal.ecal_hardcoded_conditions
from LDMX.Ecal import EcalGeometry
from LDMX.Hcal import hcal
from LDMX.Ecal import vetos

p.maxEvents = -1
p.run = 2

print(fileIn)
p.inputFiles  = fileIn
p.histogramFile = "myHistoOnEventFile.root"


myAna = ldmxcfg.Analyzer.from_file('MyAna.cxx')


p.sequence = [myAna]

and MyAna.cxx is

#include "Framework/EventProcessor.h"

#include <math.h>

class MyAna : public framework::Analyzer {
public:
  MyAna(const std::string& name, framework::Process& p)
  : framework::Analyzer(name, p) {}
  ~MyAna() = default;
  void onNewRun(const ldmx::RunHeader& rh);
  void analyze(const framework::Event& event) final;
};


void MyAna::onNewRun(const ldmx::RunHeader& runHeader) {
   std::cout << "ldmx-sw version = " << runHeader.getLdmxswVersion() << std::endl;
   std::cout << "ldmx-sw sha = " << runHeader.getSoftwareTag() << std::endl;
}

void MyAna::analyze(const framework::Event& event) {}

DECLARE_ANALYZER(MyAna);

[bryngemark]

One question, what happens to this information when I run over an input file with a different version and produce a new output file?

[tvami]

One question, what happens to this information when I run over an input file with a different version and produce a new output file?

I just tested this by running myAna again while I modified the gold_label. It kept the "old" version.

-- > I think this is the desired behavior anyway, what we really care about is the simulation step, the other producers can run in the top of that. Otherwise just by running skimming in a new version should not overwrite this, so this behavior makes sense to me

[tomeichlersmith]

Yea, whenever running in recon mode, the RunHeader is copied from the input file to the output file. We could have subsequent processes add a new run parameter (as Tamas suggested on slack with setStringParameter), but then we have to figure out how to handle the case when we run recon mode on a file that was already recon'ed.

I think just leaving the base version is the best for now. We could develop a situation where we associate the pass name with a ldmx-sw version at some point in the future.

[jpasc27]

So the ldmx-sw version gets printed during the output of newly generated files - great! How would you check the version for files that have already been run (after this update is pushed of course)? Or is that a separate problem?

[tomeichlersmith]

That is a separate problem. This helps avoid that problem in the future.

I can help you a bit more on slack if need be, but I'd ask you to more clearly define what information you want. Do you need to know if a specific simulation bug was present? Do you just want to document for replicability?

[jpasc27]

Was just wanting to document for replicability! We can chat on Slack Tom.

[tvami]

Ehhh...

https://github.com/LDMX-Software/ldmx-sw/actions/runs/13034690037/job/36362081247

#8 0.823 CMake Error at Framework/CMakeLists.txt:69 (file):
#8 0.823   file failed to open for reading (No such file or directory):
#8 0.823 
#8 0.823     /code/Framework/../.github/actions/validate/gold_label

[tomeichlersmith]

I'm guessing its because we need to copy the source code into the image

ldmx-sw/Dockerfile

Line 9 in b319599

COPY . /code

and this copy skips hidden directories.

It might be easier to just move gold_label somewhere else, maybe even have a version file at repository root that can be read by everyone.

[tvami]

One question, what happens to this information when I run over an input file with a different version and produce a new output file?

@bryngemark I was thinking about this: we could easily adopt a convention in central production to have the pass name be the software version. sim and test and etc are not very useful names anyway. Not sure if it makes sense to automate it, maybe it would break some of the validation code, tho from a quick look nothing seems extract anything with test in it, @tomeichlersmith ?

[tvami]

Made an issue for further discussion: #1559