Hi all,
Okay, how about we check the loglevel inside the yt/logger.py module.
If it's set to less than debug, suppress them globally. Would that
work?
I have found these to be very unhelpful. You can't actually *do*
anything with them, in my experience, as instructing them to throw an
exception or fail simply suppresses them on most operating systems.
This would have the side effect of getting rid of the warnings when yt
tries to detect the radius field.
-Matt
On Mon, Aug 15, 2011 at 3:34 PM, j s oishi
Hi Stephen,
I tend to agree with Britton. I think a technically accurate but non-informative message should be suppressed at its source sooner rather than later. I would think exception handling in numpy should make this possible...for Dedalus, we use numpy to dump you into ipython if a certain kind of error occurs for deubgging purposes, so I imagine something simpler like quieting a particular message in a particular place should be possible...that having been said, I don't know how to do it.
j
On Mon, Aug 15, 2011 at 12:23 PM, Britton Smith
wrote: I think the issue is that these are messages coming straight out of numpy that are nearly impossible to supress. My personal opinion is that they are annoying at best and can ruin screen output that the user might be looking for. I feel that if we let these stick around, more of these will pop up. If at a later date someone wants to clean up the code so that the warnings go away, it will be much more difficult to locate them since the warning messages come completely without context. I say try to get rid of it if possible.
Britton
On Mon, Aug 15, 2011 at 3:18 PM, Casey W. Stark
wrote: At the risk of introducing complexity, we could do debug levels. If somebody wants these messages, they can set something, but they are supressed by default.
On Monday, August 15, 2011, Stephen Skory
wrote:Hi all,
this may not be a big issue because most people won't be using Geoffrey's new ellipsoidal halo information. However, it may spark discussion about this topic overall and set a useful precedent.
I have just finished vectorizing some of Geoffrey's code that is attached to the halo finder code. In so doing, I am allowing NaNs to come into the calculation because it keeps thing simple. Happily, the NaNs only exist where I know the answers can't be, and numpy.nanargmin/max() happily ignores the NaNs. But when I make the NaNs through a divide by zero (and some other stuff) I get warning messages telling me I just did what I knew was going to happen.
My question is, do we think that I should try to suppress these warnings? They are accurate, but the math that makes them is done intentionally, so they're not informative.
Can I get a +1/0/-1? Thanks!
-- Stephen Skory s@skory.us http://stephenskory.com/ 510.621.3687 (google voice) _______________________________________________ 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