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
|
