Action Items from the meeting:
* Try to meet again in a week or two - Marco will set out a plan for
changes we need to make in the code for the use cases we want to support;
Marco and Robert will communicate about use cases and make sure we have
properly enumerated them.
* Gabe will schedule the meeting by circulating a Doodle poll, etc.
* Make one more round of analysis of the new directory layout - Marco and
Robert should confer on possible external hooks (e.g., external frameworks
may want to instantiate and operate on a `GHepRecord`).
#### GENIE config meeting 2017/December/1
* Marco, Costas, Robert, Gabe
* Current system basically works... ?
* Need to add some default global configs
* CLI already available!
* Re-org `config` directory
* add subdirectories for each tune
* will we remove subdirectories when they become obsolte?
* need to re-org the xml files to reduce the entropy
* `UserPhysicsOptions.xml` is the key file
* we have one in each subdir
* NOTE: so much duplication... is it possible to have a `base` directory others
can 'inherit' from?
* this is the plan
* Get rid of 'Default' everywhere...
* Need to clean up `UserPhysicsOptions.xml`
* Just configure models, not every parameter
* Algorithm configs can all be in the base config directory
* Subdir only contains UserPhysOpts plus maybe one or two other files, then
base config dir contains files that contain the configs within the XML
as, well, configs
* UserPhys
* Constants, bad!
* Params, sort of bad! (e.g., put M_A in one of the Alg config files
in the base config dir)
* `tunable.xml` to make interface to Professor easier (put one in every
'tuning' subdirectory - subdirs of the config subdirs)
* not actually part of the configuration system... or is it?
* `Common_params.xml`?
* Note: I would make this a Python script or something we could run on
top as a separate "product"... we didn't discuss this.
* Spread work over multiple releases?
* This might confuse users... we didn't have time to discuss timelines.
* Wait - how does the configuration actually work?
* Costas educates (code agrees): the _local_ (Algorithm) config takes
priority - if the config is not found there, the registry falls back
to looking in the global config.
* How _should_ the configuraiton work, according to Robert:
* bottom: global if we can't find it (sort of like physical constants)
* next: what is specified in the alg config file
* top: master-override by name - `tunable.xml`
* `tunable.xml` -> should be renamed `config-summary.txt`?
* What is the purpose of this file?
* We probably need to change the code to get the behavior we want.
* (Basically, the behavior we want is we need a file capable of
overriding configurations as they appear in algorithm files.)
* Override and fallback options in `fConfig->GetDoubleDef(...)`?
* We _must_ change the code - what we want to do is not supported at the
moment.
* Completely eliminate the second argument of `fConfig->GetXDef`?
* Change the way it works so there is no confusion over what overrides
what.
* New topic: `src` re-org
* Phys: e.g, `Phys/QuasiElastic/XSec`, and `Phys/QuasiElastic/EvGen`
* What about models that combine, e.g., `QuasiElastic` and `NpNh`?
Add a new "top level" within Phys. -> yes.
* External framework consumers... if they want to store an EventRecord,
need to link to a lot of libs - can we make it easier to do this? e.g.,
separate data structures into separate library - break `Core` into
`DataStructures` and something else (`Algorithms`? seems like a bad name).
* What about things that have the ability to be visited by an `EventRecVisitor`,
etc.?