[yt-users] Support for cylindrical coordinates?

[Matthew Turk]

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 at 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 at 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 at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>
>
> _______________________________________________
> yt-users mailing list
> yt-users at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>
>