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  December 2018

NEUTRINO-MC-CORE December 2018

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Re: GENIE mtg

From:

Marco Roda <[log in to unmask]>

Reply-To:

Marco Roda <[log in to unmask]>

Date:

Tue, 4 Dec 2018 19:16:24 +0000

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (169 lines)

Hi again, 

  I've just seen Costas' email and the point about having a physicist
helping Julia is extremely valuable. 

About who, I honestly don't know. But following what I said before,
there is probably time to find out. 

In this respect, there are now some people involved in developing new
piece of code for comparisons and professor analyses: there are us here
in Liverpool but also Vlad, who is writing some new hadronization
comparisons in Tufts, and Libo is already able at least to use the
existing code. 

Given the amount of people involved in this kind of activity we can
probably organize some short workshops sooner or later so that they can
fully understand better this part of the code. 
Thus, even someone not experienced in comparisons but aware of the
experimental developments, should be able to catch up kind of easily. 

Cheers, 
  Marco 

Il giorno mar, 04/12/2018 alle 19.06 +0000, Marco Roda ha scritto:
Hi all, 

  I do have thoughts about the development of Minerva and where to best put  JuliaY's effort.

As per one of the incubator of the incubator projects, we are developing a major re-factorization of Comparisons. 
This will require a some small changes in many of the classes we already have, including Minerva. 
This is in order to fully use the tuning machinery and even more, not just a coding exercise, so I believe a bit of maintenance will be unavoidable. 

Nothing is coded right now, we are just designing, and before start coding we will need one (or probably more) dedicated meeting(s). 
I would like to have a full design by the end of December and giving the current status, I believe we can probably have the first of these meetings at the beginning of next year. 

All of this introduction to say that, for the time being and for the next two months, I guess, there is no point to change Minerva database as it's bound to evolve naturally once the new professor interface is ready. 
After the interface is finalized we can have JuliaY going back to minerva development. 
Needless to say that her presence will be at least desirable at the meeting for reviewing the new interface. 

Can that be a plan? Would two months enough to add something stable or kind of to the unit tests? I believe that leaving unfinished businesses is not something we nor JuliaY would like. 

Cheers, 
  Marco 

Il giorno mar, 04/12/2018 alle 18.38 +0000, Dytman, Steven A ha scritto:

Going forward, we are asking Julia to work on expanding unit tests (about 3 

examples in there now) and adding recent data to Comparisons framework, 

e.g. Minerva data is only up to 2015.  Finding right balance between these 

2 tasks is hard.  Any thoughts?


I add Walter because he is her supervisor now and I don't think he's on this list.


Steve

On 12/4/2018 12:09 PM, Constantinos Andreopoulos wrote:
Yes. Interestingly, CCQE sections / Ma reweight is one of the few things for which there is a test, by JuliaY, within the UnitTesting framework.
I hope this is how we caught this error. Would be rather depressing if it was not.
C

On 4 Dec 2018, at 18:03, Gabriel Nathan Perdue <[log in to unmask]> wrote:

Won’t help with this problem now, but in general this also argues for investments in unit tests and even more rigorous automated validation.

pax
Gabe


On Dec 4, 2018, at 11:16, Constantinos Andreopoulos <[log in to unmask]> wrote:



On 4 Dec 2018, at 16:16, Gabriel Nathan Perdue <[log in to unmask]> wrote:


On Dec 4, 2018, at 12:16 AM, Constantinos Andreopoulos <[log in to unmask]> wrote:


I hope we are learning lessons with some of the codes that were developed without planning / designing / documenting, without thinking all aspects through before starting to type lines in the editor. They are codes that we have very hard time understanding,
 evaluating, improving now. Again, a detailed document is a pre-requisite for any new development - We want to see that there is thought put into the design of the code, the integration with and potential ramifications to other parts of GENIE etc.

This project *should* have been caught much earlier, during the development of the new QE generator!!


Creating an incubator project does not amount to just adding a name in the GENIE web page. It amounts to getting that document written, reviewed and agreed.

We have 22 projects (that I know of, and I should have known them all) in incubation, all of which have a GENIE docDB number (see web page) with a skeleton for a detailed planning document (scope / deliverables / milestones / requirements / outline of development
 plan / validation plan / review points / interdependencies with other projects / references etc etc)

This needs to be done properly (and not just mock it up by adding a couple of lines) for all projects we are working on. 


We can and should do project documentation, of course, but I think the take-away from this should be that we really need to partner more firmly with the theorists who wrote the original model. Or possibly provide only interfaces and ask them to
 contribute code that targets those interfaces (and take responsibility for the model functioning). 

As long as we have complete responsibility for everything, we're only going to run into more problems like this and it will only get worse as models get more complicated. Our collaboration doesn't have the bandwidth to manage _all_ of the complexity.

This is true, but in this case the problem is not with a theoretical calculation. 

The problem is how we use an input theoretical calculation to generate 4-vectors. Kinematical transformations / Jacobians and pulling numbers out a p.d.fs is all that is needed here.
So this is firmly on our side, and this is the thing we will always have the responsibility of doing, in order integrate any theoretical calculation into our broader simulation.

Here, the problem is purely a wrong and non-sustainable attitude towards GENIE devel (or softw devel in general): Do the absolute minimum and compress initial development to 1 day, instead of 1 week, tick a box and claim a success, and then spend
 weeks on end trying to figure out problems and refactorize from within a straightjacket. Especially this specific QE code hit us twice to date! Back when Marco was starting to characterise all comprehensive models and writing a detailed tech note, he hit a
 problem there (QE generator was not updating the maximum cross-section used for the acceptance/rejection method as, apparently, all testing was done at a fixed energy and didn’t consider we generate events over a range…). It took Marco/Steve weeks to sort
 that out, because  fixing this brought into sharp focus speed issues etc. It threw us completely off track trying to finish and document the model characterisation.
Just look at this code - It probably took (Andy or Rik or someone else who worked on updating QE modelling) a couple of hrs to put together, starting from a template I provided. It never went beyond being a test code, yet we included it in a public
 version and then it took us weeks and weeks discussing and correcting it. We are still not done and, it seems, a right longer-term course of action is to just rewrite the whole thing anyway! With inefficiencies like this, yes, we don’t have bandwidth to handle
 anything. Interestingly, all people who worked on updating the QE modelling wrote papers on the GENIE implementations and took the credits. Are they still around to help us fix the issues? Which reinforces my belief we should veto any publication or public
 code releases till the work is done to a satisfactory standard.

cheers
C





To unsubscribe from the NEUTRINO-MC-CORE list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=NEUTRINO-MC-CORE&A=1







To unsubscribe from the NEUTRINO-MC-CORE list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=NEUTRINO-MC-CORE&A=1
-- 

Marco Roda, PhD in Physics
Post Doctorate Research Associate

University of Liverpool
Department of Physics 
Oliver Lodge Laboratory
Liverpool L69 7ZE, UK

Mail: [log in to unmask]
Office: +44 (0)151 79 43403 
Mobile: +44 (0)745 381 2081



To unsubscribe from the NEUTRINO-MC-CORE list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=NEUTRINO-MC-CORE&A=1
-- 
Marco Roda, PhD in Physics
Post Doctorate Research Associate

University of Liverpool
Department of Physics 
Oliver Lodge Laboratory
Liverpool L69 7ZE, UK

Mail: [log in to unmask]
Office: +44 (0)151 79 43403 
Mobile: +44 (0)745 381 2081

########################################################################

To unsubscribe from the NEUTRINO-MC-CORE list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=NEUTRINO-MC-CORE&A=1

Top of Message | Previous Page | Permalink

JiscMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

January 2019
December 2018
November 2018
July 2018
June 2018
May 2018
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