Hi John,
Thanks for writing, and sorry for the delay in getting back to you.
I've identified the problem. What was going on was that back in
January, Sam put in something to lock the edges of grids to the edges
of the cell boundaries -- this is necessary for some situations where
roundoff causes problems. But, it also shouldn't be applied to data
where the dx doesn't vary, like ND < 3. In 2D data, for instance, we
set the dz to be equal to the domain width along that axis, which is
what you've noted with the 8kpc. So what I've done is changed which
dxs get updated.
So in the past, we did this:
1) dx = base_dx along all three dimensions , divided by refine_by ** level
2) lock edges to this dx
This makes sense for 3D data, where the refine_by *does* get applied
to all three dimensions. But for 2D data, we actually want it to look
like:
1) dx = base_dx along the *actual* dimensions, divided by refine_by ** level
2) lock edges to this dx
So when I changed it to this, I was able to get correct answers.
I've issued a pull request:
https://bitbucket.org/yt_analysis/yt/pull-request/269/fix-flash-grid-edges-f...
I've issued it as a pull request because hopefully at least you and
one other person can test it for your data to make sure there aren't
any additional subtleties I've missed. You can test this by issuing
this command:
cd $YT_DEST/src/yt-hg
hg pull -r 67b63e227903 https://bitbucket.org/MatthewTurk/yt/
hg up -r 67b63e227903
and then running like usual. If this doesn't work for you, let's
re-explore what's up, and we can take another shot at it. But I think
this should do it, since it keeps the dz constant for all grids, and
keeps their grid edges at the domain edges. What do you think?
-Matt
On Wed, Sep 5, 2012 at 8:20 PM, John Forbes
Hi all,
I'm running into some issues with 2D FLASH data, which seem to be related to the z positions of the data. Nathan has helped me track down the likely culprits, but I haven't come up with a reasonable workaround as of yet.
From what I can tell by inspecting the hdf5 file directly (here's a link to it: http://www.ucolick.org/~jforbes/cloud_hdf5_plt_cnt_0000 ), the z-coordinates are explicitly specified to be 0.0 for each of the root grids (there are 4 in this particular setup), and -1.0 for all other grids. I think the 'dz' field in yt is also somehow being read directly from the hdf5 file, and it is 1 cm for all cells.
The problem is that pf.domain_left_edge[2] and pf.domain_right_edge[2] are -8 kpc and 8 kpc respectively, so as-is, yt will give all the data a z-coordinate of -8 kpc, whereas I think it should probably be close to 0 in this particular setup. Even worse, the difference between the z-coordinates explicitly written in the hdf5 file between root and refined blocks means that most of the data will be at z = -8 kpc, but some will be at z=0 (i.e. when the root grid has the maximum-resolution data available at a particular location).
Any suggestions would be appreciated.
Thank you, John
Bonus information:
In the IRC channel I mentioned that replacing na.rint(self.grid_left_edge[i]/dx)*dx with na.rint(self.grid_left_edge[i]/(.99999999999*dx))*dx (and the corresponding change for the right edge) in frontends/flash/data_structures.py seemed to sidestep the problem, but in fact it created other problems. The effect was that all the z-data now appeared at -8 kpc, so I thought that would solve any issues stemming from the data having different z-values, but as it turns out that put all the z coordinates just outside grid_left_edge, so for instance calling pc.add_phase_object ran into trouble because it could find no valid data inside the domain.
I suspect that part of the problem lies with the for loop at line 146 in frontends/flash/data_structures.py as I claimed on yt-dev, but it seems the problems are a bit deeper. _______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org