[yt-users] GADGET visualization

Nathan Goldbaum nathan12343 at gmail.com
Mon Feb 24 13:58:00 PST 2014


Hi Andrew,

Thanks for writing.  I'm responding since I've had some experience
working with yt's SPH frontends.  Matt and others might have more
information as well.

Support for Gadget data is still not finished.  In the yt-3.0 branch
of the development repository, you'll should be able to load the data
and do some basic visualization and analysis tasks.  The data is
available both in its raw form as particles and also by depositing the
particle data onto an octree and then visualization and analyzing the
octree. The first notebook you linked to describes the basic of
loading, visualizating, and analyzing SPH data.

If you want to work with a more stable codebase (although one that is
not being actively developed) you should be able to do many analysis
and viz tasks using the yt-3.0 branch of the main development
repository: https://bitbucket.org/yt_analysis/yt

The 3.0 branch was a big refactoring of the underlying data selection
algorithms yt uses to load data off disk.  This made it possible to
present the same user interface for visualizing datasets from particle
codes like Gadget, octree AMR codes like Ramses, and patch-based AMR
codes like Enzo.

Support for SPH smoothing is available in a separate repository.  In
this experimental development repository we've refactored the code to
use a symbolic units library to handle unit conversions and detect
code bugs using dimensional analysis.  We've also completely
refactored the way frontends are written and fields are set up and
detected.

If you want to dive in to the code, I'd suggest starting with the
experimental version of yt.  This may be a bit more rocky at first -
there might be bugs - but will be more rewarding in the end as this is
the direction the codebase is going.  The work is ongoing in the
yt-3.0 branch on Matt Turk's fork of yt:
https://bitbucket.org/MatthewTurk/yt

In both cases there is unfortunately not a lot of documentation at the
moment.  This is something that we're working on right now.  Mailing
list archives as well as the YTEP listing
(http://ytep.readthedocs.org/) might prove to be useful.

As for your questions about yt internals, I've written some basic
description below.  I would also encourage you to read the yt method
paper and to take a look YTEP-0001 and YTEP-0005, which describe the
new geometry system.

The basic data structure yt uses to represent an on-disk dataset is
the StaticOutput class.  The SPH frontend defines a GadgetStaticOutput
class as well as a GadgetHDF5StaticOutput subclass to represent HDF5
Gadget datasets.  You can create a new StaticOutput instance using the
'load' function or by directly instantiating an instance of a
StaticOutput subclass defined in one of the frontends.  You'll need to
look at the parameters of the __init__ method to figure out exactly
how to load the data. For Gadget, the 'load' convenience function only
works with HDF5 datasets, so if you are have data written in Gadget's
binary format, you'll need to load your data by calling
GadgetStaticOutput directly.

StaticOutput instances have as an attribute an instance of
GeometryHandler.  This class handles the indexing and selection of
data.  This is really the heart of yt's hard-core numerics, and is
written in a way that is very accessible at a high level.  If you want
to dive into the algorithms, I think it would help to look over the
GeometryHandler class as well as its subclass the
ParticleGeometryHandler.  That said, yt's interface is more or less
agnostic to the underlying algorithm used to index the data.

Do you have specific questions about how to load and visualize your datasets?

Hope that's helpful and not too much of a manifesto :)

-Nathan



More information about the yt-users mailing list