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