Files for validation pipeline

[enlupi]

This pull request includes the following changes:

• ADD scripts/FCCee directory, which includes:
  - bash and analysis scripts for ALLEGRO, CLD, and IDEA in the respective directories
  - common utility scripts for comparing and plotting histograms in the utils directory

• Modified the www and web directories to fix the website for the new validation pipeline.
  - modified web/python/make_web.py and web/templates to adapt to the new website structure
  - Added www/static/styles.css for new website look

[jmcarcell]

I'm not a fan of these blocks, if you keep reading then it's obvious so it's not telling you anything. If you want a small comment so that you can jump, it can be just # Beginning of ECal Barrel and the ending has Endso that the in the editor you can search for Begin and End. In one of the files below, the blocks look to be almost 50% of the contents of the script.

[tmadlener]

It might also be a simple sign that you effectively have (almost) a function (or at least something that can be refactored into one) here. In that case you solve several issues in one step:

• You have a clearly defined name for searching
• You have a very well defined scope of where it starts and ends
• You have a clearly defined place where you can put some top level comments / a docstring
• Most editors allow you to fold / collapse the function body, so readability of the complete file also improves

[enlupi]

I put them because Brieuc requested them: we wanted clearly separated sections for each subdetector so people could easily add new sections or modify the ones they were responsible for without disturbing the rest of the script. I can try to make them smaller if you think that would help, but i would not get rid of them completely.

Encapsulating them into functions is also an option, let me know what would be preferred.

[tmadlener]

I would have a preference for functions, as that minimizes chances that changes in one "section" influence anything somewhere else.

edit: But in the end it's also up to you a bit and how much time you can / want to invest into going down that route.

[jmcarcell]

Suggested change

	energy = calo.getEnergy()
	hist_ccE.Fill(energy)
	hist_ccE.Fill(calo.getEnergy())

It's easier to read and the intermediate variable isn't doing anything. Same comment for other lines.

[jmcarcell]

Suggested change

	printf "\n\nSIM-DIGI-RECO PHASE:\n"
	echo "\n\nSIM-DIGI-RECO PHASE:\n"

Use only echo for consistency. Same comment for the other occurrences of printf.

[jmcarcell]

Now that I remember it, for metadata it would be fine to remove the key4hep-spack and spack commits; it's not necessary for users to know it and it's already bundled in the stack, so knowing which stack was used lets you know which commits were used. When I wrote this initially, the information of the commits wasn't available in each stack.

[jmcarcell]

I added some style and minor comments on the code. I recommend using a python formatter like ruff or black, both are available in the stack. Then I have some other comments:

• Each geometry having a script to make plots is OK but I feel there is too much repetition but I'm not sure if parts can be abstracted.
• With the new layout space is not used well when there are multiple plots as all of them are in a vertical column.
• There isn't much documentation, for example, what does an expert have to do if they want to add a detector, subdetector or plot to the webpage?

[enlupi]

I saw the changes you suggested, and I agree with most of them.

The most pressing issue now is adding the documentation. Luckily, I have already written a README for my own personal repository that contains all the information you requested: I will update it with the latest changes and submit it asap.

The other issues are mostly "cosmetical", so I will have to give priority to other mandatory tasks like finishing the report before addressing them.

[atolosadelgado]

I added some style and minor comments on the code. I recommend using a python formatter like ruff or black, both are available in the stack. Then I have some other comments:

* Each geometry having a script to make plots is OK but I feel there is too much repetition but I'm not sure if parts can be abstracted.

* With the new layout space is not used well when there are multiple plots as all of them are in a vertical column.

* There isn't much documentation, for example, what does an expert have to do if they want to add a detector, subdetector or plot to the webpage?

Hi Juan

1. You are right about the repetition, but since the same subdetector can be used by different detector concepts and options, I do not see how to abstract that without adding a layer of complexity to it. For example, although the Geant4 simulation uses the full detector, the reconstruction and analysis scripts can be defined for individual subdetectors and then called depending on the detector model). Since the bash script is living somewhere else (FCCconfig), the abstraction should be proposed there right?
2. The layout of the histograms could be tackled in a subsequent PR or do you consider it a showstopper?