JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for NEUTRINO-MC-CORE Archives


NEUTRINO-MC-CORE Archives

NEUTRINO-MC-CORE Archives


NEUTRINO-MC-CORE@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

NEUTRINO-MC-CORE Home

NEUTRINO-MC-CORE Home

NEUTRINO-MC-CORE  April 2018

NEUTRINO-MC-CORE April 2018

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Done adding BDM in the trunk / Next necessary devel before v3 freezing

From:

Costas Andreopoulos - UKRI STFC <[log in to unmask]>

Reply-To:

Costas Andreopoulos - UKRI STFC <[log in to unmask]>

Date:

Wed, 4 Apr 2018 12:13:04 +0000

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (1 lines)

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 
 
 
 
 

Top of Message | Previous Page | Permalink

JiscMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

April 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
August 2016
June 2016
April 2016
March 2016
February 2016
January 2016
December 2015
April 2015
March 2015
September 2014
July 2013
June 2013
May 2013
April 2013
March 2013
September 2012


JiscMail is a Jisc service.

View our service policies at https://www.jiscmail.ac.uk/policyandsecurity/ and Jisc's privacy policy at https://www.jisc.ac.uk/website/privacy-notice

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager