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

[j s oishi]

Sounds like the answer is "restart the kernel."

On Wed, Mar 20, 2013 at 1:02 PM, Matthew Turk <matthewturk at gmail.com> wrote:
> 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
> _______________________________________________
> yt-users mailing list
> yt-users at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org