Hi everyone, The rewritten hierarchy now passes all the unit tests. You can inspect this branch in this repository: http://hg.enzotools.org/yt/ in the named branch hierarchy-opt . The Orion hierarchy will need to be converted (Jeff and I can talk about this offline) but overall I think the new mechanism for instantiating and creating hierarchies is now extremely straightforward, and will suit itself better to new AMR formats. You can see the outline here: http://hg.enzotools.org/yt/file/hierarchy-opt/yt/lagos/HierarchyType.py#l201 This is the base class, and other hierarchies just have to implement those functions to be real. The enzo hierarchy instantiation should be marginally faster and might use a bit less RAM. However, I still need to work on both reorganizing the DataQueue and the Grid objects, which will become smaller (eliminating some data members) and faster. I intend to eliminate at least one dictionary in the grid object. (Each dictionary removal drops 1K per object -- for the L7, this would be 300 megs per dict.) If you'd like to take a look, please do so, and let me know how it works out. You can do this with: hg clone http://hg.enzotools.org/yt/ ./experimental-yt cd experimental-yt hg up -C hierarchy-opt Best, -Matt
I have a coding question: If my code reads: from yt.mods import * pf = load("/Users/Jennifer/work/little_galcluster_highres_crs/RD0031/ RD0031") pc = PlotCollection(pf) def Press(field, data): densq= (data["Density"]*data["Density"]) return densq add_field("Press", function=Press, units=r"\rm{g}/\rm{cm}^{2}") pc.add_projection("Press",0) print pc.save("test1") It fails. But if there is "Pressure" in place of ever "press" it works. What is the reason for that to occur? Thanks, Jennifer P.S. yes I am aware that this is not actually creating pressure.
Hi Jennifer, You're underflowing the floating point precision -- (10^-27)^2 breaks 32-bit precision. Unfortunately, if you run with 32-bit precision, data fields obtained from the CPU files are not promoted to 64-bit precision. We might be able to hack something like this in if we cast the conversion factors to 64-bits. That's what's happening with the Pressure field, because Pressure is a derived field defined by yt, and so when you add it it's replacing the function but not the conversion factor. Cast the first data["Density"] to float64 with .astype("float64") and it should work. Be sure to delete your .yt files to ensure you're making new projections! :) Best of luck, and let us know if this doesn't work, Matt PS This is really better suited to the yt-users list. I think it would also be very helpful if we could keep the subject line and thread information relevant to the new question -- maybe it'd be better if you started a new thread for new questions and problems. On Tue, Sep 1, 2009 at 1:51 PM, Jennifer Jones<westbr39@msu.edu> wrote:
I have a coding question:
If my code reads: from yt.mods import *
pf = load("/Users/Jennifer/work/little_galcluster_highres_crs/RD0031/RD0031") pc = PlotCollection(pf)
def Press(field, data): densq= (data["Density"]*data["Density"]) return densq add_field("Press", function=Press, units=r"\rm{g}/\rm{cm}^{2}")
pc.add_projection("Press",0) print pc.save("test1")
It fails.
But if there is "Pressure" in place of ever "press" it works. What is the reason for that to occur?
Thanks, Jennifer
P.S. yes I am aware that this is not actually creating pressure. _______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
participants (2)
-
Jennifer Jones -
Matthew Turk