Hi Britton and Stephen, I believe John Wise had written some star particle convenience routines. Also, the Enzo hierarchy object has the property num_stars, which accumulates the values of NumberOfStarParticles (which I think we should make an array, like particle_count.) For instance, in RD0005, num_stars is set to 351. More generally, I do agree that having convenience functions is a useful thing. I've made a few short forays, but none have ever really been successful. It's hard to get a simple API that covers a lot of ground, while avoiding being confusing to the user or to other developers. (The first empirical law of yt seems to be: function arguments will seek to expand until they fill an entire file ...) But, I agree: there is a *huge* amount of functionality that is, just now, very difficult to provide access to without boilerplate code. So what I think might be most helpful and productive is if we brainstorm a set of functionality that would be good to provide access to, and maybe a proposed way of providing that functionality. So ... what would this set of convenience functions look like? -Matt On Sat, Dec 11, 2010 at 7:28 AM, Britton Smith <brittonsmith@gmail.com> wrote:
Hi Stephen,
I agree that this information, specifically the current number of star particles, should be easy to get at. Maybe the solution should be on the enzo side instead of the yt side, as in maybe enzo should be carrying that around as a variable that can easily be made an attribute to the pf or put in the pf.parameters dict. I'm just wondering if that may just be easier. Just a thought.
Britton
On Fri, Dec 10, 2010 at 7:28 PM, Stephen Skory <stephenskory@yahoo.com> wrote:
Hi all,
after my conversation on -users with Matt, and the recent investigations of inline yt, a thought occurs to me. The whole point of the conversation was that I would like to do some inline analysis of a simulation with star(s). As a zero-order test, the analysis shouldn't run if there are no stars, so I wanted to find out how many stars there are. But as the conversation revealed, it isn't simple/blindingly obvious to do that kind of calculation in a way that works in serial, parallel, and inline, e.g. with derived quantities.
How do we feel about my writing a set of convenience functions that make these simple calculations easy? This shouldn't be comprehensive, just things that might come up often. Thoughts?
Stephen Skory stephenskory@yahoo.com 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