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

[Matthew Turk]

On Wed, Mar 20, 2013 at 12:57 PM, j s oishi <jsoishi at gmail.com> 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 <matthewturk at gmail.com> wrote:
>> Hi Jeff,
>>
>> On Wed, Mar 20, 2013 at 10:39 AM, j s oishi <jsoishi at gmail.com> 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 at lists.spacepope.org
>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>> _______________________________________________
>> yt-users mailing list
>> yt-users at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
> _______________________________________________
> yt-users mailing list
> yt-users at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org