Project

General

Profile

StatusMeeting 3262010

Walt - fitting of CLHEP by today, random number service restarted next Thursday

Lynn - still working through the CLHEP issues and will start the build system stuff next week

Configuration in mu2e according to Rob

Slides have links to code and instructions.

Storage of parameter sets is not quite the same as provenance of data. The parameter set DB
will be CVS in the first version.

Rob asks what should be used for geometry and conditions data. Currently it is his private
language. It supports type on the name / value pairs.
He has units. We talked about annotations that indicate units and comments about the variables.

Wants to declare internally the units that will be used. He wants the parameter set system to
manage adherence to the units in the application at convert on input. This requires a declaration
in the parameter set language of units. Unit safety on input wanted. Wants to force units to be
specified. This is a challenge for the parameter set language - we do not have total freedom to
add stuff here. Must be careful of JSON / yaml extensions.

Options:

  1. energy: "5 MeV"
  2. energy: 5 // MeV
  3. energy: 5MeV

Unit conversion from parameter set? trouble. how does this fit into the parameter set package?

What about the "do standard thing except for these exceptions"?

Must take a layered approach to this, where the basic package is not units aware.

examples

Here is an example of mapping Rob's example from the python config into the new parameter new language.
The m1 stuff is highly questionable. It shows how a module with many interfaces could be identified.
Seems unnecessary. Maybe delineating by "interface" is not the right thing. The module knows the
interfaces it adheres to and can inform the system when it is born.

m1 : {
name: "doX1"
type: "CommonModule"
}

EDAnalyzer : [ {
name: "checkhits"
type: "ReadBack"
g4ModuleLabel: "g4run"
minEnergy: 0.001
maxFullPrint: 201
}, {
// ...
},
m1
]

EDProducer : [
// ...
m1
]

Service : [ {
type: "GeometryService"
inputFile: "mu2eG4/test/geom_01.txt"
}, {
// ...
}
]

Substituting values issue

We did not talk about this yet. Will need to do so Monday. We should propose some options
and what the pitfalls / constraints of each (preprocessing and references).

schedule issues

We need to make sure that process is started next week. We should be setting milestones early
next week - one month, two month. Summer is an issue. These milestones need to be aligned with
what is the achievable. The developers will need to dictate this. Need to establish development
target.

The basic examples from mu2e need to be run by all involved.

  • Meeting on Monday - discuss the substitution / reference problems.
  • Meeting on Thursday - discuss the planning and milestones.

Marc's notes below ...