Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
EBSaver Tool in EventBuildingV2 tool set.
This is splitted from PR #307
Changes based on your comments:
· EBSaver has a lot of cout usage. Can we switch these for Log calls?
Most of them are for printing debug timestamps, I just add verbosity requirements for them. There are some couts left like line 337 just for step checks.
· The block of lines 163-214 seems to be printing out all removed events, is this needed? Maybe we can put this all in a debug verbosity check.
Added! Maybe not in a elegent way.
· line 215,242,267, - english please.
Translated, I will blame myself and chatGPT. (Learn some Chinese will be benifit tho. Just a joke)
· EBSaver finalise - seems like this is printing out some information about unbuilt event information, with MRD information specifically written to file. It seems like this could be useful information to track over time. Perhaps all that information (maybe also with the summary information on what was built too) could be put into a text summary for that event-builder output, and that could be stored as meta-information with the output file. It seems like this would be a nice way to track information about file contents and runs. We could read the contents of those meta-info files to track those metrics over time, or possibly later put them into SAM dataset meta info.
I will add this after merging current EBV2 tools to main repo. Maybe there can be better way to track rather than just txt print out. For now since we have all analysis variables saved to boost store and root file (built events), we can manually check them like in Steven's data quality report, but I agree save how many things are built and not built is useful.