RelVals 2500.{325,403} failing in ROOT6_X (wrong type of arguments)

[iarspider]

Full logs: 1, 2

----- Begin Fatal Exception 09-Apr-2024 02:58:12 CEST-----------------------
An exception of category 'StdException' occurred while
   [0] Processing  Event run: 367771 lumi: 5 event: 9075325 stream: 0
   [1] Running path 'NANOAODoutput_step'
   [2] Prefetching for module NanoAODOutputModule/'NANOAODoutput'
   [3] Calling method for module SimpleCandidateFlatTableProducer/'customJetExtTable'
Exception Message:
A std::exception was thrown.
method named "get" for type "reco::TaggingVariableList" was passed the wrong types of arguments.
----- End Fatal Exception -------------------------------------------------

Possible cause: #43485

[iarspider]

assign xpog,reconstruction

[cmsbuild]

New categories assigned: xpog,reconstruction

@vlimant,@hqucms,@jfernan2,@mandrenguyen you have been requested to review this Pull request/Issue and eventually sign? Thanks

[cmsbuild]

cms-bot internal usage

[cmsbuild]

A new Issue was created by @iarspider.

@antoniovilela, @sextonkennedy, @Dr15Jones, @makortel, @rappoccio, @smuzaffar can you please review it and eventually sign/assign? Thanks.

cms-bot commands are listed here

[vlimant]

what's an IB we can look at this in ?

[iarspider]

what's an IB we can look at this in ?

The failures are in ROOT6_X IB: RelVal 2500.325, RelVal 2500.403

They don't appear in other IB flavors

[Dr15Jones]

I took a look a quick look at the problem. It seems customJetExtTable passes enum values to the cut parser (which passes them to reco::TaggingVariableList::get) as strings. That is supposed to work. What happens internally is the cut parser asks ROOT what are the function arguments for the function in question (here reco::TaggingVariableList::get) and then tries to see if it can convert the value passed to the parser (either an int, float or a string) to the type needed by the function. If the function argument is an Enum, the parser asks ROOT for the names of all the enums and then compares them to the string passed to the cut parser. If there is no match, one will get that exception message.

So it is probably that enum handling in ROOT 6 has changed and that is causing this problem.

[Dr15Jones]

assign root

[Dr15Jones]

@pcanal this problem happened right when we moved to the head of ROOT's master branch.

cms-sw/cmsdist#9127

[makortel]

type root

[pcanal]

@Dr15Jones So far, I can not see any commit that would have changed the behavior.

[iarspider]

Happened in CMSSW_14_1_ROOT632_X_2024-04-29-2300: RelVal 2500.325, RelVal 2500.403 and in CMSSW_14_1_ROOT6_X_2024-04-29-2300: 2500.325, 2500.403

----- Begin Fatal Exception 30-Apr-2024 08:35:37 CEST-----------------------
An exception of category 'Configuration' occurred while
   [0] Constructing the EventProcessor
   [1] Constructing module: class=SimplePATJetFlatTableProducer label='customJetExtTable'
Exception Message:
Expression parser error:method named "get" for type "reco::TaggingVariableList" was passed the wrong types of arguments. (char 38)
----- End Fatal Exception -------------------------------------------------

[Dr15Jones]

A trivial reproducer is

import FWCore.ParameterSet.Config as cms

process = cms.Process("TEST")

process.source = cms.Source("EmptySource")

process.maxEvents.input = 1

process.test = cms.EDProducer("SimplePATJetFlatTableProducer",
    cut = cms.string(''),
    doc = cms.string('slimmedJetsPuppi, i.e. ak4 PFJets Puppi with JECs applied, after basic selection (pt > 15)'),
    extension = cms.bool(True),
    name = cms.string('Jet'),
    singleton = cms.bool(False),
    src = cms.InputTag("linkedObjects","jets"),
    variables = cms.PSet(
        DeepCSV_flightDistance2dSig = cms.PSet(
            doc = cms.string('transverse distance significance between primary and secondary vertex'),
            expr = cms.string("tagInfo(\'pfDeepCSV\').taggingVariables.get(\'flightDistance2dSig\', -999)"),
            lazyEval = cms.untracked.bool(False),
            precision = cms.int32(10),
            type = cms.string('float')
        )
                )
        )

process.p = cms.Path(process.test)

[Dr15Jones]

So I took a look and the function being called in

cmssw/DataFormats/BTauReco/interface/TaggingVariable.h

Line 235 in ba95554

TaggingValue get(TaggingVariableName tag, TaggingValue defaultValue) const;

Where the first argument is

cmssw/DataFormats/BTauReco/interface/TaggingVariable.h

Line 30 in ba95554

enum TaggingVariableName {

which is the namespace reco::btau

However, there is a using done here

cmssw/DataFormats/BTauReco/interface/TaggingVariable.h

Line 170 in ba95554

using btau::TaggingVariableName;

which moves those enums into the reco namespace. I believe this is causing the problem.

In pure root.exe I do

root [0] auto c = TClass::GetClass("reco::TaggingVariableList")
root [1] auto m = c->GetListOfMethods()
root [2] for( auto i: *m) { std::cout << static_cast<TMethod*>(i)->GetName()<<std::endl; for (auto j: *static_cast<TMethod*>(i)->GetListOfMethodArgs()) { std::cout << "  "<<static_cast<TMethodArg*>(j)->GetTypeName()<<std::endl;}}
TaggingVariableList
TaggingVariableList
  reco::TaggingVariableList
operator=
  reco::TaggingVariableList
size
begin
end
push_back
  reco::TaggingVariable
~TaggingVariableList
checkTag
  reco::TaggingVariableName
insert
  reco::TaggingVariable
  bool
insert
  reco::TaggingVariableList
insert
  reco::TaggingVariableName
  reco::TaggingValue
  bool
insert
  reco::TaggingVariableName
  vector<reco::TaggingValue>
  bool
finalize
get
  reco::TaggingVariableName
get
  reco::TaggingVariableName
  reco::TaggingValue
getList
  reco::TaggingVariableName
  bool
getRange
  reco::TaggingVariableName
operator[]
  reco::TaggingVariableName
root [20] auto c2 = TClass::GetClass("reco::TaggingVariableName")
(TClass *) nullptr
root [21] auto c2 = TEnum::GetEnum("reco::TaggingVariableName")
(TEnum *) nullptr
root [22] auto c2 = TEnum::GetEnum("reco::btau::TaggingVariableName")
(TEnum *) 0x4f163f0
root [23] auto c2 = TEnum::GetEnum("reco::btau::TaggingVariableName")
(TEnum *) 0x4f163f0

So the name reco::TaggingVariableName is unknown to ROOT, but reco::btau::TaggingVariableName is know.

If I run the exact same code in our standard release, the member data types are the full namespaced versions:

In CMSSW_14_1_X_2024-04-24-1100

root [2] for( auto i: *m) { std::cout << static_cast<TMethod*>(i)->GetName()<<std::endl; for (auto j: *static_cast<TMethod*>(i)->GetListOfMethodArgs()) { std::cout << "  "<<static_cast<TMethodArg*>(j)->GetTypeName()<<std::endl;}}
TaggingVariableList
TaggingVariableList
  reco::TaggingVariableList
operator=
  reco::TaggingVariableList
size
begin
end
push_back
  reco::TaggingVariable
~TaggingVariableList
checkTag
  reco::btau::TaggingVariableName
insert
  reco::TaggingVariable
  bool
insert
  reco::TaggingVariableList
insert
  reco::btau::TaggingVariableName
  reco::TaggingValue
  bool
insert
  reco::btau::TaggingVariableName
  vector<reco::TaggingValue>
  bool
finalize
get
  reco::btau::TaggingVariableName
get
  reco::btau::TaggingVariableName
  reco::TaggingValue
getList
  reco::btau::TaggingVariableName
  bool
getRange
  reco::btau::TaggingVariableName
operator[]
  reco::btau::TaggingVariableName

[Dr15Jones]

@pcanal what changed in ROOT 6.33/01 that caused TMethodArg to now give the type of the enum as the using version rather than the declared namespace?

[Dr15Jones]

I was able to work around the problem by changing all mentions of TaggingVariableName in reco::TaggingVariableList to btau::TaggingVariableName.

I'll make a PR with that workaround.

[pcanal]

@pcanal what changed in ROOT 6.33/01 that caused TMethodArg to now give the type of the enum as the using version rather than the declared namespace?

I am not sure. I am looking into it.

[pcanal]

This change introduced by fa278745f2141ea02d40ed27af986ac8729dee2b. This makes TMethodArg::GetTypeName now returns the intended type (ie. the way it was "spelt"). To retrieve the underlying type, use TMethodArg::GetTypeNormalizedName.

Related, the fact that we have:

auto c2 = TEnum::GetEnum("reco::TaggingVariableName")

is an issue which is now recorded at root-project/root#15406