# Presentation: 388210

## MC, the DB and SAMRick St. Denis - Glasgow

- The DB
- Datasets in SAM: what is there now and what is planned
- What will be done

## DB access in MC

- Look at what is accessed at
- Begin Job
- Begin Run
- Event
- Use Action on “Name Action” and setenv DEBUG 3 to see what an MC job constructed using web instructions does.

##  Accesses:

- Begin Job: CprClusterModule, CentralStripClusterModule, SiClusteringModule
- Begin Run: Calibration Manager
- Event: SimluationControlMod

## What they Access

- CprClusteringModule: CALDigiToGev3,CALL1Peds3,CHASlewing,PHASlewing,WHASlewing,PPRLinEResponse -> All Fail!  Good thing: wrong constants.
- CentralStripClusterModule: Creates Managers
- SiClusteringModule: SiDpsParms (3932 rows from run 138623 version 1)
- Calibration Manager: PROD_PHYSICS_CDF for run 146 v 7 (fails)
- Calorimetry Module: (Creates Managers)
- PesDtoEModule (Prints “No calib in MC”)
- SimulationControlMod (requests managers)

## Problems with this

- Calibrations accessed in begin job BEFORE the manager can decide what you should have
- Mixed policy of allowing code to decide what to do and allowing calibration management.
- TCL contains information on Silicon calibration run to use.

## Suggested solution

- Create valid sets (using tools of used sets) by analysis module: CALDigiToGev3 etc should be in one.
- MC request managers create a used set for the MC run.
- MC validation should include check using the tools action on “Name Action” and setenv DEBUG 3
- Most valid sets should be made once and used many times.  Dead channel handling used in reconstruction.
- Bookkeeping: see sam stuff.

## Suggestion Solution

- MC reps from physics groups manage the calibrations.  Naturally addresses
- How to handle lots of parameters, a physics question.
- Do you want dead ladders? How many CDF detector configurations do you analyze?
- Motivating coders to get the code sorted.

## SAM: DFC and MC

- Everything in DFC is automatically transferred to sam
- mtestc contains lots of datasets
- Filename is mc....test.
- Run numbers distinguish processes
- Look for data in current MC pages and in SAM.

## Slide 9

## Slide 10

## Slide 11

## Slide 12

## Note the mtestc is same as in dfc: 

- Note the mtestc is same as in dfc:
- Work Group is filecatalog
- I will show you how to make the mtestc-top dataset
- You have freedom to clone and restrict
- datasets as you wish

## Slide 14

## Slide 15

## Slide 16

## Slide 17

## Slide 18

## Slide 19

## Slide 20

## Slide 21

## Slide 22

## Slide 23

## Slide 24

## Slide 25

## Slide 26

## Slide 27

## Slide 28

## Dimensions

- A dimension is a nickname for a quantity that can be obtained from ANY part of the database
- Examples: luminosity, run quality etc.
- Definition (6wks) done with “sam add dimension” by sam support.
- For now, run numbers seem sufficient
- Also, if stuff goes into the dfc as mctest, automatically in sam: so use this.

## What is desired

-   o select dataset for a process and with some parameters
-   o discover no events or too few
-   o pick up tcl and fill out a request form
-   o submit request
-   o receive notification that request is fulfilled and
-      the name of the dataset.

- What exists
-   o Table to hold information on request
-   o Indirect storage of datasets through DFC
-   o ability to pick datasets based on dimensions
-      and run AC++

- What is missing
-    o Entry Gui for requests- IS the D0 stuff ok?
-    o API that writes request to database – D0 stuff?
-    o Direct storage into sam with metadata – 1 mo.
-    o Easy definition of dimensions (parameters)

- What is missing
-    o Entry Gui for requests- IS the D0 stuff ok or limited?
-    o API that writes request to database – D0 stuff?
-       can at least get information on db and get a browser
-       page to check requests.
-    o Direct storage into sam with metadata – underway.
-    o Easy definition of dimensions (parameters) – 6 wks.

- Request
-     o Request ID
-     o work group
-     o person
-     o no. events
-     o comments
-     o priority
-     o email
-     o job name
-     o status

- Request Detail
-     o request detail id
-     o request id
-     o application family
-     o status
-     o processing order

- Request status: approved, complete
- finished,hold,new,partial,pending,
- running,terminated.

## MC tools from D0

- Request system: sam create request –dict=GetRequestKeywordDict.py –group=dzero –num-events=100 –comment=“Test job”
- Metadata system (keyword,value) like topmass 170.

## Status of tools

- Submission: in dev
- Modify request: in dev, mostly working
- Modify status: working
- Auto status mods: does not exist
- Request list: does not exist
- Get request: in development
- Keyword addition: being tested

## Additional tasks	

- Add physics parameters that are desired: store with file
- Put TCL portion of schema into production (can browse this now)
- Add request parameters: mc generator, random number, tcl collection id, gen xsect, validation status, physics type.
- Add dimensions for these parameters.
- Program to fetch params from CLOB into param for a file
- Add data run as a parameter in the request and the files as well.

## Who

- Parameters and dimensions: Randy, Matt, etc (SBIR)
- GUI – Iain Bertram?
- Enter parameters and try: Rick,Frank,Dave
- Clob to param: Stefan (after batch adapter)

## Conclusions

- Physics groups need to get the DB access under control and use present procedure for valid sets and make used sets
- Currently can make datasets based on things entered via the DFC and on run numbers and run AC++ from these files.
- Development under way to query datasets with richer choice of parameter
- Development underway but date unclear for Gui submission.