Hi all,

as you probably know, we are working on some software reorganization in order to release genie v3.

A major feature will be the possibility to have a number of global configurations, called CGC (comprehensive global configuration) and each of them can have a number of tuning against public data using the new genie/professor machinery.

In the repository, there is now a development branch called v3config https://genie.hepforge.org/trac/browser/generator/devel/branches/v3config which already allows this new feature.

Your are welcome to try it and report any issues you can find.

The tunes already implemented are

G16_01b

G16_02a

G16_02a_01_003

and you can simply call them using the option --tune followed by the tune (or CGC) name.

Valid examples:

gevegen --tune G16_02a

gmkspilne --tune G16_02a_01_003

You can find the description of the CGC here https://genie.hepforge.org/load.php?include=comprehensive_models

while G16_02a_01_003 is an example of tuning against dataset, the only difference with respect to G16_02a is that some parameters are changed.

This is implemented creating a substructure of directories in the config directory.

This is not the only change which happened in the code: we are also reorganizing the parameters input, as there is a lot of confusion. 

As a first step we changed the parameter names so that they are uniform across the whole code. Before that, the variables names depended on the xml file they were obtained from. For example QEL-Ma was just Ma in a number of algorithms and was QEL-Ma only in UserPhysicsOptions. 

This was creating a lot of potential ambiguities.

Having the same names would allow to move all the parameters from UserPhysicsOptions, as it is not supposed to be the xml file containing parameters, only algorithm configurations. Parameters were supposed to be the exception but they became the rule.

Practically, most of this job is already done: all the parameters are already copied from UserPhysicsOption to their corresponding xml files.

What needs not be done is to remove the parameters from UserPhysicsOptions.

This has not been done because of the way the code is written: if we remove the parameters from UserPhysicsOption, the code will crush since the default configurations are read from Registries without the default option.

In order to do that, we plan to add another access method to the registry in order to look for parameters within a vector of registries.

Once again, if something is not working you are welcome to let me or Costas know.

All the best,

Marco Roda

--