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
