Hi John,<br><br>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:<br>
if len(store.result) == 1: store.result = store.result[0]<br>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.<br>
<br>Britton<br><br><div class="gmail_quote">On Wed, Jul 11, 2012 at 11:00 AM, John ZuHone <span dir="ltr"><<a href="mailto:jzuhone@gmail.com" target="_blank">jzuhone@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div>Hi Britton,</div><div><div class="im"><br><blockquote type="cite">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.<br>
</blockquote><div><br></div></div>That's what I assumed the reason was, but I wanted to check. </div><div><div class="im"><br><blockquote type="cite">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.<br>
</blockquote><div><br></div></div><div>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. </div>
<div><br></div><div>Best,</div><div><br></div><div>John</div><div class="im"><div><br></div><blockquote type="cite">
<br>Britton<br><br><div class="gmail_quote">On Tue, Jul 10, 2012 at 8:23 PM, John ZuHone <span dir="ltr"><<a href="mailto:jzuhone@gmail.com" target="_blank">jzuhone@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all,<br>
<br>
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.<br>
<br>
1) If I run more than one task in a script, it has to load all of the pfs again. Is this by design?<br>
<br>
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:<br>
<br>
times = ts.params.current_time<br>
<br>
where times is a list of lists, each sublist with one member, with<br>
<br>
na.array(times).shape == (number of pfs, 1)<br>
<br>
The same sort of thing happens with returning, say, the angular momentum vector, which will have a shape of (number of pfs, 1, 3).<br>
<br>
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.<br>
<br>
Best,<br>
<br>
John Z<br>
_______________________________________________<br>
yt-dev mailing list<br>
<a href="mailto:yt-dev@lists.spacepope.org" target="_blank">yt-dev@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
</blockquote></div><br>
_______________________________________________<br>yt-dev mailing list<br><a href="mailto:yt-dev@lists.spacepope.org" target="_blank">yt-dev@lists.spacepope.org</a><br><a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
</blockquote></div></div><br></div><br>_______________________________________________<br>
yt-dev mailing list<br>
<a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
<br></blockquote></div><br>