Hi all



I am switching the discussion on v3 from the Exec Board to the full GENIE collaboration list mailing list.

Please let’s use this list for all code / physics devel discussion, and let’s reserve the Exec Board list for collaboration admin stuff.



I have now included in the trunk the Boosted Dark Matter (BDM) module implemented by 

This is awesome work: an implementation of elastic and inelastic dark matter + nucleus scattering. It looks indistinguishable

from our own GENIE code (admittedly the authors developed quite an expertise that we rarely see in other contributors)

and they produced excellent documentation that is already in the Physics and Users manual (trunk version).

It touches on several parts of the code, so I am glad this is out of the way and included in pre-v3 on time for validation.



There is 1 outstanding devel item to finish BDM integration with the trunk. It strikes me to be _exactly_ the same kind of

development we need to deploy splines for each tune without confusion.



The BDM module authors say that, _whenever_ their code is used, it involves a scan over the values of the unknown dark matter mass 

and coupling parameters. To simplify booking-keeping (of splines etc) they included the mass and coupling values into the string code 

used to identify splines (So, a single file contains all splines and they picked the ones with the correct parameter values, out of many alternatives 

ones describing the same process). Unfortunately this introduced some undesired couplings (the low level Interaction objects shouldn’t 

know about algorithm and app configuration options). They removed this feature, but require a workaround.



The string including the dark mass and coupling values is, effectively, a string that identifies their model “tune” (with the dark

matter mass and coupling the two free parameters in their model). 

Seen like this, what **both** they and us require is a method to save the tune name in the spline file.



We should be able to keep in memory (and in the same XML file) the splines for all “tunes”. This is not how we use it in neutrino

mode, but this is how BDM needs to use splines. We need to make sure that, when we add the tune name in the spline file,

the gspladd app (which merges spline files continues to work in a correct manner). 

Also, since the tune name is in the loaded splines, the GENIE event generation code should be able to locate the set of splines for 

which the stored tune name matches the value of the —tune argument. Seems like the easiest way to accomplish that is to tweak 

the XML schema of the spline file 



from:



<genie_xsec_spline_list version=“vrs”>

    <spline name=“blah1” nknots=“n1”> … </spline>

    <spline name=“blah2” nknots=“n2”> … </spline>

</genie_xsec_spline_list>



to something like:



<genie_xsec_spline_list version=“vrs”>

   <tune name=“blah_tune1”>

       <spline name=“blah1” nknots=“n1”> … </spline>

      <spline name=“blah2” nknots=“n2”> … </spline>

   </tune>

   <tune name=“blah_tune2”>

       <spline name=“blah1” nknots=“n1”> … </spline>

      <spline name=“blah2” nknots=“n2”> … </spline>

   </tune>

</genie_xsec_spline_list>

      

I believe this is better than adding the tune as an attribute to the root tag (<genie_xsec_spline_list tune=“blah”>)

since it makes it easier to keep the gspladd app working.



I will be away till Tuesday after the Orthodox Easter (will have e-mail access to discuss, but will be unable to work

on any code devel). If anybody wants to have a go at implementing something like the above would be great.



cheers

Costas