Hi Britton,

The first thing is by design.  The reason is that when you keep all the pfs open, you keep all their hierarchies around which ends up taking a lot of memory.  I was getting out of memory errors all the time before we made this change.

That's what I assumed the reason was, but I wanted to check. 

On the second thing, I think that behavior is probably not right, because each item in the list ends up being a list itself.  Even in the case where the parameter is multidimensional, what you get back is a list of list, where each of those list contains the array.  Unless there's a reason I'm not seeing, that should probably be changed to just a list of the actual items.

I've dived into the code on this a little bit, and it looks like it has something to do with the way piter is arranging things, since what gets appended onto store.result is an item that is not a list, but what comes out at the end is a list of lists. 

Best,

John


Britton

On Tue, Jul 10, 2012 at 8:23 PM, John ZuHone <jzuhone@gmail.com> wrote:
Hi all,

I've been playing around with some TimeSeries examples for the cookbook and I have noticed a couple of things that seem frankly annoying and I just wanted to ping the list and see if there was a reason for them.

1) If I run more than one task in a script, it has to load all of the pfs again. Is this by design?

2) Secondly, I have noticed that what gets returned in a parameter lookup or a quantities computation has one dimension more than desired. For example, getting the simulation time of each pf in the TimeSeries yields:

times = ts.params.current_time

where times is a list of lists, each sublist with one member, with

na.array(times).shape == (number of pfs, 1)

The same sort of thing happens with returning, say, the angular momentum vector, which will have a shape of (number of pfs, 1, 3).

It seems to me that what should be returned is a NumPy array with the dimensionality scaled down by one, e.g. the lists "in the middle" should be eliminated.

Best,

John Z
_______________________________________________
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