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
(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?
On Sat, Dec 11, 2010 at 7:28 AM, Britton Smith <brittonsmith(a)gmail.com> wrote:
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.
On Fri, Dec 10, 2010 at 7:28 PM, Stephen Skory <stephenskory(a)yahoo.com>
> 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
> 510.621.3687 (google voice)
> Yt-dev mailing list
Yt-dev mailing list