Hi,
I have a function in pyrosetta that performs repack, and I call this function many times. Right now I get tracer output from core.pack.task:
e.g.
core.pack.task: Packer task: initialize from command line()
core.pack.pack_rotamers: built 143 rotamers at 8 positions.
Is there a way to mute this output ONLY while in my function? i.e. I'd like to mute this output and then turn it back on later in my script?
Category:
Post Situation:
Unfortunately, there isn't a clean way of doing this -- the tracer system is set up for the C++ level, which only really allows activation/deactivation of tracers at program startup.
This might actually work for you - you have a relatively flexible control of tracer output at startup, using the command line options. Just use the '-out:levels' option to control how "chatty" each tracer is. For example, if it's just those two tracers which are giving you grief, you can turn down how much they output by setting the level for just these tracers to 'warning': `-out:levels core.pack.task:warning core.pack.pack_rotamers:warning` (the levels are fatal/error/warning/info/debug/trace with the default being 'info'). -- This will change the output levels for these tracers for your entire PyRosetta run, not just for your function. Depending on what you're doing, this may be satisfactory.
There unfortunatly isn't a good way to adjust the levels of the tracers themselves after the program starts. There is a priority() method on the Tracer object which can adjust the priority of the tracer (using the corresponding basic.t_warning etc. values), but there's really no easy access to the tracer objects themselves - they're buried in the C++ level, and aren't exposed to the Python level. You might be able to fish the appropriate tracer out of the list returned by basic.TracerManager.get_instance().all_tracers(), but I'm not sure how well that would work, if at all.
Rocco - to clarify for my benefit - you are implying the tracer levels options are only read at runtime, not on each write to the tracer? I can see how that's more efficient...but I thought the Tracers were intialized only after option system readin, which is later than Tracer construction time...which implies they could change their verbosity on the fly.
I know there is code elsewhere in Rosetta that sets option values internally. It's illegal by the coding standards, but it's functional.
The tracer levels are typically set up during initialization (option-system read-in), not during the (loading-program-into-memory-time) Tracer construction. There is indeed a mechanism to change the priority of a tracer on the fly, that's the priority() method I referenced. (The TracerProxy objects actually make use of this.)
The big issue from a PyRosetta perspective is that there isn't a good way to actually get access to the normal (C++-level) Tracer objects. They're defined in *.cc files, not header files, so they aren't wrapped by PyRosetta. Even if they were, they'd be a large amount of namespace collision, as all the tracers in a given namespace all have the same variable name. This, more than when the priorities are initialized, is the issue with temporarily changing the Tracer priority during PyRosetta runs.
Thanks for the quick reply. Much appreciated.
Set the mute option during init.
init("-mute core.pack.pack_rotamers core.pack.task")
this will mute all of both tracers. I'm not at my computer ATM, so I can't completely check, but it should work. Search mute or traceron the Rosetta main documentation page(not the purosetta docs, but the main Rosetta wiki (check RosettaCommons.org)), and you should get more details. There are also option setters that you can use, and are found in the pyrosetta.org FAQ or docs, but as Rocco and Steven has said, they may not work.
Thanks Jared,
That will mute tracer output for all of my pyrosetta script, whereas I was looking for a method that will mute the output only inside a particular function (i.e. a way to turn it off and then back on again in different places in my pyrosetta script)