[yt-dev] text halo supplementary data

[Stephen Skory]

Hi Sam & Matt,

> I guess I don't understand why we have two dictionaries.  I would think we
> could define a standard for the normal properties, then read in all others
> as desired by the user.

Yeah, you're probably right that we can have a bit more intelligence
and have only one dict.

>> If we start thinking of a future where we can load halos without
>> necessarily affiliating them with simulation data, this could be kind
>> of cool.  What do you think?

I think it's reasonable to redesign the halo object so that it doesn't
need to point to a dataset. If it's made available, that's great, and
if not, it will just not allow you to do certain operations. But there
would have to be some value-added aspect to this - how do we make yt
work on unaffiliated halo objects in a way that's more useful than a
simple python/perl/awk script on a bunch of text? One idea is to make
merger tree operations streamlined and simplified with halo objects.
For example, one can imagine a time series halo

time_halo['m'], time_halo['t']

where the first gives mass of the halo at each time given by the
second. This would involve some fairly invasive changes to halos and
the merger tree, and I haven't fully formed these ideas. Thoughts from
the crowd?

-- 
Stephen Skory
s at skory.us
http://stephenskory.com/
510.621.3687 (google voice)