Ensure ROOT is in batch mode #207
Conversation
k4FWCore/scripts/k4run
Outdated
| @@ -6,6 +6,7 @@ import argparse | |||
| import logging | |||
|
|
|||
| from k4FWCore.utils import load_file | |||
| from ROOT import gROOT | |||
There was a problem hiding this comment.
Ugh, this will make calling k4run slower, in particular the first time because of the ROOT imports:
{[email protected]} ~ % time python -c "from ROOT import gROOT"
python -c "from ROOT import gROOT" 0.59s user 0.36s system 8% cpu 11.352 total
{[email protected]} ~ % time python -c "from ROOT import gROOT"
python -c "from ROOT import gROOT" 0.54s user 0.30s system 65% cpu 1.300 total
There was a problem hiding this comment.
Can we move the import to after the dry_run check. Or alternatively, hide this behind a dedicated flag for k4run?
Alternatively, which algorithm is causing this, and can't that be fixed to not create a Canvas?
edit: Or set batch mode in the processor / algorithm directly? I don't think we should fix this at this level.
There was a problem hiding this comment.
Can we move the import to after the
dry_runcheck
yes
Alternatively, which algorithm is causing this, and can't that be fixed to not create a Canvas?
It is https://github.com/iLCSoft/CLICPerformance/blob/master/Tracking/src/TrackChecker.cc
but the creation of the canvas is intended :(
We could also turn on batch mode there but without explicitly searching I would think it will not be the only existing processors, just the only one we use regularly...
In the end I don't care were and how we fix this, but I still think having ROOT in batch mode is the most future proof solution. Who knows when they make something else suddenly produce graphics output :)
There was a problem hiding this comment.
OK. In that case I would hide it behind a flag for k4run (that disables batch mode).
There was a problem hiding this comment.
I added a flag that disables batch mode now but given the previous discussion isn't that the opposite of what you wanted? :D
There was a problem hiding this comment.
Ah yes, sorry. I actually wanted the flag the other way around. Opt-in to non-batch mode (too many negatives flying around here).
There was a problem hiding this comment.
But this is opt-in to non-batch mode?
There was a problem hiding this comment.
The other way around I am not interested in as we will always have to turn it on and then I can just keep it in CLDConfig 🤷 so then we can also just close this :)
There was a problem hiding this comment.
But this is opt-in to non-batch mode?
You are right. And I think this is what we want. With this flag, the default is to run in batch mode, but it gives users the possibility to turn it off and get outputs (if anything creates them).
One issue with this is that algorithms are in principle free to switch things again in their implementation, but I suppose there we simply have to tell people to not do that.
Zehvogel
force-pushed
the
root-batchmode
branch
2 times, most recently
from
3656a80
to
21f3adf
Compare
tmadlener
force-pushed
the
root-batchmode
branch
from
21f3adf
to
170b3f2
Compare
|
Should we merge this? Or did someone come up with a better solution in the meantime? |
|
I would like to have a second look, I remember seeing ROOT running some stuff for ipython when running k4run that I don't think it should run, also related to interactive versus batchmode. |
|
I think as long as no one else runs into this issue it is of very low priority as we just apply this "fix" in |
k4FWCore/scripts/k4run
Outdated
| @@ -155,6 +155,12 @@ def main(): | |||
| help="Print all the configurable components available in the framework and exit", | |||
| ) | |||
| parser.add_argument("--gdb", action="store_true", help="Attach gdb debugger") | |||
| parser.add_argument( | |||
| "--disableROOTBatchMode", | |||
There was a problem hiding this comment.
The rest of the options use dashes, maybe this could be changed to something like --enable-root-interactive? Or simply --root-interactive. I think the option in positive is easier to find in case someone wants to look at some plots.
jmcarcell
force-pushed
the
root-batchmode
branch
from
170b3f2
to
9f4827b
Compare
jmcarcell
force-pushed
the
root-batchmode
branch
from
f50d96e
to
a8d9a0b
Compare
|
I tested this and overall it doesn't change the runtime (as expected I guess). The only change is that loading ROOT happens earlier; now before running Gaudi while before this it would happen immediately after starting running in most cases because of podio or EDM4hep. |
BEGINRELEASENOTES
gROOT.SetBatch(True)ink4runENDRELEASENOTES
Basically an upstream of key4hep/CLDConfig#36 as there will probably also be some other processors that are affected.