[Rivet] problems running rivet

[Hannes Jung]

Dear Andy
thanks a lot for looking into it.
cheers 
Hannes

On 28.02.2011, at 23:33, Andy Buckley wrote:

> No idea, sorry. It seems to be correctly loading the analysis plugins
> but dying when it tries to use one of the registered analyses... hmm.
> 
> It could be related to the known memory issue, which I'm afraid I've not
> had a chance to fix yet and hasn't been high priority because of its
> lack of effect on any of the most used systems. As far as I'm aware
> Rivet does work on Macs -- we have some tests that get run on them, but
> can't be any more help due to my own Mac inexperience. I'll make sure
> that the code is blameless for version 2.0.0... maybe some static
> analysis tools will help us.
> 
> Andy
> 
> 
> On 28/02/11 10:16, Hannes Jung wrote:
>> Dear Andy
>> 
>> thanks a lot for your reply.
>> I have attached the output file using the -lTRACE command.....
>> Does this help ?
>> 
>> Thanks a lot
>> Cheers
>> Hannes
>> 
>> 
>> 
>> 
>> On 28.02.2011, at 10:02, Andy Buckley wrote:
>> 
>>> On 28/02/11 07:17, Hannes Jung wrote:
>>>> Dear Hendrik & Andy
>>>> 
>>>> thanks a lot for your prompt reply (so late on Sunday...)
>>>> 
>>>> Yes, you were absolutely right, it was the wrong beam setting.
>>>> Now it seems to work on lxplus.  Thanks a lot.
>>> 
>>> Good!
>>> 
>>>> Could one include somehow a message, when one is using the
>>>> wrong setting ?
>>> 
>>> It did say "Removing incompatible analysis ATLAS_2010_XXXXXX" before
>>> exiting -- that's meant to be the message. There is time to update that
>>> before our next release, so I'll make it even more explicit.
>>> 
>>>> Is there a way to see, why I still get a seg fault when running on a mac :
>>>> 
>>>>> rivet -a ATLAS_2010_CONF_2010_031 example_out.dat
>>>> Rivet running on machine Hannes-3.local (i386)
>>>> zsh: segmentation fault  rivet -a ATLAS_2010_CONF_2010_031 example_out.dat
>>> 
>>> I have no idea what is going wrong there: Macs have often given us build
>>> problems, but the hourly build and test jobs on our testing Mac are (I
>>> think) working ok. You could try running again with the argument -lTRACE
>>> and send us the output. Or run it through gdb -- this can be done with
>>> Python but might be easier using the less functional rivet-nopy program
>>> which exists specifically for this sort of reason.
>>> 
>>> Andy
>>> 
>>> -- 
>>> Dr Andy Buckley
>>> SUPA Advanced Research Fellow
>>> Particle Physics Experiment Group, University of Edinburgh
>>> 
>>> The University of Edinburgh is a charitable body, registered in
>>> Scotland, with registration number SC005336.
>>> 
>> 
>> ***********************************************************************
>> Hannes Jung 
>> Email: Hannes.Jung at cern.ch
>> mobile :+49 40 8998 93741
>> http://www.desy.de/~jung                                           
>> Tel: +49 (0) 40 8998 3741 (DESY)
>> Tel: +41 22 76 71691 (CERN)       
>> CERN - PH
>> 40-3 B11
>> CH-1211 Genève 23
>> Switzerland
>> ***********************************************************************
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 
> -- 
> Dr Andy Buckley
> SUPA Advanced Research Fellow
> Particle Physics Experiment Group, University of Edinburgh
> 
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
> 

***********************************************************************
Hannes Jung 
Email: Hannes.Jung at cern.ch
mobile :+49 40 8998 93741
http://www.desy.de/~jung                                           
Tel: +49 (0) 40 8998 3741 (DESY)
Tel: +41 22 76 71691 (CERN)       
CERN - PH
40-3 B11
CH-1211 Genève 23
Switzerland
***********************************************************************