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
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
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
+1
On Tue, Dec 7, 2010 at 1:21 PM, j s oishi
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
+1
On Tue, Dec 7, 2010 at 11:29 AM, Britton Smith
+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
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
+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
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
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
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
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
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
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
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
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
Done, thanks for the input.
On Thu, Dec 9, 2010 at 6:10 PM, Matthew Turk
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
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
On Thu, Dec 9, 2010 at 2:58 PM, Matthew Turk
wrote: 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 < samskillman@gmail.com> 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
_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
participants (5)
-
Britton Smith
-
Cameron Hummels
-
j s oishi
-
Matthew Turk
-
Sam Skillman