[yt-dev] Some questions about TimeSeries

[John ZuHone]

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 at 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 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/20120711/9f13726e/attachment.htm>