[yt-dev] 2012 Community Survey Summary

Nathan Goldbaum goldbaum at ucolick.org
Wed May 23 00:00:18 PDT 2012


Hi all, just a few comments:

I think the main issue is that yt is at its heart an extension of the python language.  If a new user is not familiar with python initially then they will have a much more difficult time following the docs and learning how to control yt.  At the same time, the fact that yt is embedded in a high level programming language means that it is very powerful and easily extensible to someone familiar with python and willing to wade through the decently-sized codebase.

Elizabeth's point about Reason in the docs is worth thinking about.  I don't think Reason is quite there yet, but if we can point to the gui in the docs before we even mention a python tutorial, I think far fewer people will be scared off in the same way as the negative commenter.

For that to happen It should be much easier to write new analysis modules for reason.  If there were an API to add new functionality in the same way as we can add new derived quantities or time series analysis tasks in pure python, I think reason would get much more attention.

One option that may be worth thinking about is a gui plotting interface separate from reason.   I know we want the new plotting interface to expose the matplotlib backend more readily - something I am completely for - but I think matplotlib can be quite confusing for newcomers.  

I'd like it if I could make a plot with nice-looking tick marks, labels, and colorbar by manipulating a plotting window and without writing a line of matplotlib code or python code.  It would also be cool to set up a plot interactively and save a script that could reproduce that plot or press a button to interactively make the exact same plot with a different dataset.  This is all stuff that visit does and I think there are some lessons to be learned with how visit handles data, even if the plotting and scripting is sometimes pretty awful (sorry visit developers…).

One other thing that I've mentioned before that would make the docs much easier to use for a newcomer would be an improved search.  Right now, random API references tend to appear at the top of the search results while the narrative docs appear at the bottom which is very confusing.

Thanks for posting the results of the survey Matt.  I'm looking forward to working on this stuff this summer :)

Cheers,

Nathan

On May 22, 2012, at 9:20 PM, Elizabeth Tasker wrote:

> Hi everyone,
> 
> I have a couple of comments related to the negative comment on the yt survey. In particular, there is one part I agree with and one I do not:
> 
> The comment about yt being heavily cosmology based I do not agree with. As a non-cosmo simulator --one who still intends to torch a fellow developer's house for declaring all my research 'test problems' at a user meeting-- I use yt for all my simulation analysis and use a wide range of its capabilities. In fact, the only part I can think that I do not use is the halo finder, but I do use connected sets which is a similar idea for gas. 
> 
> I therefore feel this comment is not part of the general consensus and can be ignored. 
> 
> However, the comment about the documentation being from the user's rather than the programmer's, point of view is interesting and think worth some thought. For a while, I skirted around yt, aware that it was powerful but baulking at the effort needed to use it comfortably. Last summer, I had to write an entirely new analysis program for my simulations and I bit the bullet and starting working extensively with yt and python. I've never picked up an IDL script since, but there was definitely an energy bump. I also think that I do find the documentation **significantly** clearer now I approach it from a programmer's perspective. 
> 
> I have a couple of suggestions of what I think might help with this:
> 
> (1) The quickest option is to keep everything the same but add more actual examples. For instance, the routine call, e.g.
> 
> contour(self, field, ncont=5, factor=4, take_log=False, clim=None, plot_args=None):
> 
> is confusion for a non-programmer. When I first came to yt, I spent a while with thoughts like:
> 
> What is 'self'? Do I need to pass it like in C++ with Grid-> ? 
> 
> Although it's slightly painful, I think it would be much improved if there was an actual call example for each one of the callbacks and other tools. So we'd have:
> 
> contour(self, field, ncont=5, factor=4, take_log=False, clim=None, plot_args=None):
> (This is a proxy for ContourCallback.)
> pc.modify["contours"]("Density", ncont=1, take_log=False)
> Add contours in field to the plot. ncont governs the number of contours generated, factor governs the number of points used in the interpolation, take_log governs how it is contoured and clim gives the (upper, lower) limits for contouring.
> 
> 
> (2) My second suggestion involves the gui and concerns the way yt is presented. Currently, we talk about scripts and then mention there is a gui. How about we do it the other way around? So a new user's first port of call should be the gui. Then, we get to the section "beyond the gui" and talk about scripting and cookbook-ing and then finally onto full simulation analysis, i.e. writing whatever analysis package you like in python, but making use of the routines yt has.
> 
> For instance, in the workshop we just had at Hokudai, we could have stood up and brought up the yt gui before anything else. *Then* gone onto scripts.
> 
> The docs could be rearranged in a similar fashion.
> 
> I think this might provide a much faster way for new users to start getting into yt and make the gui of much more interest. Currently, people come to it after they learn to script at which point, its value is much less because it's inevitably more limited. 
> 
> 
> Elizabeth
> 
> PS today's google-doodle (or possible tomorrow's for the USA) is awesome.
> 
> 
> 
> 
> !DSPAM:10175,4fbc659f1748213191834!
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> 
> 
> !DSPAM:10175,4fbc659f1748213191834!




More information about the yt-dev mailing list