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:

Re: [Genie] mtg Monday, Apr 9 11am ET

From:

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

Reply-To:

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

Date:

Thu, 12 Apr 2018 15:18:03 +0000

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (1 lines)

Yes, I believe we have all agreed that tunes will not change (except bug fixes only). We can add revisions of the existing tunes (if necessary) with new names as tuning work continues throughout the v3 lifecycle. Then, moving on to v4, with all the necessary clean up and removal of outdated models, it won’t be possible to maintain all the v3 tunes. We can make a choice though to try to preserve some of the most successful and commonly used ones (almost) as is (as we do now with the G00xyz tunes), but generally this won’t be possible. However, most of the v4 tunes will be evolutions of the v3 tunes and you can try to emphasise continuity. But I think the lifetime of a tune, to first order, is the same as the lifetime of a major release. 
cheers 
C 
 
On 12 Apr 2018, at 17:35, Steven Dytman <[log in to unmask]<mailto:[log in to unmask]>> wrote: 
 
Good start.  A bevy of numbers is mostly safe but also confusing. 
We may need to make an app that decodes the numbers. 
I find that dates rather numbers are useful because it's hard to have 
multiple tunes in 1 day.  We could expand that field or replace the xxx field. 
 
To make any tune truly safe, it has to be in svn or file protected. 
Svn will definitely help make a tune solid. 
 
Steve 
 
On 4/12/2018 10:21 AM, Gabriel Nathan Perdue wrote: 
I would propose tunes, e.g., "G18_10i_00_001", etc., never change. We can update them to, e.g. "G19_10i_00_001" in 2019 (or now, at the cost of a bit of confusion), or if we want to keep the year marker strictly maintained, we could have "G18_10i_00_001a", which, amazingly actually adds to the already very specific description of the tune. 
 
Of course, if one changes the data being used for the tune or the group of parameters included, that bumps different parts of the name string and then you don't need to worry about adding anything. I say we try: 
 
* keep tunes frozen once made, 
* bump the year if we really have to redo a tune with the same configuration, parameters, and data regardless of what year it is. 
 
Recall from Costas's doc, that for Gdd_MMv_PP_xxx, that 
 
* dd specifies the year, 
* MMv specifies the model configuration, 
* PP specifies a code for the set of parameters included in the tune, and 
* xxx is a look-up key that identifies the data included in the tune. 
 
Gabriel Perdue 
Associate Scientist 
 
Scientific Computing Division 
Fermi National Accelerator Laboratory 
PO Box 500, MS 234, Batavia, IL 60510, USA 
[log in to unmask]<mailto:[log in to unmask]> 
Office: 630-840-6499 
Cell: 630-605-8062 
 
Connect with us! 
Web<http://www.fnal.gov> | Facebook<http://www.facebook.com/Fermilab> | Twitter<https://www.twitter.com/fermilab> 
 
On Apr 12, 2018, at 8:51 AM, Steven Dytman <[log in to unmask]<mailto:[log in to unmask]>> wrote: 
 
Yes, I'm glad you agree.   No, it wasn't discussed last Monday. 
Question on my mind - will tunes change?  We must somehow keep them constant. 
 
Steve 
 
On 4/12/2018 9:39 AM, Costas Andreopoulos - UKRI STFC wrote: 
We need to sort out a mechanism to associate a group of splines with a tune. Was that discussed at the meeting? 
cheers 
C 
 
On 9 Apr 2018, at 19:04, Steven Dytman <[log in to unmask]<mailto:[log in to unmask]>> wrote: 
 
Steve Dennis, Gabe, Robert, and I met this morn. 
We are now aiming for code freeze Apr 18, Wed next week.  US Taxes will be 
done and we will all be working with renewed vigor. 
 
Robert made 4 splines last week and will post them soon.   I will look at them. 
 
Gabe is getting Julia to set up validations to work with versions other than G00_00a. 
We agree that G18_10i is interesting. 
 
Steve D is working on reweight.  Right now, it doesn't work and Marco is working 
on fixes to registry to make it happen.  Steve guesses this will finish this week. 
 
I haven't looked at Llewellyn-Smith or reweighting yet. 
 
Marco says code is stable.   I was having trouble with CCRES this morn, I think it's 
settled after I updated more carefully. Any other issues? 
 
regards, 
Steve 
 
On 4/9/2018 10:40 AM, Roda, Marco wrote: 
Hi all, 
 
  I have another meeting at the same time and I won't be able to 
attend. 
 
Anyway, I'd like to report a few things. 
Last week, together with Julia Vidal, our PhD student, we started the 
tuning using professor of the old default. 
The system is stable: we have a generation with 500 points in a 7D 
parameter space. This is enough to build a 4th order polynomial in the 
parameter space and we are in the process of trying the result of the 
minimization procedure. 
This is another way to say that the whole chain that looks for external 
configuration and tunes has been tested and it's doing what we thought. 
Also, the usage of the Tunable special parameter set has been 
extensively tested in this process and it's working. 
 
Second thing which is worth reporting about the code. While 
investigating with Steve Dennis about the reweighing issue I found a 
problem in the Registry class. 
 
The problem is in line 975 of Registry.cxx 
 
fRegistry.insert(reg_entry); 
 
The whole function (Append) is always creating new memory but because 
of the way the std::map::insert is working, sometimes it is not saved 
in the memory, hence we leak memory. This is a very old problem and 
unrelated to the v3 updates. 
The right thing to do would be to check if the insertion is successful 
and if not, delete the memory. 
 
I plan do add a similar method called Merge for Registry as we need a 
method to override existing entries which insert is not doing. 
I can fix this issue at the same time. 
 
ETA 2 days. 
 
Sorry for the long email. 
 
Cheers, 
  Marco 
 
 
 
Il giorno ven, 06/04/2018 alle 15.22 -0400, Steven Dytman ha scritto: 
Hi, 
It seems appropriate to have a mtg Monday at usual time.  Last week 
wasn't 
as quiet as might have been hoped but good progress was made.  Seems 
worthwhile 
to assess where we are.  I am hopeful there are some new splines and 
some 
simulation runs.  We also need to assess status of code. 
 
Hi there, 
 
Steven Dytman is inviting you to a scheduled Zoom meeting. 
 
Topic: Steven Dytman's Personal Meeting Room 
 
Join from PC, Mac, Linux, iOS or Android: https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffnal.zoom.us%2Fj%2F4126&data=01%7C01%7Cdytman%40pitt.edu%7C03507e2551ae402d93b908d59e27d145%7C9ef9f489e0a04eeb87cc3a526112fd0d%7C1&sdata=bygRi0%2B4WGVho2hFZWvOc7qvfG2vdk3yflu66WmsbcE%3D&reserved=0 
249244 
 
Or iPhone one-tap : 
     US: +16465588656,,4126249244#  or +16699006833,,4126249244# 
Or Telephone: 
     Dial(for higher quality, dial a number based on your current 
location): 
         US: +1 646 558 8656  or +1 669 900 6833 
     Meeting ID: 412 624 9244 
 
regards, 
Steve 
 
 
regards, 
Steve 
 
_______________________________________________ 
GENIE mailing list 
[log in to unmask]<mailto:[log in to unmask]> 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.hepforge.org%2Flists%2Flistinfo%2Fgenie&data=01%7C01%7Cdytman%40PITT.EDU%7C9a005351509140eb336708d5a07afa70%7C9ef9f489e0a04eeb87cc3a526112fd0d%7C1&sdata=VNUcF7AS18Z6JYzv5iFWomImyLzR1ssQKPeU1gYbFBo%3D&reserved=0 
 
 

Top of Message | Previous Page | Permalink

JiscMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

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