[yt-dev] Projection wipes grids

Matthew Turk matthewturk at gmail.com
Wed Jul 4 03:53:19 PDT 2012


Hi Elizabeth,

This is probably due to the projection scripts calling either
preload() for the data fields, or calling clear_data() on the grids.

Right now unless we can track down where those calls are made, and
come up with a way to temporarily disable them, I think your best bet
is avoiding projecting.  The longer term solution, which could be
useful for other applications as well, is a data sidecar file -- so
you could save a field generated in memory to disk.  I don't know when
I will be able to work on that, but perhaps someone else here will
have some ideas.

-Matt

On Wed, Jul 4, 2012 at 4:37 AM, Elizabeth Tasker
<tasker at astro1.sci.hokudai.ac.jp> wrote:
> Hi,
>
> I'm using a code which creates a new field by assigning values to
> individual cells.
>
> If --in the middle of the script-- I create a projected image, the new
> field gets wiped.
>
> This script demonstrates the problem:
>
> http://paste.yt-project.org/show/2517/
>
> Here, the code loops over two objects, and gives their neighbouring
> cells values in the new field and creates an extracted region from
> those cells.
>
> When the second object is called, the code reassigns its cells to
> object one and creates a new extracted region of object one's cells.
>
> If line 53 is not called (p = pc.add_projection("Density", 2)), this
> is fine. Both objects initially have 26 cells and then object one gets
> 52 cells.
>
> If the projection is created, the code forgets about the cells it
> assigned to object 1 in the first loop and object 1 ends up with only
> object 2's cells.
>
>
> This isn't a huge problem for me, since I can just ensure I never call
> a projection during my script.
>
> But.... I am liable to forget and clobber my data at a later point! Is
> it easy to somehow bank the new field so it's not destroyed during a
> projection? (If not, no worries.)
>
> (Matt, I know we previously discussed how projection didn't know about
> the new field. Possibly, this is a logical consequence from that and
> if so, I'm sorry to repeat the question!)
>
> Elizabeth
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org



More information about the yt-dev mailing list