Actually, on reflection, you are correct: it should be only done on
the root processor in any event. There are no state changes. If you
use the root-only decorator to only have the routine
print_key_parameters be run on root, that should be okay.
Sorry, I don't know what I was thinking, you're right this should only
be on root.
-Matt
On Thu, Dec 9, 2010 at 2:58 PM, Matthew Turk
I think we shouldn't do it in that manner; I think you should instead turn off logging on all but the root processor. You can do this in your script by importing ytcfg from yt.config and setting your warning level to 50 on all the non-root processors.
-Matt
On Thu, Dec 9, 2010 at 2:55 PM, Britton Smith
wrote: I'm playing around with inline analysis and just realized that the new print outs are done by every processor. This could get ugly when running on 1000 cores. Is anyone opposed to me making the print out happen only on the root proc?
Britton
On Tue, Dec 7, 2010 at 3:37 PM, j s oishi
wrote: Hi Cam,
I don't think this should affect speed: first off, the parameter file is usually only read once, and that is always a fast operation. Slowing it down with a few console writes shouldn't be a rate limiter. The print_stats() dives down the hierarchy, so for a dataset of any consequence speedwise, that will be the rate limiting step.
j
On Tue, Dec 7, 2010 at 12:32 PM, Cameron Hummels
wrote: A little late, but +1. As you note, I think we need to be careful we're not pushing *too* much information to the user (as then it all looks like noise), and also make sure these lookups don't slow down the process significantly. It would be a shame to lose the speed of yt for this additional behavior.
Cameron
On 12/7/10 3:06 PM, Matthew Turk wrote:
Hi all,
Okay, it's pretty unanimous. I'll make the changes and push 'em. Thanks!
-Matt
On Tue, Dec 7, 2010 at 12:04 PM, Sam Skillman
wrote: +1
On Tue, Dec 7, 2010 at 11:29 AM, Britton Smith
wrote: > +1 > > On Tue, Dec 7, 2010 at 1:21 PM, j s oishi wrote: >> These kinds of simulation parameters are good to print. I'm a solid >> >> +1 >> >> on both of these changes. I also love print_stats, and having more >> data there is a good thing. >> >> j >> >> On Tue, Dec 7, 2010 at 10:10 AM, Matthew Turk >> >> wrote: >>> Hi all, >>> >>> I would like to propose that we increase the verbosity of two >>> operations: >>> >>> 1) When a parameter file is parsed, I would like several pieces of >>> information output via the "INFO" level of the logging handler. >>> This >>> would be the current simulation time, the dimensions of the domain, >>> and any cosmological parameters. >>> 2) When print_stats is called in the hierarchy, I would like to >>> include all of the cosmological parameters. >>> >>> The reason I'm bringing this up rather than just changing it is >>> that >>> in the past yt has (rightly) been accused of being too verbose (in >>> fact, it was one of the first things Jeff said to me the first time >>> we >>> met to talk about yt!) and I don't want to increase that >>> unnecessarily. But, I feel strongly that as we move into more >>> codes >>> we need to be more upfront about what yt thinks of a given >>> simulation >>> output. I think that this will also help ensure that errors are >>> avoided. >>> >>> +1/-1? >>> >>> -Matt >>> _______________________________________________ >>> Yt-dev mailing list >>> Yt-dev@lists.spacepope.org >>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >>> >> _______________________________________________ >> Yt-dev mailing list >> Yt-dev@lists.spacepope.org >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > > _______________________________________________ > Yt-dev mailing list > Yt-dev@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > _______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org