search

yt-project / yt

Main yt repository
http://yt-project.org
Other
461 stars 276 forks source link

Handling cell_volume in 1D and 2D cartesian #797

Open yt-fido opened 10 years ago

yt-fido commented 10 years ago

Originally reported by: John ZuHone (Bitbucket: jzuhone, GitHub: jzuhone)

cell_volume is ill-defined for 1D and 2D cartesian data because it is still given in terms of length**3, even though the unused dimensions are meaningless. What we have done is set the domain_width to unity in these cases, but with the unit refactor I think this issue ought to be revisited.

That said, I'm not sure what to do about it.

yt-fido commented 10 years ago

Original comment by Nathan Goldbaum (Bitbucket: ngoldbaum, GitHub: ngoldbaum):

2D data works just like it always has: we treat it like 3D data but with a dummy z dimension with a width of 1.0 in code_length units.

yt-fido commented 10 years ago

Original comment by chummels (Bitbucket: chummels, GitHub: chummels):

So where does this leave us? Can one still get mostly-full yt functionality for 1D and 2D datasets, or will it break with the new unit-refactor? I seem to remember doing some analysis with unitrefactor on an enzo 2D dataset a few months back, which seemed OK. Are there specific things that will fail for <3D datasets?

yt-fido commented 10 years ago

Original comment by Matt Turk (Bitbucket: MatthewTurk, GitHub: MatthewTurk):

I think the bigger issue here is what to do about fcoords, fwidth, domain_left_edge, and domain_right_edge. I have spent some time looking at this with @samskillman and we recorded some of our thoughts on the Finite Element Trello board:https://trello.com/b/7KFLQ0iv/finite-element . As @ngoldbaum suggested, this is a more general problem.

The things we'll need to get rid of are the uses of .prod() on any fwidth attributes or on domain_left_edge. We can likely come up with a way to do this that preserves dimensionality correctly, and we may eventually need to ultimately make our datasets N-dimensionally indexed, with bounding boxes in N-dimensions. (That will be considerably harder and we will not address it directly, but instead just keep our thoughts on it as we modify fcoords and the like.)

I am not ready to do this in 3.0, but we absolutely need to at some point in the future. @samskillman and I have been talking about this for non-spatial datasets, too. I have a sneaking suspicion that when it comes down to it, the work will be primarily in getting unitrefactor to play nicely, rather than in modifying the underlying code.

yt-fido commented 10 years ago

Original comment by Nathan Goldbaum (Bitbucket: ngoldbaum, GitHub: ngoldbaum):

Using the new field plugin system, might it be possible to dynamically switch out cell_area for cell_volume if we detect a 2D simulation?

I don't think we've ever thought about treating reduced dimensionality data on the same footing as volumetric data. Something we should think about for yt 4.0, perhaps? This would go hand-in-hand with support for curvilinear coordinate systems and unstructured meshes.