Reduce frequency of "XXX events processed" from Delphes

FCCSW
1

Dear all,

a very naive question: how to reduce the frequency of the
**XX events processed" in DelphesPythia_EDM4HEP?
I get this message for every event that has been processed (note it’s not from Pythia: the messages from Pythia are correctly print out only every 100 events according to my settings in the Pythia .cmd file)

Another question I have is whether this printout should be sent to stderr (as it seems to be the case now) or rather to stdout to avoid confusing real error messages (or at least warnings) with this innocuous message.

Thanks, Giovanni

2

Dear Giovanni,
The message

**XX events processed

actually comes from Delphes upon calling the progress bar Update function. The Delphes..._EDM4HEP executables do not seem to have a way to control this.

This said, the Update function does not carriage return after printing the number of events, overriding the line and obtaining a rolling counter. This means that the number of different lines you get on the screen is controlled by the Pythia::next() calls, which on the contrary do a carriage return. For example, if I set

Next:numberCount = 500              ! print message every n events

in the Pythia cmd file, I get this

 --------  End PYTHIA Event Listing  -----------------------------------------------------------------------------------------------
 PYTHIA Warning in Pythia::check: energy-momentum not quite conserved
** 499 events processed
 Pythia::next(): 500 events have been generated
** 999 events processed
 Pythia::next(): 1000 events have been generated
** 1499 events processed
 Pythia::next(): 1500 events have been generated
** 1999 events processed
 Pythia::next(): 2000 events have been generated
** 2499 events processed
 Pythia::next(): 2500 events have been generated
** 2999 events processed
 Pythia::next(): 3000 events have been generated
** 3499 events processed
 Pythia::next(): 3500 events have been generated
** 3999 events processed
 Pythia::next(): 4000 events have been generated
** 4499 events processed
 Pythia::next(): 4500 events have been generated
** 4999 events processed
 Pythia::next(): 5000 events have been generated
** 5499 events processed
 Pythia::next(): 5500 events have been generated
** 5999 events processed
 Pythia::next(): 6000 events have been generated
** 6499 events processed
 Pythia::next(): 6500 events have been generated
** 6999 events processed
 Pythia::next(): 7000 events have been generated
** 7499 events processed
 Pythia::next(): 7500 events have been generated
** 7999 events processed
 Pythia::next(): 8000 events have been generated
** 8499 events processed
 Pythia::next(): 8500 events have been generated
** 8999 events processed
 Pythia::next(): 9000 events have been generated
** 9499 events processed
 Pythia::next(): 9500 events have been generated
** 10000 events processed
** Exiting ...

I fully agree. Being on the Delphes side, we need to open an issue there.

G Ganis

3

Hi Gerry,

This said, the Update function does not carriage return after printing the number of events, overriding the line and obtaining a rolling counter.

that’s true for the interactive session (though I still find a waste of time to refresh the screen for every events processed), but in my jobs stdout and stderr are redirected to log files and the one for stderr is very big because it contains a string like:

1 events processed^M** 2 events processed^M** 3 events processed^M** 4 events processed^M (and so on..)

which makes then very difficult to parse the file for real errors.
The code that produces these messages is this one delphes/external/ExRootAnalysis/ExRootProgressBar.cc at 3cfe61d819de7a83aee1ea6a1e0c3b1e0a8e28e8 · delphes/delphes · GitHub?
Then indeed any action should be taken on Delphes’ side

Cheers,
Giovanni

4

Hi,

Right.
Yes we need to be able to control that, at least switch on/off, in the k4 dDelphes interface (call or not Update) and possibly in Delphes; and Delphes should also change to stdout instead of sdterr.

Yes

Thanks,
G