Re: [yt-users] reloading pf does not reflect changes in the hierarchy

thanks, btw! On Wed, Mar 20, 2013 at 1:04 PM, j s oishi wrote:

Sounds like the answer is "restart the kernel."

On Wed, Mar 20, 2013 at 1:02 PM, Matthew Turk wrote:

...

On Wed, Mar 20, 2013 at 12:57 PM, j s oishi wrote:

...

Hi Matt,

I can't be sure, but it doesn't seem like deleting it works. For now, I'll just restart the kernel. Not a huge deal.

Well, if any other references to it exist, it will persist.

At load time, the only information that yt has about a parameter file is the filename passed in. However, because we need to be able to support identifying parameter files off of which pickled objects hang, we need to use that information to identify which parameter file it is. So at load time, ever parameter file is pushed into a WeakValueDictionary. As long as a reference to the object exists, that parameter file value in the key value dictionary will remain, and will be used *instead of* a new instance of the parameter file. Imagine a case where you have thousands of halo objects pickled, which you then de-pickle, in a very large hierarchy. If we weren't able to do this, unpickling would create a new parameter file (and hierarchy) instance for each one. This keeps us from that eventuality.

Note that IPython also retains references to items that have not been assigned to variables, in variables whose names escape me at the moment. So you may have an object in one of those that references it.

I would be open to alternate methods of identifying parameter files and keeping singletons on a per-pf basis, but I couldn't (and still can't) think of any...

...

j

On Wed, Mar 20, 2013 at 10:51 AM, Matthew Turk wrote:

...

Hi Jeff,

On Wed, Mar 20, 2013 at 10:39 AM, j s oishi wrote:

...

Hi all,

I'm not sure this is the proper use case, but I've noticed that if, using the iPython notebook you do

pf = load("DD0000/DD0000")

and then recreate DD0000 with a different hierarchy, when you rerun the load cell, the pf does not change its hierarchy. I don't know if this is an intentional behavior, or if I'm doing something wrong. Restarting the ipython notebook kernel fixes the problem. If the hierarchy stays the same but the data changes, this seems to work just fine. I'm trying to debug intial conditions, hence the repeated loading of a rapidly changing pf.

Is this something we could fix? Or is it by design? If we're moving increasingly toward iPython notebooks, I would imagine reloading a pf as a fairly common use case.

Delete it first, and I think it will work.

-Matt

...

j _______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

---

yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org