<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
Hi all,<br>
<br>
Sam Leitner and I have just started writing a new yt frontend for the distributed version of<br>
ART (a completely different file format, but very similar units and structure to the current<br>
ART frontend).  artio refers to an interface library we use to read/write from the new file formats,<br>
similar in principle to RamsesReader.<br>
<br>
We're targeting yt-3.0 in hopes of using the new Oct tree support written for Ramses, and <br>
hopefully can help develop and generalize that part of yt.  We'll be focusing on trying to get
<div>a very basic AMR support implemented and leave particle support for a later phase.</div>
<br>
The online documentation on frontends is out of date and lacking in some areas, so we'll <br>
probably be flooding the list with questions over the next few weeks.  I am not a current
<div>user of yt, so I'm also trying to catch up on general terminology and may ask some basic</div>
<div>or ill-posed questions.  Thanks for your patience.</div>
<div><br>
</div>
<div>We currently are able to read parameters from artio and set a few fields and units.  This </div>
<div>development has produced the following questions:</div>
<div>
<div><br>
- Is there a list of the properties of StaticOutput that are required?  Each front-end has a slightly<br>
different list and it's not clear which ones are in current use or required (except when the code<br>
throws an exception on load).  For now we're setting the following:<br>
<br>
dimensionality<br>
refine_by<br>
domain_dimensions<br>
domain_left_edge<br>
domain_right_edge<br>
min_level<br>
max_level<br>
current_time<br>
<br>
and in the case of cosmological simulations:<br>
cosmological_simulation<br>
omega_lambda<br>
omega_matter<br>
hubble_constant<br>
current_redshift<br>
<br>
and <br>
parameters["initial_redshift']<br>
parameters["HydroMethod"]
<div><br>
</div>
<div>what about units?  time_units?  </div>
<div><br>
</div>
<div><br>
- It looks like GeometryHandler has replaced AMRHierarchy as the preferred frontend interface?  Chombo <br>
now uses GridGeometryHandler rather than AMRHierarchy, for example.  How does that affect io.py, where </div>
<div>the online documentation (<a href="http://yt-project.org/doc/advanced/creating_frontend.html">http://yt-project.org/doc/advanced/creating_frontend.html</a>) describes Grid instances</div>
<div>being passed to methods in io.py.  What if we're using an OctreeGeometryHandler rather than a</div>
<div>GridGeometryHandler?</div>
<div><br>
</div>
<div><br>
</div>
<div>
<div>- What would be the best way to start developing a customized geometry handler?  Where are the major entry</div>
<div>points, and what functions are required vs optional?  Is it possible to begin by writing something coarse that doesn't</div>
<div>implement any performance features like chunking or parallelism?  </div>
<div><br>
</div>
<div><br>
</div>
<div>- We'd like to use the RAMSES and ART frontends as examples, since their data structures are very similar to our</div>
<div>own.  How current are those frontends in yt-3.0?  Are there any major pieces which are scheduled for deprecation</div>
<div>or refactoring that we should be aware of?  In RAMSES, for example, some field names are hard-coded in </div>
<div>RAMSESGeometryHandler._detect_fields.  Shouldn't this information be pulled from the fields interface?</div>
<div><br>
</div>
<div><br>
</div>
<div>Thanks for the help!</div>
<div><br>
</div>
<div>Douglas Rudd</div>
<div>Scientific Computing Consultant<br>
Research Computing Center, KICP<br>
University of Chicago<br>
<a href="mailto:drudd@uchicago.edu">drudd@uchicago.edu</a></div>
</div>
</div>
</div>
</body>
</html>