Hi Mike,
You're right, this is a bug. I've committed a fix in r1695.
Essentially, fields that can be generated just from existing ray data
(i.e., things like pressure, where you don't need to touch the actual
grids if you already have the constituent parts in the ray's .data
object) are automatically sorted, by definition; so, they don't need
to be resorted. However, the logic that was in place, meant to ensure
that only *new* fields read from disk were sorted, was not allowing
for something like dx -- which needs the grid object but is not found
on disk -- to be sorted. So this would apply to any field using the
validator ValidateGridType or ValidateSpatial -- which dx is!
Let me know if this doesn't work, and thanks very much for the bug report!
-Matt
On Fri, Apr 23, 2010 at 5:04 PM, Michael Kuhlen
It seems that ortho_ray produces a 'dx' field (also 'CellLength') that is not the same order as the other data fields. This is again for a 1D simulation, this time with a few levels of AMR on.
ray = pf.h.ortho_ray(0, [0.5, 0.5])
print ray['x'] yt INFO 2010-04-23 16:54:42,181 Getting field x from 6 [ 0.005 0.015 0.025 0.035 0.045 0.055 0.065 0.075 0.085 0.095 0.105 0.115 0.125 0.135 0.145 0.155 0.165 0.175 0.185 0.195 0.205 0.215 0.225 0.235 0.245 0.255 0.265 0.275 0.285 0.295 0.305 0.315 0.325 0.335 0.345 0.355 0.365 0.375 0.385 0.395 0.405 0.415 0.425 0.435 0.445 0.455 0.465 0.475 0.485 0.495 0.505 0.515 0.525 0.535 0.545 0.555 0.5625 0.5675 0.5725 0.5775 0.5825 0.5875 0.595 0.605 0.615 0.625 0.635 0.645 0.655 0.665 0.675 0.685 0.695 0.705 0.7125 0.7175 0.72125 0.72375 0.725625 0.726875 0.728125 0.7290625 0.7296875 0.7303125 0.7309375 0.7315625 0.7321875 0.7328125 0.7334375 0.7340625 0.7346875 0.7353125 0.7359375 0.736875 0.738125 0.739375 0.74125 0.74375 0.7475 0.7525 0.7575 0.765 0.775 0.785 0.795 0.805 0.815 0.825 0.835 0.845 0.855 0.865 0.875 0.885 0.895 0.905 0.915 0.925 0.935 0.945 0.955 0.965 0.975 0.985 0.995 ]
print ray['dx'] yt INFO 2010-04-23 16:54:42,232 Getting field dx from 6 [ 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.01 0.005 0.005 0.005 0.005 0.005 0.005 0.005 0.005 0.005 0.005 0.005 0.0025 0.0025 0.0025 0.0025 0.00125 0.00125 0.00125 0.00125 0.00125 0.00125 0.000625 0.000625 0.000625 0.000625 0.000625 0.000625 0.000625 0.000625 0.000625 0.000625 0.000625 0.000625]
Any ideas how to fix this bug? Or some other way to access the ray's 'dx' values in the correct order? I suppose I could simply calculate the dx's myself from the 'x' field...
Thanks,
Mike
-- ********************************************************************* * * * Dr. Michael Kuhlen Theoretical Astrophysics Center * * email: mqk@astro.berkeley.edu UC Berkeley * * cell phone: (831) 588-1468 601 Campbell Hall * * skype username: mikekuhlen Berkeley, CA 94720 * * * ********************************************************************* _______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org