[yt-dev] Some questions about TimeSeries

[Britton Smith]

Hi John,

The place to look is the eval function for TimeSeriesData.  On line 125 of
yt/data_objects/time_series.py, store.result is initialized to a list and
all return values are appended to that list on line 141.  This looks to me
to be handling tasks called with piter that have multiple return values.
If you add something like:
if len(store.result) == 1: store.result = store.result[0]
just outside of the "for task in tasks" loop, it produces the behavior that
we discussed.  However, now that I understand why this was done, I'm not so
sure it should be changed.  Having tasks dispatched with piter send back
their return values in a list is a desired feature I think, and so I think
that generality should be preserved.  Perhaps there is a solution that
could only affect getting parameters through params, but I think we should
let Matt chime in on this, since he is the most knowledgeable about this
area of the code.

Britton

On Wed, Jul 11, 2012 at 11:00 AM, John ZuHone <jzuhone at gmail.com> wrote:

> 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
>
>
>
> _______________________________________________
> 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/65e9e4b0/attachment.htm>