Hi Ben,
the one missing piece of information is, like you said, whether the
HepMC files that were used contain 'U' lines (should do after 2.04).
They contain the authoritative unit information. Then next check is if
the numbers in the HepMC file match that unit assignment.
(A)
If the HepMC file has 'U' lines, but is inconsistent, the producer is at
fault. If the HepMC file is consistent, we'd have to look into Rivet
instead.
(B)
For legacy HepMC files without 'U' lines,
* Rivet linked to old HepMC will as far as I can tell always assume
GEV+MM (that's why >2.05 is recommended). Most generators linked with
old HepMC also produce GeV+MM, so it works fine by chance.
* Rivet linked to new HepMC will take the units from HepMC's configure line.
I hope I've covered all options here. Please correct me if I've made any
mistakes.
David
Ben Waugh wrote:
> Hi Sercan, and Rivet experts in case someone can tell us what we should
> really be going,
>> Aha! Thanks, Sercan. It appears there was a change in the way units are
> handled in HepMC version 2.04:
>http://lcgapp.cern.ch/project/simu/HepMC/20400/#units>> The configure log for the HepMC version I am using is at
> /afs/cern.ch/sw/lcg/external/HepMC/2.06.03/logs/hepmc_x86_64-slc5-gcc43-opt_config.log
> and includes "--with-momentum=MEV". What event file or generator are you
> using as input to Rivet? What version of HepMC format is it using?
> Looking at the standard output from your job using the newer HepMC
> <http://www.hep.ucl.ac.uk/~ssen/DEBUG/Rivet130/rivet130wBoost144> it
> seems that the beam energies are being interpreted as 3.5 GeV, so I
> guess the generator just says "3500" and is interpreted as either GeV or
> MeV depending on the HepMC version linked with Rivet.
>> The Rivet home page recommends "HepMC 2.05 or later" and I think we will
> need to understand what is going on properly at some point, so we can
> deal correctly with different generators and versions.
>> Meanwhile, the version of Sherpa we are using from
> /afs/cern.ch/sw/lcg/external/MCGenerators/sherpa/1.2.2p/x86_64-slc5-gcc43-opt
> is configured with HepMC 2.03.11 so I guess that is more useful to Jack
> and David at the moment.
>> I would suggest David and Jack use Sercan's installation for now:
> /unix/cedar/software/slc5/rivetenv-1.3.0.p2.sh
>> Cheers,
> Ben
>>> On 29/10/10 15:18, Sercan Sen wrote:
>> Hi Ben
>>>> When I ran my analysis with this configuration some of the plots were
>> really odd. However, I haven't had time to search for the reason this
>> week and I've stayed with the previous configuration.
>>>> Anyway, I've just figured out the problem with this configuration !!
>>>> First, I check the standard analysis; MC_LEADINGJETS .
>>>> _Rivet 1.3.0 with HepMC_2.03.11 and Boost_1.42_
>>>> Rivet.Analysis.Handler: DEBUG Event #2 weight = 1
>> Rivet.Analysis.Handler: DEBUG About to run analysis MC_LEADINGJETS
>> Rivet.Analysis.MC_LEADINGJETS: DEBUG Jet multiplicity = 34
>> Rivet.Analysis.MC_LEADINGJETS: DEBUG Leading jet: pT = _7.07939 GeV_, eta = -1.86541, phi = 2.09819
>> Rivet.Analysis.Handler: DEBUG Finished running analysis MC_LEADINGJETS
>>>>>> _Rivet 1.3.0 with HepMC_2.06.01 and Boost_1.44_
>>>> Rivet.Analysis.MC_LEADINGJETS: DEBUG Vetoing event on line 64 of MC_LEADINGJETS.cc
>> Rivet.Analysis.Handler: DEBUG Event #2 weight = 1
>> Rivet.Analysis.MC_LEADINGJETS: DEBUG Jet multiplicity = 34
>> Rivet.Analysis.MC_LEADINGJETS: DEBUG Leading jet: pT = _0.00707939 GeV_, eta = -1.86541, phi = 2.09819
>>>>>> As you see, the second configuration uses Units::TeV !!
>>>> I've checked this issue by writing a simple routine which prints the pT
>> of the leading jet.
>>>> the code is here;
>>http://www.hep.ucl.ac.uk/~ssen/DEBUG/Rivet130/JETS_TEMPLATE.cc>>>> and all the results / log files are here;
>>http://www.hep.ucl.ac.uk/~ssen/DEBUG/Rivet130/>>>> The situation is the same when I run my analysis routine instead of a
>> standard analysis in Rivet.
>>>> This is not related with the version of Rivet. I haven't checked the
>> "ChangeLog" files of HepMC or Boost yet !
>>>> Cheers
>> Sercan
>>>>>>>>>>>>>>>>>>>> On Oct 29, 2010, at 7:58 AM, Ben Waugh wrote:
>>>>> Hi Sercan,
>>>>>> Can you be a bit more specific about what does not work? Apart from
>>> the NeutralFinalState projection that is, which does not seem to have
>>> been fixed even in the trunk version.
>>>>>> Cheers,
>>> Ben
>>>>>> On 29/10/10 04:30, Sercan Sen wrote:
>>>> Hi Ben, all
>>>>>>>> On Oct 28, 2010, at 10:35 PM, Ben Waugh wrote:
>>>>>>>>> Hi Jack, David, Sercan,
>>>>>>>>>> Following various problems, mostly reported by Sercan, I have
>>>>> installed the newest version of the 1.3.0 Rivet tag from Subversion in
>>>>> /unix/cedar/software/slc5/rivet-test. You should be able to use it by
>>>>> first typing:
>>>>> source /unix/cedar/software/slc5/rivetenv-test.sh
>>>>>>>>>> Sercan, can you test this and see if it works for you? It includes the
>>>>> fixes recently made by Andy and Hendrik to the source code and build
>>>>> files, and is linked to FastJet 2.4.2 instead of 2.4.2p3.
>>>>>>>> I've actually tested the below configuration before. I believe, it does
>>>> not work in some parts *!! , That's why, I use this configuration -->
>>>> /unix/cedar/software/slc5/rivet-1.3.0.p2/config.log
>>>>>>>>>>>> Boost-1_44
>>>>>>>> HepMC_2.06.01
>>>>>>>> FastJet_2.4.2p3 --> FastJet_2.4.2
>>>>>>>> swig_2.0.1
>>>>>>>> At least one of the bug in your current installation is in the
>>>> NeutralFinalState projection. We realized it when we were working with
>>>> James M. last week and he informed Hendrik. I mean, they know the story
>>>> but maybe they forget to fix the bug. Because, when I run the current
>>>> installation and look to the neutralfinalstate projection, it returns
>>>> particles like 2212, 211, 321.
>>>>>>>> This line in NFS projection
>>>>>>>> //if ((PID::threeCharge(p.pdgId()) != 0) && (p.momentum().Et() >
>>>> _Etmin)) {
>>>> // _theParticles.push_back(p);
>>>>>>>> should be modified like this;
>>>>>>>> if ((PID::threeCharge(p.pdgId()) == 0) && (p.momentum().Et() > _Etmin)) {
>>>> _theParticles.push_back(p);
>>>>>>>> * Some of the results have really large discrepancy when I run this with
>>>> this configuration. I haven't have time to look them this week but
>>>> I'll do.
>>>>>>>>>>>>> Jack, can you try it too and see if it works? The errors in the log
>>>>> file you posted on the web indicate that you are trying to install
>>>>> your own version over the top of mine in /unix/cedar, and that is not
>>>>> allowed! I'm not sure if that is what you were trying to do. If the
>>>>> installed version is not working, which apparently it wasn't, let me
>>>>> know so I can fix it. If you need or want to install your own version
>>>>> you should do it in a separate directory, either in your own home
>>>>> directory or by making yourself a directory /unix/cedar/jpegler. We
>>>>> can talk about this tomorrow if you like: I'll be around most of the
>>>>> day.
>>>>>>>>>> If this "rivet-test" version works I'll replace the existing
>>>>> rivet-1.3.0 installation.
>>>>>>>>>> Cheers,
>>>>> Ben
>>>>>>>> Cheers
>>>> Sercan
>>>>>>>>>>>>>>>>>>>>>> On 28/10/10 20:54, Jack O Pegler wrote:
>>>>>> Hi,
>>>>>>>>>>>> as I spoke to Ben about earlier in the week, I'm having a little
>>>>>> trouble
>>>>>> getting rivet going. I've sort of got it going a couple of times once
>>>>>> using the twiki instructions and once using the instructions from the
>>>>>> rivet homepage.
>>>>>>>>>>>> Both times I've got down to the last few points with everything fine,
>>>>>> then
>>>>>> it all seems to go a bit wrong. Despite that I did manage to run an
>>>>>> analysis i think (or at least got some .aida files out).
>>>>>>>>>>>> I wiped rivet off my account this afternoon and attempted to
>>>>>> re-install,
>>>>>> it went better than the last few times (I got all the way down to the
>>>>>> last
>>>>>> point -make install) and got a different error.
>>>>>> (http://www.hep.ucl.ac.uk/~jpegler/)
>>>>>>>>>>>> I guess what I'm getting at in a very round about way is, if this is a
>>>>>> common problem that I should just keep installing and one time it will
>>>>>> work? or does it not matter so long as I get most of the way down the
>>>>>> instructions.
>>>>>>>>>>>> In better news, I did manage to run a HERA_DIS simulation successfully!
>>>>>> Thanks, and sorry for the long message!!
>>>>>>>>>>>> Jack
>>>>>>>>>>>>>>>>> --
>>>>> Dr Ben Waugh Tel. +44 (0)20 7679 7223
>>>>> Dept of Physics and Astronomy Internal: 37223
>>>>> University College London
>>>>> London WC1E 6BT
>>> --
>>> Dr Ben Waugh Tel. +44 (0)20 7679 7223
>>> Dept of Physics and Astronomy Internal: 37223
>>> University College London
>>> London WC1E 6BT
>