[Yt-dev] Verbosity Increase

Matthew Turk matthewturk at gmail.com
Thu Dec 9 15:10:19 PST 2010


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 <matthewturk at gmail.com> wrote:
> 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 <brittonsmith at gmail.com> 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 <jsoishi at gmail.com> 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
>>> <chummels at astro.columbia.edu> 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 <samskillman at gmail.com>
>>> >> wrote:
>>> >>> +1
>>> >>>
>>> >>> On Tue, Dec 7, 2010 at 11:29 AM, Britton Smith
>>> >>> <brittonsmith at gmail.com>
>>> >>> wrote:
>>> >>>> +1
>>> >>>>
>>> >>>> On Tue, Dec 7, 2010 at 1:21 PM, j s oishi <jsoishi at gmail.com> 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
>>> >>>>> <matthewturk at gmail.com>
>>> >>>>> 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 at lists.spacepope.org
>>> >>>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>> >>>>>>
>>> >>>>> _______________________________________________
>>> >>>>> Yt-dev mailing list
>>> >>>>> Yt-dev at lists.spacepope.org
>>> >>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> Yt-dev mailing list
>>> >>>> Yt-dev at lists.spacepope.org
>>> >>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>> >>>>
>>> >>>
>>> >>> _______________________________________________
>>> >>> Yt-dev mailing list
>>> >>> Yt-dev at lists.spacepope.org
>>> >>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>> >>>
>>> >>>
>>> >> _______________________________________________
>>> >> Yt-dev mailing list
>>> >> Yt-dev at lists.spacepope.org
>>> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>> >>
>>> > _______________________________________________
>>> > Yt-dev mailing list
>>> > Yt-dev at lists.spacepope.org
>>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>> >
>>> _______________________________________________
>>> Yt-dev mailing list
>>> Yt-dev at lists.spacepope.org
>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>
>>
>> _______________________________________________
>> Yt-dev mailing list
>> Yt-dev at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>
>>
>



More information about the yt-dev mailing list