[yt-dev] text halo supplementary data

Sam Skillman samskillman at gmail.com
Tue Jul 10 09:33:23 PDT 2012


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.

i would think  LoadTextHaloes(pf, "file.txt", columns = {'x':0, 'y':1,
'z':2, 'r':3, 'm':4, 'dinosaur_age':5}) could be possible.  Maybe you would
want the value for each key to be (column, type) if you cared about
non-float types.

Sam

On Tue, Jul 10, 2012 at 10:28 AM, Matthew Turk <matthewturk at gmail.com>wrote:

> Hi Sam,
>
> I think Stephen's idea is a bit more general than that.  If you look
> in halo_objects.py, you can se that the number of properties of a halo
> object has 1) exploded 2) no standardization.  Having a dictionary of
> properties, which can vary in name, fits more with the yt philosophy.
> I like this idea.  We could expand it to "derived properties" as well,
> and maybe reduce te number of by-default calculated properties of a
> halo.
>
> 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?
>
> -Matt
>
> On Tue, Jul 10, 2012 at 9:25 AM, Sam Skillman <samskillman at gmail.com>
> wrote:
> > Hi,
> >
> > Could we just check if 'm' exists in the columns dict, and not have a
> supp
> > dict?
> >
> > Sam
> >
> >
> > On Tue, Jul 10, 2012 at 10:18 AM, Stephen Skory <s at skory.us> wrote:
> >>
> >> Hi all,
> >>
> >> I didn't read my email until this morning, when I saw the text halos
> >> thread had exploded. I had no idea how strongly people felt about
> >> halos!
> >>
> >> Here is a proposal for a solution that I think reduces confusion and
> >> also adds capability. Using Christine's request as an example, what I
> >> would do is add to the LoadTextHaloes a supplementary data column
> >> dict:
> >>
> >> pf = load("data")
> >> halos = LoadTextHaloes(pf, "file.txt", columns = {'x':0, 'y':1, 'z':2,
> >> 'r':3}, supp = {'m':4})
> >>
> >> And for each halo object there would be a supp dict hanging off of it:
> >>
> >> h0 = halos[0]
> >> h0.supp['m']
> >>
> >> This means that h0.total_mass() will correspond to the sphere, while
> >> the 'm' above to whatever's in the text file. This supp dict could be
> >> used to store temporary data for each halo object outside the
> >> LoadTextHaloes function, and if I hear that it might be useful, it
> >> could be included in a halo.dump() save.
> >>
> >> One issue is what happens to the supp columns? Do I float() them, or
> >> do I keep them strings, which allows users to convert them if needed?
> >> If I keep them strings, 'type' string columns would be useful. Or do I
> >> have yet another dict that specifies type in the call to
> >> LoadTextHaloes?
> >>
> >> --
> >> Stephen Skory
> >> s at skory.us
> >> http://stephenskory.com/
> >> 510.621.3687 (google voice)
> >> _______________________________________________
> >> yt-dev mailing list
> >> yt-dev at lists.spacepope.org
> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> >
> >
> >
> > _______________________________________________
> > yt-dev mailing list
> > yt-dev at lists.spacepope.org
> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> >
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20120710/d5e0b41a/attachment.htm>


More information about the yt-dev mailing list