ilcsoft / marlin Goto Github PK

tl; dr: EventModifiers are not drop-in replacements for Processors but a warning suggest otherwise.

Marlin has an AllowToModifyEvent parameter that allows processors to modify the event in their processEvent() method. Setting this to true emits the following message:

urging one to instead implement the processor as an EventModifier instead.

However, the EventModifiers and the Processors are collected into two different lists and executed one after the other. Therefore, the order that one defines Processors (not knowing that some of them are EventModifiers) in in the steering file is no longer the same as the order of execution. If one wants to create the inputs to the EventModifier and run it in the same steering file this is not possible and one needs to go back to a "regular" Processor and set AllowToModifyEvent...

Unfortunately, this strict separation is already fixed on the lowest layer by the LCReader implementation cf.:

  void SIOReader::processEvent( std::shared_ptr<EVENT::LCEvent> event ) {
    auto eventImpl = dynamic_cast<IOIMPL::LCEventIOImpl*>( event.get() ) ;
    std::set<IO::LCEventListener*>::iterator iter = _evtListeners.begin() ;
    while( iter != _evtListeners.end() ) {
      eventImpl->setAccessMode( EVENT::LCIO::UPDATE ) ;
      (*iter)->modifyEvent( eventImpl ) ;
      eventImpl->setAccessMode( EVENT::LCIO::READ_ONLY ) ; // set the proper acces mode
      (*iter)->processEvent( eventImpl ) ;
      iter++ ;
    }
  }

Therefore, I would suggest to document this behavior better and to modify the warning message.

Hello,

We have discovered that the driver responsible for converting a stdhep file to a collection of MCParticles within Marlin (StdHepReader.cc) is assigning a generator status of 1 (final state) to EVERY particle in the event.

When we analyze the file at the stdhep level (using the StdhepEvent class in the LCSim framework), we see proper generator status assignment. However, after we ran this file through the StdHepReader which converts it to collections of MCParticles, we discovered that each particles had a generator status of 1 (using the getGeneratorStatus() function.)

This flawed driver can be found here: /cvmfs/ilc.desy.de/sw/x86_64_gcc44_sl6/v01-17-09/Marlin/v01-08/source/src/StdHepReader.cc

I wanted to draw attention to this issue and point out that the LCStdHepReader found in the plcio workspace, works great and can be found here: https://stash.desy.de/projects/IL/repos/plcio/browse/source/utilities/LCStdHepReader.cc

Jane Shtalenkova
[email protected]

throw exception if a processor parameter of that name has been registered previously in:
Processor::registerParameter(name,....)

Is there already a processor that takes two or more collections and spits out a new collection containing the elements of all the others? For e.g. reconstructed particles?

Example steering files created by Marlin -x link to a XML schema definition file (ilcsoft.desy.de/marlin/marlin.xsd).
This schema definition does not define a <constant> element causing xml linters to complain. Maybe this should be changed?

Issue

Consider the following steering file:

<marlin>

<constants>
</constants>

<global>
    <parameter name="LCIOInputFiles">
    <!-- my_data1.slcio -->
         my_data2.slcio
    </parameter>
    <parameter name="MaxRecordNumber" value="0" />
    <parameter name="SupressCheck" value="false" />
    <parameter name="AllowToModifyEvent" value="false" />
</global>

<execute>
        <processor name="MyUsefulProcessor" />
</execute>


<processor name="MyUsefulProcessor" type="UsefulProcessor">
</processor>

</marlin>

I would expect the program to be processing only my_data2.slcio as the my_data1.slcio is commented.
However running Marlin on such an steering file will read my_data1.slcio instead of my_data2.slcio!

E.g. Marlin -c ./steer.xml will output:

. . .
Loading LCIO file [my_data1.slcio]
. . .

Tested with:

iLCSoft

source /cvmfs/ilc.desy.de/sw/x86_64_gcc82_centos7/v02-02-02/init_ilcsoft.sh

Hi all,

I am using the latest version of LDConfig (HEAD-2017-04-06). I just ran the example in the README file, that is,

Simulation:
ddsim --inputFiles ./bbudsc_3evt.stdhep --outputFile=./bbudsc_3evt.slcio --compactFile $lcgeo_DIR/ILD/compact/ILD_l1_v01/ILD_l1_v01.xml --steeringFile=./ddsim_steer.py

Creation of gear file
convertToGear default $lcgeo_DIR/ILD/compact/ILD_l1_v01/ILD_l1_v01.xml gear_ILD_l1_v01_dd4hep.xml

and reconstruction
Marlin bbudsc_3evt_stdreco_dd4hep.xml --global.GearXMLFile=gear_ILD_l1_v01_dd4hep.xml --InitDD4hep.DD4hepXMLFile=$lcgeo_DIR/ILD/compact/ILD_l1_v01/ILD_11_v01.xml

Everything runs well but the last one (reconstruction) which gives the following error,

Error in TCling::RegisterModule: cannot find dictionary module dict_rdict.pcm

A runtime error occured - (uncaught exception):
marlin::ParseException: XMLParser::parse error in file [bbudsc_3evt_stdreco_dd4hep.xml, row: 0, col: 0] : Failed to open file
Marlin will have to be terminated, sorry.

Does anyone knows if there is a problem with Marlin? Does something changed recently? For example, the way of giving the inputs?

Cheers,

Alejandro

• OS version: CentOS Linux 7
• Compiler version: GCC 8.2
• Package version: ILCSoft v02-02-02, CVMFS release
• Reproduced by: After that ANY Marlin processor is executed and at the end, just after reporting time used by processors, I receive "Segmentation fault"! It doesn't matter which Marlin Processor is in execute block of steering xml file. however, I tried with "IsolatedLeptonTaggingProcessor" and also separately with my own processor (both without LCIOOutputProcessor at the end):

........
[ MESSAGE "Marlin"] ---------------------------------------------------------
[ MESSAGE "Marlin"] Events skipped by processors :
[ MESSAGE "Marlin"] Total: 0
[ MESSAGE "Marlin"] ---------------------------------------------------------
[ MESSAGE "Marlin"]
[ MESSAGE "Marlin"] ---------------------------------------------------------
[ MESSAGE "Marlin"] Time used by processors ( in processEvent() ) :
[ MESSAGE "Marlin"]
[ MESSAGE "Marlin"] MyIsolatedLeptonTaggingProcess 8.300000e-01 s in 998 events ==> 8.316633e-04 [ s/evt.]
[ MESSAGE "Marlin"] Total: 8.300000e-01 s in 998 events ==> 8.316633e-04 [ s/evt.]
[ MESSAGE "Marlin"] ---------------------------------------------------------
Segmentation fault

• Goal: At the end this does not affect the output I expected, But seems there is a problem in Marlin/iLCSoft/...

This warning is pointless when using dd4hep

[ WARNING "Marlin"]
[ WARNING "Marlin"]  ========================================================
[ WARNING "Marlin"]    Detector name  not found in Gear file
[ WARNING "Marlin"]     - can't check consistency with lcio file
[ WARNING "Marlin"]  ========================================================
[ WARNING "Marlin"]