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.
On Tue, Jul 10, 2012 at 8:23 PM, John ZuHone <email@example.com>
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.
yt-dev mailing list
yt-dev mailing list