[yt-dev] new ART front end (artio)

[Douglas Harvey Rudd]

Hi all,

Sam Leitner and I have just started writing a new yt frontend for the distributed version of
ART (a completely different file format, but very similar units and structure to the current
ART frontend).  artio refers to an interface library we use to read/write from the new file formats,
similar in principle to RamsesReader.

We're targeting yt-3.0 in hopes of using the new Oct tree support written for Ramses, and
hopefully can help develop and generalize that part of yt.  We'll be focusing on trying to get
a very basic AMR support implemented and leave particle support for a later phase.

The online documentation on frontends is out of date and lacking in some areas, so we'll
probably be flooding the list with questions over the next few weeks.  I am not a current
user of yt, so I'm also trying to catch up on general terminology and may ask some basic
or ill-posed questions.  Thanks for your patience.

We currently are able to read parameters from artio and set a few fields and units.  This
development has produced the following questions:

- Is there a list of the properties of StaticOutput that are required?  Each front-end has a slightly
different list and it's not clear which ones are in current use or required (except when the code
throws an exception on load).  For now we're setting the following:

dimensionality
refine_by
domain_dimensions
domain_left_edge
domain_right_edge
min_level
max_level
current_time

and in the case of cosmological simulations:
cosmological_simulation
omega_lambda
omega_matter
hubble_constant
current_redshift

and
parameters["initial_redshift']
parameters["HydroMethod"]

what about units?  time_units?


- It looks like GeometryHandler has replaced AMRHierarchy as the preferred frontend interface?  Chombo
now uses GridGeometryHandler rather than AMRHierarchy, for example.  How does that affect io.py, where
the online documentation (http://yt-project.org/doc/advanced/creating_frontend.html) describes Grid instances
being passed to methods in io.py.  What if we're using an OctreeGeometryHandler rather than a
GridGeometryHandler?


- What would be the best way to start developing a customized geometry handler?  Where are the major entry
points, and what functions are required vs optional?  Is it possible to begin by writing something coarse that doesn't
implement any performance features like chunking or parallelism?


- We'd like to use the RAMSES and ART frontends as examples, since their data structures are very similar to our
own.  How current are those frontends in yt-3.0?  Are there any major pieces which are scheduled for deprecation
or refactoring that we should be aware of?  In RAMSES, for example, some field names are hard-coded in
RAMSESGeometryHandler._detect_fields.  Shouldn't this information be pulled from the fields interface?


Thanks for the help!

Douglas Rudd
Scientific Computing Consultant
Research Computing Center, KICP
University of Chicago
drudd at uchicago.edu<mailto:drudd at uchicago.edu>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20121116/c77c11c4/attachment.htm>