[Rivet] Time for Rivet 2.5.3?

[Andy Buckley]

Inside ATLAS we just got forwarded the question again, though, except 
they want to use Minuit. Which in its simplest form would require 
compiling against ROOT and all the hell that comes with it.

We can't have that as a package dependency. But we could start thinking 
about whether (again) a more distributed mechanism for analysis 
deployment could work -- extended from previous thoughts on that matter 
to include extra build dependencies and compiler -I/-L/-l flags in the 
.info file, which would then be used by rivet-buildplugin.

I'm not keen, but if the demand for fastjet contrib, minimisers, MT* 
variables, etc. continues then we need to respond, and I don't have a 
better idea. Does anyone else?

Yeesh,
Andy


On 09/12/16 09:16, David Grellscheid wrote:
> Fine, then let's go ahead with removing GSL
>
>   David
>
>
> On 07/12/16 14:00, Chris Pollard wrote:
>> To be honest I don't really have details. It was mentioned for one of
>> the Atlas top analyses which performs a fit "after unfolding". The
>> contact for that analysis is a graduating student who won't have time to
>> implement in Rivet, so it's unclear when we will actually have someone
>> attempting to write this thing. I think it'd be better if we did not
>> provide a fitting library (even via dependency).
>>
>> On Wed, Dec 7, 2016 at 1:55 PM, David Grellscheid
>> <david.grellscheid at durham.ac.uk <mailto:david.grellscheid at durham.ac.uk>>
>> wrote:
>>
>>
>>     >>> Amazing, thank you! Changes like that on the "default" branch (aka
>>     >>> trunk), please -- and you can re-apply your GSL removal there, if not
>>     >>> already done. Thanks!
>>     >> Ok will do, Chris however mentioned that some people wanted to use gsl
>>     >> stuff in an analysis,
>>     >> I think some minimisation stuff, not sure what do do now.
>>     >
>>     > Hmm, that's a first. Any details, Chris?
>>     >
>>     > Fits into the general question of "what external libs do we allow?".
>>     >
>>     > The GSL interface is actually pretty nasty from a C++ perspective, so I
>>     > think it'd be best if we could avoid exposing all that raw-C-array, raw
>>     > pointers, etc. stuff to analysis users... but what's the alternative?
>>     > Pity Minuit isn't available anymore without hauling in the rest of ROOT,
>>     > and all its runtime foibles & attempts to grab the wheel :-/
>>
>>     I'm still very excited about removing GSL completely, so we'll have to
>>     look at that individual case. Is it such a complicated minimization that
>>     we need something like Minuit for it or can we make use of a simpler
>>     function we can include in the analysis?
>>
>>     See you,
>>
>>       David
>>
>>
>>     _______________________________________________
>>     Rivet mailing list
>>     Rivet at projects.hepforge.org <mailto:Rivet at projects.hepforge.org>
>>     https://www.hepforge.org/lists/listinfo/rivet
>>     <https://www.hepforge.org/lists/listinfo/rivet>
>>
>>
> _______________________________________________
> Rivet mailing list
> Rivet at projects.hepforge.org
> https://www.hepforge.org/lists/listinfo/rivet
>


-- 
Dr Andy Buckley, Lecturer / Royal Society University Research Fellow
Particle Physics Expt Group, University of Glasgow