[yt-dev] text halo supplementary data
Stephen Skory
s at skory.us
Tue Jul 10 10:01:05 PDT 2012
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)
More information about the yt-dev
mailing list