Hi Brian, Kuo-Chuan, First: non-cartesian geometry (and more broadly, non-patch based cartesian AMR) is on the roadmap. Brian has given a pretty accurate summary of the current status of non-cartesian coordinates in yt. It isn't in there just yet, and I think that implementing it would be non-trivial; it can be done, however, and I would be happy to outline how to do it. Anybody who's interested in helping out with some potentially far-reaching and fun changes to yt should be encouraged to read more and participate in the discussion. Sam Skillman, Jeff Oishi and I have spoken about implementing this. It is doable, and we intend to do so, but we would be extremely appreciative of any help, in conceptualization, implementation or testing. As a bit more information, I've included a sketch of the current yt roadmap. Any comments or suggestions on this roadmap would be greatly appreciated; I'm speaking somewhat extemporaneously based on informal conversations with the other devs. The first and most difficult task will be reading the entirety of this email, which as I write this has ballooned to what Brian charmingly refers to as a "Mattifesto." = Roadmap = We intend to finish up the current projects that we have going on in yt for a 2.2 release (codename "Olive Tuba") to release at the end of June. This release will focus on a refactored field system that will scale better for complexity, support for Nyx/Castro, a new set of web tools such as the fully-featured Reason and a simpler Google Maps interface (both of these are largely done) and potentially a new parallelized quadtree projection system with improved scaling and IO. This release will also feature answer testing run on a regular basis. Following the 2.2 release, at some point in the fall (likely mid-October) branch into two separate lines of development. One of these will lead to a 2.3 release (codename "Brick Trombone"), which will be focused on a re-factoring and simplification of the plotting system. This should enable passing around plots, easier storage, and even non-Python exporting of underlying plot data. It will also likely include a few more widgets and improvements to the web GUI, and greater integration with external codes like Paraview. We hope to release 2.3 by the end of the calendar year. The other branch will be much more invasive set of changes. The current plan is that this will involve -- among other things -- paving the way and implementing non-cartesian coordinates, as well as strictly point-based selection of data. I believe this will avoid any API-incompatible changes. Despite that, I see this as being a 3.0 (codename "Lime Trumpet") as it should speed things up. It may involve inclusion of a new IO subsystem based on garbage collection ("Space Emperor" by Sam Geen) which should also enable greater inclusion of non-AMR codes. I don't see this being done by the end of the year, but I do see it as being usable by the end of the year. = Non-Cartesian = Back to the non-roadmap. The geometry of a "grid" is used in a couple ways, where it is implicitly assumed to be cartesian. This is a non-comprehensive list, but it's the big ones. 1) To identify which cells overlap while taking a line integral (via volume rendering and projections) 2) To traverse cells with a line, as in the volume renderer 3) To identify cells that intersect with a slice 4) To identify grids that intersect a data object (i.e., the first of two passes) 5) Visualization of 2D image data -- slices and projections. (If anyone has any other places I've forgotten, please chime in!) This is roughly the order of decreasing difficulty of implementation. #5 is essentially trivial; the current pixelization algorithm takes (px,py,pdx,pdy, value) and turns this into a 2D buffer; we could simply add in a cylindrical and spherical pixelization that accepts all the necessary coordinates and returns a pixel buffer. #4 is also easy -- first step would be to construct a cartesian bounding box for all the grids/cells in the AMR non-cartesian coordinates and utilize that. #3 is challenging but feasible. #2 is much more difficult, as is #1. The stages of implementation would be to remove all the geometric, cartesian operations from the data objects in data_containers.py (this is usually _is_fully_enclosed and _get_list_of_grids) and then move that into a geometry handler, much like ObjectFindingMixin, in object_finding_mixin.py. After this, we would add new fields that reflect the volume of a cell, the extent, and so on. This handler will be affiliated with the hierarchy and will handle the necessary selections. Many of these changes will also be applicable to moving to a more general handling of cell-based data, like RAMSES, and particle-based data like Gadget. = How Can You Help = We'd very much appreciate your help. If you're interested in getting started with this, we'd appreciate your help either conceptualizing this process or helping with implementation, you should hop on over to yt-dev and we can chat more in depth about this. As I mentioned I don't see myself working on this until October, but that doesn't mean it can't start much sooner than that. Anyway, thanks for making it to the end of the email. If there's anything else I can clear up or help with, let me know. Best, Matt On Tue, May 31, 2011 at 4:38 PM, Brian O'Shea <bwoshea@gmail.com> wrote:

Hi Kuo-Chuan,

YT does not currently support non-Cartesian coordinate geometries in any dimensionality.  If you feel like implementing cylindrical coordinates into the code, I am sure that you would be heralded as a hero, and many songs would be sung in your honor at the next yt users meeting.  I leave it to others to comment on the difficulty of this task - I suspect it's highly non-trivial.

Cheers, Brian

On Tue, May 31, 2011 at 5:01 PM, Pan, Kuo-Chuan <kpan2@illinois.edu> wrote:

...

Hi,

Does yt support FLASH data with 2D cylindrical coordinates? If yes, how to enable it? If not, is it easy to implement it? I couldn't find info about it in the website. Thank you very much.

Sincerely yours, Kuo-Chuan _______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org