filter and CRV summary log text

[rlcee]

One of my background projects is keeping the default text in log files to a minimum, so that new anomalies and errors are easier to spot. Are the below prints required? May I put the CRV print behind a verbose flag and suppress the others?

SUMMARY CrvCoincidence 0 / 5 events satisfied coincidence requirements SUMMARY CrvCoincidence Total dead time: 0 / 6750 = 0% using time window 400 ns ... 1750 ns %MSG-i Summary: DetectorStepFilter:DetStepFilter@EndJob 29-Oct-2021 15:26:41 CDT ModuleEndJob DetectorStepFilter_module: passed 5 / 10 events

%MSG %MSG-i Summary: FilterStatusG4:g4consistentFilter@EndJob 29-Oct-2021 15:26:41 CDT ModuleEndJob FilterStatusG4_module summary: 10 events with status 0

%MSG %MSG-i Summary: GenEventCountReader:genCountLogger@EndJob 29-Oct-2021 15:26:41 CDT ModuleEndJob GenEventCount total: 10 events in 1 SubRuns

[oksuzian]

Yes.

Best, Yuri.

On Oct 29, 2021, at 4:17 PM, Ray Culbertson @.***> wrote:

 One of my background projects is keeping the default text in log files to a minimum, so that new anomalies and errors are easier to spot. Are the below prints required? May I put the CRV print behind a verbose flag and suppress the others?

SUMMARY CrvCoincidence 0 / 5 events satisfied coincidence requirements SUMMARY CrvCoincidence Total dead time: 0 / 6750 = 0% using time window 400 ns ... 1750 ns %MSG-i Summary: @.*** 29-Oct-2021 15:26:41 CDT ModuleEndJob DetectorStepFilter_module: passed 5 / 10 events

%MSG %MSG-i Summary: @.*** 29-Oct-2021 15:26:41 CDT ModuleEndJob FilterStatusG4_module summary: 10 events with status 0

%MSG %MSG-i Summary: @.*** 29-Oct-2021 15:26:41 CDT ModuleEndJob GenEventCount total: 10 events in 1 SubRuns

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[rlcee]

and this

%MSG-i COSMIC: CrvStepsFromStepPointMCs:CrvSteps@BeginModule 29-Oct-2021 16:25:36 CDT run: 1 subRun: 0 event: 1 mu2e::CrvStepsFromStepPointMCs will use StepPointMCs from: mu2e::StepPointMCs_g4run_CRV_ceSimReco.

[oksuzian]

Yes, Ray. Thank you for looking into this.

On Oct 29, 2021, at 4:51 PM, Ray Culbertson @.***> wrote:

 and this

%MSG-i COSMIC: @.*** 29-Oct-2021 16:25:36 CDT run: 1 subRun: 0 event: 1 mu2e::CrvStepsFromStepPointMCs will use StepPointMCs from: mu2e::StepPointMCs_g4run_CRV_ceSimReco.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[rlcee]

and this from MT: WE WILL RUN 1 SCHEDULES

Current G4State is : GeomClosed Art Run Number is: 1202 Current Run is 1202 Begin processing the 1st record. run: 1202 subRun: 0 event: 1 at 30-Oct-2021 17:30:56 CDT Our RMmap has 1 members

at endRun: numExcludedEvents = 0 CALLING RunTermination() from MTRunManager EarlyPrescaleFilter passed 5 events out of 5 for a ratio of 1

[rlcee]

Mu2eProductMixer: Applying time offsets from InputTag: label = 'protonTimeOffset', instance = ''

[soleti]

Hi Ray, feel free to put the time offset message behind a verbose flag. Not sure about the MT ones, but I guess the same applies to them. Thanks

-- Stefano Roberto Soleti @.*** (510) 486-5196, Room 050-6026A Lawrence Berkeley National Laboratory Berkeley, CA 94720

On Oct 30, 2021, at 15:36, Ray Culbertson @.***> wrote:

Mu2eProductMixer: Applying time offsets from InputTag: label = 'protonTimeOffset', instance = ''

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or unsubscribe.

[rlcee]

Hi Ray, feel free to put the time offset message behind a verbose flag. Not sure about the MT ones, but I guess the same applies to them. Thanks … -- Stefano Roberto Soleti @. (510) 486-5196, Room 050-6026A Lawrence Berkeley National Laboratory Berkeley, CA 94720 On Oct 30, 2021, at 15:36, Ray Culbertson @.> wrote: Mu2eProductMixer: Applying time offsets from InputTag: label = 'protonTimeOffset', instance = '' — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or unsubscribe.

Thanks. Is there any reason to keep the filtering summary prints? I think they are the same numbers as in the TrigReport. In fact, I think I'd recommend removing these lines from the code entirely.

[rlcee]

Hearing no objections, I'll proceed with all of these changes.

[gaponenko]

Is there any reason to keep the filtering summary prints? I think they are the same numbers as in the TrigReport.

TrigReport shows per-trigger path statistics. A trigger path may include several filters, so the numbers are not always the same.

[rlcee]

Is there any reason to keep the filtering summary prints? I think they are the same numbers as in the TrigReport.

TrigReport shows per-trigger path statistics. A trigger path may include several filters, so the numbers are not always the same.

I think I can imagine the scenario you are referring to. The basic question of what to do remains

1. remove the print
2. leave it alone
3. leave it in, but suppress the message
4. go in the opposite direction, require that filters report an endjob count, and create a standard report format.

One of the principles I am going for is to reduce info MSG-i prints, because visually they have the same impact as MSG-e, when casually scanning a log file. I'd prefer error messages to jump out as visually anomalous, not common, so while I'd still do 3 myself, I'd prefer 4 to 2.

[gaponenko]

Hi Ray,

I am fine with both (3), which is easy to do, and (4), which will be a never-ending task. (At least the policing of it).

Andrei

On Wed, 3 Nov 2021, Ray Culbertson wrote:

Is there any reason to keep the filtering summary prints? I think they are the same numbers as in the TrigReport.

TrigReport shows per-trigger path statistics. A trigger path may include several filters, so the numbers are not always the same.

I think I can imagine the scenario you are referring to. The basic question of what to do remains

1. remove the print
2. leave it alone
3. leave it in, but suppress the message
4. go in the opposite direction, require that filters report an endjob count, and create a standard report format.

One of the principles I am going for is to reduce info MSG-i prints, because visually they have the same impact as MSG-e, when casually scanning a log file. I'd prefer error messages to jump out as visually anomalous, not common, so while I'd still do 3 myself, I'd prefer 4 to 2.

-- You are receiving this because you were assigned. Reply to this email directly or view it on GitHub: https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Mu2e_Offline_issues_640-23issuecomment-2D960189760&d=DwICaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=O47fc5vzDTR2V_gla4Ub0Q&m=uynYZiUnJu31byF0e7yeBSwoUv0MxbshnKO324P0l-eog_561zc99-IDJjZ--FSy&s=Nf4ViSG3TpN88V7Ez3L_yLUHN2DMXEdfywkvtdH3DYM&e=

[kutschke]

1. remove the print
2. leave it alone
3. leave it in, but suppress the message
4. go in the opposite direction, require that filters report an endjob count, and create a standard report format.

About "suppress the message" - do you mean just print it without the message facility decorations around it? If so, I believe that all of the message facility severity levels come in pairs, with and without decorations. You still get all of the other features, just no decorations.

[rlcee]

About "suppress the message" - do you mean just print it without the message facility decorations around it?

In that sentence, I meant "tell message logger to record the message but do not print it in the log file". Leaving it on w/o decoration is an interesting option, which meets my visual alert criteria, but I'm not hearing a demand to keep the print.

[dnbrow01]

I don't think any of these printouts were specifically in geometry code, but generally speaking I support suppressing unneeded output. Thanks for working on this.

Dave B

[rlcee]

Mostly all done by #656 #655 #651 #642

There are still these prints from geant, which I hope Krzysztof can work on.

1) <<< Geant4 Physics List simulation engine: ShieldingM <<< Reference Physics List ShieldingM_EMZ is built

2) hInelastic Shielding : threshold between BERT and FTFP is over the interval for pions : 9.5 to 9.9 GeV for kaons : 9.5 to 9.9 GeV for proton : 9.5 to 9.9 GeV for neutron : 9.5 to 9.9 GeV

3)

Birks coefficients used in run time

G4_POLYSTYRENE 0.07943 mm/MeV 0.00841958 g/cm^2/MeV massFactor= 101.16702711239 effCharge= 0.027027027027027

[rlcee]

@resnegfk here is the issue with the excessive geant print