Project

General

Profile

Idea #13997

Job-level segregated fcl directory in sbndcode

Added by Dominic Brailsford about 3 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Start date:
10/03/2016
Due date:
% Done:

0%

Estimated time:
Duration:

Description

The mcc xml generation script tries to find a generator level fcl folder and subsequently produces mcc projects based around each gen-level fcl file that it finds.
We do not currently have this directory level separation of our fcl files.

I have started a feature branch (feature/dbrailsf_mcc1.0) with the following fcl directory structure:
srcs/sbndcode/fcl/gen/single

After a small tweak to the mcc xml script in sbndutil, I am now able to produce xml files for the MCC.

I propose we either use this job level fcl folder structure (as the other experiments already do) or we go about cleaning up the JobConfiguration directory already in sbndcode.

As I need this for the MCC, I am happy to implement whatever is decided.

History

#1 Updated by Gianluca Petrillo about 3 years ago

I was pursuing a lazy approach to the second option (cleaning of JobConfigurations).
Your proposal has value to me, though.
But I request that job configurations are individually tested before they are moved from JobConfigurations.
It would be good for them to have common patterns (one I like you can find in prod_eminus_0.1_0.9_sbnd.fcl and standard_reco_sbnd_basic.fcl).
For the generator jobs, it would be good to have unit tests exercising them (see test/JobConfigurations/CMakeLists.txt for inspiration, but it's not necessary to have a script for each job).

#2 Updated by Dominic Brailsford about 3 years ago

  • Subject changed from Job level segregated fcl directory in sbndcode to Job-level segregated fcl directory in sbndcode

Gianluca Petrillo wrote:

I was pursuing a lazy approach to the second option (cleaning of JobConfigurations).
Your proposal has value to me, though.
But I request that job configurations are individually tested before they are moved from JobConfigurations.
It would be good for them to have common patterns (one I like you can find in prod_eminus_0.1_0.9_sbnd.fcl and standard_reco_sbnd_basic.fcl).
For the generator jobs, it would be good to have unit tests exercising them (see test/JobConfigurations/CMakeLists.txt for inspiration, but it's not necessary to have a script for each job).

I agree with the tests.
I also do not have strong opinions either way about creating a new fcl directory or cleaning up JobConfigurations.
What I do care about is semi-automating MCC xml production and which way we pick has direct implications on that procedure.

I have noticed that at least one fcl file (I think it was prodgenie_sbnd_proj.fcl) did not run so some cleaning will need to be done either way.

I think we should agree on a way to proceed and then I can start making amendments as I'm keen on getting MCC stuff up and running.
Right now I am very slightly leaning towards a new fcl directory, only because I've already done this in my feature branch and my MCC script uses this new directory. Additionally, going this route provides a natural means of testing the fcl files (they have to be tested before being added to the directory).

Thinking out loud, we could use the JobConfigurations folder to store the generic fcl files which provide the common patterns (kind of like abstract base classes) and use the new fcl (sub)directories to provide user-level fcl files that should run out of the box which is what is needed for MCC jobs.

#3 Updated by Dominic Brailsford over 2 years ago

  • Status changed from New to Closed
  • Target version deleted (v05_12_01)

The fcl directory now exists and is populated with generator, g4, and anatree level fcl files.
The unit tests do NOT exist yet but I think thats deserving of a separate issue.

I think we are probably done here so I'll close the issue.



Also available in: Atom PDF