[yt-svn] commit/yt-doc: 2 new changesets
commits-noreply at bitbucket.org
commits-noreply at bitbucket.org
Sun Nov 3 17:16:49 PST 2013
2 new commits in yt-doc:
https://bitbucket.org/yt_analysis/yt-doc/commits/9868c22a4b59/
Changeset: 9868c22a4b59
User: MatthewTurk
Date: 2013-11-03 22:35:08
Summary: Moving all of welcome into a single overview file.
Affected #: 8 files
diff -r aa482e4881748677e642ab64369bc601b2ad442e -r 9868c22a4b59395723f2bae87a0ae8fbafce47a5 source/index.rst
--- a/source/index.rst
+++ b/source/index.rst
@@ -37,6 +37,16 @@
<tr valign="top"><td width="25%"><p>
+ <a href="overview.html">Overview</a>
+ </p>
+ </td>
+ <td width="75%">
+ <p class="linkdescr">What's yt all about?</p>
+ </td>
+ </tr>
+ <tr valign="top">
+ <td width="25%">
+ <p><a href="bootcamp/index.html">yt Bootcamp</a></p></td>
@@ -141,6 +151,7 @@
installing
yt Bootcamp <bootcamp/index>
+ overview
cookbook/index
visualizing/index
analyzing/index
diff -r aa482e4881748677e642ab64369bc601b2ad442e -r 9868c22a4b59395723f2bae87a0ae8fbafce47a5 source/overview.rst
--- /dev/null
+++ b/source/overview.rst
@@ -0,0 +1,278 @@
+A Little Bit About yt
+=====================
+
+.. sectionauthor:: J. S. Oishi <jsoishi at gmail.com>
+
+History
+-------
+
+yt was originally written by Matthew Turk in the course of his graduate
+studies. However, it is now a community-developed project with contributions
+from many people, the hospitality of several institutions, and benefiting from
+many different grants. With this community-driven approach and contributions
+from many external developers, it has evolved from a simple data-reader and
+exporter into what a fully-featured toolkit for analysis and visualization of
+adaptive mesh refinement data.
+
+yt was designed to be a completely Free (as in beer *and* as in freedom --
+"free and libre" as the saying goes) user-extensible framework for analyzing
+and visualizing astrophysical data, currently working with several different
+codes, including the "flagship" codes Enzo, Orion, Nyx and FLASH. It relies on
+no proprietary software -- although it can be and has been extended to
+interface with proprietary software and libraries -- and has been designed from
+the ground up to enable users to be as immersed in the data as they desire.
+
+yt is currently being developed by a team of developers. We used to include
+the entire list here, but it got too long, so now the best place to find it is
+to take a look at the current `CREDITS
+<http://hg.yt-project.org/yt/src/yt/CREDITS>`_ file. All development is
+conducted in the open, accessible at http://yt-project.org/ .
+
+
+What functionality does yt offer?
+---------------------------------
+
+yt has evolved substantially over the time of its development. Here is a
+**non-comprehensive** list of features:
+
+* Data Objects
+
+ * Arbitrary data objects (Spheres, cylinders, rectangular prisms, arbitrary index selection)
+ * Covering grids (smoothed and raw) for automatic ghost-zone generation
+ * Identification of topologically-connected sets in arbitrary fields
+ * Projections, orthogonal slices, oblique slices
+ * Axially-aligned rays
+ * Memory-conserving 1-, 2- and 3-D distribution functions of *arbitrary* fields and objects
+ * Halo-finding (HOP) algorithm with full particle information and sphere access
+ * Nearly **all** operations can be conducted in parallel
+
+* Data access
+
+ * Arbitrary field definition
+ * Derived quantities (average values, spin parameter, bulk velocity, etc)
+ * Custom C-written HDF5 backend for packed and unpacked AMR, NumPy-based HDF4 backend
+ * Flexible units system with CGS by default
+ * Per-user field and quantity plugins
+
+* Visualization
+
+ * Mathtext TeX-like text formatting
+ * Slices, projections, oblique slices
+ * Profiles and phase diagrams
+ * Linked zooms, colormaps, and saving across multiple plots
+ * Contours, vector plots, annotated boxes, grid boundary plot overlays.
+ * Parallel volume rendering with arbitrary emission and absorption
+ coefficients
+ * Off-axis projections and line integrals
+
+* Analysis Modules
+
+ * `Parallel Halo Finding <http://adsabs.harvard.edu/abs/2010ApJS..191...43S>`_
+ * Light cone generation
+ * Halo merger tree creation
+ * Level set extraction and clump identification
+ * Halo Mass Function
+ * SED generation
+ * Arbitrary global or sub-region two-point functions
+
+* Command-line tools
+
+ * Time-series movies
+ * HOP Halo Finding
+ * Quick slice and projection images
+ * Mapserver
+ * Bug reports
+ * IPython frontend
+
+* Access to components
+
+ * Monetary cost: **FREE**.
+ * Source code availability: **FULL**.
+ * Portability: **YES**.
+
+
+The Goals and Design of yt
+--------------------------
+
+There are many tools available for analysis and visualization of AMR
+data; there are many just for ``enzo``. So why ``yt``? Along the road
+to answering that question, we shall take a somewhat philosophical
+scenic route. For the more pragmatically minded, the answer is simple:
+what ``yt`` does not yet do, you can make it do so. This is not as
+glib as it may seem: it is in fact the main philosophical tennant that
+underlies ``yt``. In this section, it is not our goal to show you just
+how much ``yt`` already does. Instead, we will discuss how it is that
+``yt`` does anything at all. In doing so, we hope to give you a sense
+of whether or not ``yt`` will align with your science goals.
+
+At its core, ``yt`` is not a set of scripts to visualize AMR data, nor
+is it a set of low-level routines that return a homo- or even
+heterogeneous set of gridded data to your favorite scientific
+programming language--though ``yt`` incorporates both of these things,
+if your favorite scientific language is python. Instead, ``yt``
+provides a series of objects, some common AMR code structures (such as
+hierarchies and levels in a nested mesh) and some physical (a
+cylinder, cube, or sphere somewhere in the problem domain), that allow
+you to process AMR data in order to get at the fundamental underlying
+physics.
+
+
+``yt`` evolved naturally out of three design goals, though when Matt
+was busy writing it, he never really thought about them. Over
+time, it became clear that they are real and furthermore that they
+are important to understanding how to use ``yt``. These three goals
+are directed analysis, repeatability, and data exploration.
+
+Directed Analysis: Answering a Question
++++++++++++++++++++++++++++++++++++++++
+
+One of the main motivators for ``yt`` is to make it possible to sit
+down with a definite question about an AMR dataset and code up a
+script that will provide an answer to that question. Indeed much of its
+object-oriented nature can be viewed as a way perform operations on a
+data object. Given that AMR simulations are usually used to track some
+kind of structure formation, be it shocks, stars, or galaxies, the
+data object may not be the entire domain, but some region within it
+that is interesting. This data object in hand, ``yt`` makes it easy
+(if possible: some tasks ``yt`` can merely make *possible*) to
+manipulate that data in such a way to answer a question related to
+your research.
+
+Repeatability
++++++++++++++
+
+In any scientific analysis, being able to repeat the set of steps that
+prepared an answer or physical quantity is essential. To that end,
+much of the usage of ``yt`` is focused around running scripts,
+describing actions and plots programmatically. Being able to write a
+script or conducting a set of commands that will reproduce identical
+results is fundamentally important, and ``yt`` will attempt to make
+that easy. It's for this reason that the interactive features of
+``yt`` are not always as advanced as they might otherwise be. We are
+actively working on integrating the SAGE notebook system into ``yt``,
+which our preliminary tests suggest is a nice compromise between
+interactivity and repeatability.
+
+Exploration
++++++++++++
+
+However, it is the serendipitous nature of science that often finding
+the right question is not obvious at first. This is certainly true for
+astrophysical simulation, especially so for simulations of structure
+formation. What are we looking for, and how will we know when we find
+it?
+
+Quite often, the best way forward is to explore the simulation data as
+freely as possible. Without the ability for spot-examination,
+serendipitous discovery or general wandering, the code would be simply
+a pipeline, rather than a general tool. The flexible extensibility of
+``yt``, that is, the ability to create new derived quantities easily,
+as well as the ability to extract and display data regions in a
+variety of ways allows for this exploration.
+
+Object Methodology
+------------------
+
+``yt`` follows a strong object-oriented methodology. There is no real
+global state of ``yt``; all state is contained within objects that
+encapsulate an AMR code object or physical region.
+
+Physical Objects vs Code Objects
+++++++++++++++++++++++++++++++++
+
+The best way to think about doing things with ``yt`` is to think first
+of objects. The AMR code puts a number of objects on disk, and ``yt``
+has a matching set of objects to mimic these closely as possible. Your
+code runs (hopefully) a simulacrum of the physical universe, and thus
+in order to make sense of the output data, ``yt`` provides a set of
+objects meant to mimic the kinds of physical regions and processes you
+are interested in. For example, in a simulation of star formation out
+of some larger structure (the cosmic dark matter web, a turbulent
+molecular cloud), you might be interested in a sphere one parsec in
+radius around the point of maximum density. In a simulation of an
+accretion disk, you might want a cylindrical region of 1000 AU in
+radius and 10 AU in height with its axial vector aligned with the net
+angular momentum vector, which may be arbitrary with respect to the
+simulation cardinal axes. These are physical objects, and ``yt`` has a
+set of these too. Finally, you may wish to reduce the data to produce
+some essential data that represent a specific process. These
+reductions are also objects, and they are included in ``yt`` as well.
+
+Somewhat separate from this, but in the same spirit, are plots. In
+``yt``, plots are also objects that one can create, manipulate, and
+save. In the case of plots, however, you tell ``yt`` what you want to
+see, and it can fetch data from the appropriate source.
+
+In list form,
+
+ Code Objects
+ These are things that are on the disk that the AMR code knows about --
+ things like grids, data dumps, the grid hierarchy and so on.
+ Physical Objects
+ These are objects like spheres, rectangular prisms, slices, and
+ so on. These are collections of related data arranged by physical
+ properties, and they are not necessarily associated with a single
+ code object.
+ Reduced Objects
+ These are objects created by taking a set of data and reducing it
+ into a smaller format, suitable for a specific purpose.
+ Histograms, 1-D profiles, and averages are all members of this
+ category.
+ Plots
+ Plots are somewhat different than other objects, as they are
+ neither physical nor code. Instead, the plotting interface
+ accepts information about what you want to see, then goes and
+ fetches what is necessary--from code, physical, and reduced
+ objects as necessary.
+
+.. _intro_to_projections:
+
+Flexible Projections: an Example of Reusable Data Reduction
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+
+AMR data is best applied when the dynamic range in a quantity of
+interest (length or mass scales, typically) is large, but the volume
+filling factor of such interesting regions is small. In astronomy,
+virtually all available observations are projections on the sky, with
+little radial information about the observed structure. In order to
+compare with these observations, *projections* are an extremely useful
+data reduction for simulations. It is often useful to project to a
+given resolution, which may be as high as the highest subdomain in the
+AMR data set. However, projecting in a given direction through the
+full AMR data set can be quite costly in computing time. ``yt``'s
+project tool saves an *adaptive* projection when it completes this
+costly step, allowing you to make 2D images at whatever resolution you
+like with very modest computational resources. This idea, that of
+saving as much information as you need (and no more) to make the data
+reduction flexible for reuse is another core idea behind ``yt``. You
+should not have to spend computational resources and precious time to
+replot a projection from a 1000x1000 image to a 2000x2000 image. As a
+side note, in this specific case, because the 2D data product ``yt``
+produces is "smart", it never needs to use an array in memory as large
+as the full effective AMR resolution (which could be very large, and
+nearly devoid of unique information).
+
+
+Derived Fields and Derived Quantities
+-------------------------------------
+
+While the primary attraction of ``yt`` is the large set of basic code,
+physical, reduced, and plot objects already developed, at its core is the fact
+that any of the objects can be used as starting points for creating fields and
+quantities of your own devices. Derived quantities and derived fields are the
+physical objects ``yt`` creates from the "primitive" variables the simulation
+code stores. These may or may not be the so-called primitive variables of fluid
+dynamics (density, velocity, energy): they are whatever your simulation code
+writes to disk.
+
+Derived quantities are those data products derived from these variables such
+that the total amount of returned data is *less* than the number of cells.
+Derived fields, on the other hand, return a field with *equal* numbers of cells
+and the same geometry as the primitive variables from which it was derived. For
+example, ``yt`` could compute the gravitational potential at every point in
+space reconstructed from the density field.
+
+``yt`` already includes a large number of both derived fields and quantities,
+but its real power is that it is easy to create your own. See
+:ref:`creating-derived-fields` for detailed instructions on creating derived
+fields.
diff -r aa482e4881748677e642ab64369bc601b2ad442e -r 9868c22a4b59395723f2bae87a0ae8fbafce47a5 source/welcome/derived_fields.rst
--- a/source/welcome/derived_fields.rst
+++ /dev/null
@@ -1,23 +0,0 @@
-Derived Fields and Derived Quantities
--------------------------------------
-
-While the primary attraction of ``yt`` is the large set of basic code,
-physical, reduced, and plot objects already developed, at its core is the fact
-that any of the objects can be used as starting points for creating fields and
-quantities of your own devices. Derived quantities and derived fields are the
-physical objects ``yt`` creates from the "primitive" variables the simulation
-code stores. These may or may not be the so-called primitive variables of fluid
-dynamics (density, velocity, energy): they are whatever your simulation code
-writes to disk.
-
-Derived quantities are those data products derived from these variables such
-that the total amount of returned data is *less* than the number of cells.
-Derived fields, on the other hand, return a field with *equal* numbers of cells
-and the same geometry as the primitive variables from which it was derived. For
-example, ``yt`` could compute the gravitational potential at every point in
-space reconstructed from the density field.
-
-``yt`` already includes a large number of both derived fields and quantities,
-but its real power is that it is easy to create your own. See
-:ref:`creating-derived-fields` for detailed instructions on creating derived
-fields.
diff -r aa482e4881748677e642ab64369bc601b2ad442e -r 9868c22a4b59395723f2bae87a0ae8fbafce47a5 source/welcome/functionality.rst
--- a/source/welcome/functionality.rst
+++ /dev/null
@@ -1,60 +0,0 @@
-What functionality does yt offer?
----------------------------------
-
-yt has evolved substantially over the time of its development. Here is a
-**non-comprehensive** list of features:
-
-* Data Objects
-
- * Arbitrary data objects (Spheres, cylinders, rectangular prisms, arbitrary index selection)
- * Covering grids (smoothed and raw) for automatic ghost-zone generation
- * Identification of topologically-connected sets in arbitrary fields
- * Projections, orthogonal slices, oblique slices
- * Axially-aligned rays
- * Memory-conserving 1-, 2- and 3-D distribution functions of *arbitrary* fields and objects
- * Halo-finding (HOP) algorithm with full particle information and sphere access
- * Nearly **all** operations can be conducted in parallel
-
-* Data access
-
- * Arbitrary field definition
- * Derived quantities (average values, spin parameter, bulk velocity, etc)
- * Custom C-written HDF5 backend for packed and unpacked AMR, NumPy-based HDF4 backend
- * Flexible units system with CGS by default
- * Per-user field and quantity plugins
-
-* Visualization
-
- * Mathtext TeX-like text formatting
- * Slices, projections, oblique slices
- * Profiles and phase diagrams
- * Linked zooms, colormaps, and saving across multiple plots
- * Contours, vector plots, annotated boxes, grid boundary plot overlays.
- * Parallel volume rendering with arbitrary emission and absorption
- coefficients
- * Off-axis projections and line integrals
-
-* Analysis Modules
-
- * `Parallel Halo Finding <http://adsabs.harvard.edu/abs/2010ApJS..191...43S>`_
- * Light cone generation
- * Halo merger tree creation
- * Level set extraction and clump identification
- * Halo Mass Function
- * SED generation
- * Arbitrary global or sub-region two-point functions
-
-* Command-line tools
-
- * Time-series movies
- * HOP Halo Finding
- * Quick slice and projection images
- * Mapserver
- * Bug reports
- * IPython frontend
-
-* Access to components
-
- * Monetary cost: **FREE**.
- * Source code availability: **FULL**.
- * Portability: **YES**.
diff -r aa482e4881748677e642ab64369bc601b2ad442e -r 9868c22a4b59395723f2bae87a0ae8fbafce47a5 source/welcome/goals_and_design.rst
--- a/source/welcome/goals_and_design.rst
+++ /dev/null
@@ -1,80 +0,0 @@
-The Goals and Design of yt
---------------------------
-
-.. sectionauthor:: J. S. Oishi <jsoishi at astro.berkeley.edu>
-
-There are many tools available for analysis and visualization of AMR
-data; there are many just for ``enzo``. So why ``yt``? Along the road
-to answering that question, we shall take a somewhat philosophical
-scenic route. For the more pragmatically minded, the answer is simple:
-what ``yt`` does not yet do, you can make it do so. This is not as
-glib as it may seem: it is in fact the main philosophical tennant that
-underlies ``yt``. In this section, it is not our goal to show you just
-how much ``yt`` already does. Instead, we will discuss how it is that
-``yt`` does anything at all. In doing so, we hope to give you a sense
-of whether or not ``yt`` will align with your science goals.
-
-At its core, ``yt`` is not a set of scripts to visualize AMR data, nor
-is it a set of low-level routines that return a homo- or even
-heterogeneous set of gridded data to your favorite scientific
-programming language--though ``yt`` incorporates both of these things,
-if your favorite scientific language is python. Instead, ``yt``
-provides a series of objects, some common AMR code structures (such as
-hierarchies and levels in a nested mesh) and some physical (a
-cylinder, cube, or sphere somewhere in the problem domain), that allow
-you to process AMR data in order to get at the fundamental underlying
-physics.
-
-
-``yt`` evolved naturally out of three design goals, though when Matt
-was busy writing it, he never really thought about them. Over
-time, it became clear that they are real and furthermore that they
-are important to understanding how to use ``yt``. These three goals
-are directed analysis, repeatability, and data exploration.
-
-Directed Analysis: Answering a Question
-+++++++++++++++++++++++++++++++++++++++
-
-One of the main motivators for ``yt`` is to make it possible to sit
-down with a definite question about an AMR dataset and code up a
-script that will provide an answer to that question. Indeed much of its
-object-oriented nature can be viewed as a way perform operations on a
-data object. Given that AMR simulations are usually used to track some
-kind of structure formation, be it shocks, stars, or galaxies, the
-data object may not be the entire domain, but some region within it
-that is interesting. This data object in hand, ``yt`` makes it easy
-(if possible: some tasks ``yt`` can merely make *possible*) to
-manipulate that data in such a way to answer a question related to
-your research.
-
-Repeatability
-+++++++++++++
-
-In any scientific analysis, being able to repeat the set of steps that
-prepared an answer or physical quantity is essential. To that end,
-much of the usage of ``yt`` is focused around running scripts,
-describing actions and plots programmatically. Being able to write a
-script or conducting a set of commands that will reproduce identical
-results is fundamentally important, and ``yt`` will attempt to make
-that easy. It's for this reason that the interactive features of
-``yt`` are not always as advanced as they might otherwise be. We are
-actively working on integrating the SAGE notebook system into ``yt``,
-which our preliminary tests suggest is a nice compromise between
-interactivity and repeatability.
-
-Exploration
-+++++++++++
-
-However, it is the serendipitous nature of science that often finding
-the right question is not obvious at first. This is certainly true for
-astrophysical simulation, especially so for simulations of structure
-formation. What are we looking for, and how will we know when we find
-it?
-
-Quite often, the best way forward is to explore the simulation data as
-freely as possible. Without the ability for spot-examination,
-serendipitous discovery or general wandering, the code would be simply
-a pipeline, rather than a general tool. The flexible extensibility of
-``yt``, that is, the ability to create new derived quantities easily,
-as well as the ability to extract and display data regions in a
-variety of ways allows for this exploration.
diff -r aa482e4881748677e642ab64369bc601b2ad442e -r 9868c22a4b59395723f2bae87a0ae8fbafce47a5 source/welcome/history.rst
--- a/source/welcome/history.rst
+++ /dev/null
@@ -1,24 +0,0 @@
-History
--------
-
-yt was originally written by Matthew Turk in the course of his graduate
-studies. However, it is now a community-developed project with contributions
-from many people, the hospitality of several institutions, and benefiting from
-many different grants. With this community-driven approach and contributions
-from many external developers, it has evolved from a simple data-reader and
-exporter into what a fully-featured toolkit for analysis and visualization of
-adaptive mesh refinement data.
-
-yt was designed to be a completely Free (as in beer *and* as in freedom --
-"free and libre" as the saying goes) user-extensible framework for analyzing
-and visualizing astrophysical data, currently working with several different
-codes, including the "flagship" codes Enzo, Orion, Nyx and FLASH. It relies on
-no proprietary software -- although it can be and has been extended to
-interface with proprietary software and libraries -- and has been designed from
-the ground up to enable users to be as immersed in the data as they desire.
-
-yt is currently being developed by a team of developers. We used to include
-the entire list here, but it got too long, so now the best place to find it is
-to take a look at the current `CREDITS
-<http://hg.yt-project.org/yt/src/yt/CREDITS>`_ file. All development is
-conducted in the open, accessible at http://yt-project.org/ .
diff -r aa482e4881748677e642ab64369bc601b2ad442e -r 9868c22a4b59395723f2bae87a0ae8fbafce47a5 source/welcome/index.rst
--- a/source/welcome/index.rst
+++ /dev/null
@@ -1,16 +0,0 @@
-Welcome to yt
-=============
-
-While not necessary to get the guts of yt up and running, this section provides
-a primer on the functionality, motivation, and philosophy of yt, which will
-prove fruitful when trying to understand why and how to activate different
-features in yt later on.
-
-.. toctree::
- :maxdepth: 2
-
- history
- functionality
- goals_and_design
- objects
- derived_fields
diff -r aa482e4881748677e642ab64369bc601b2ad442e -r 9868c22a4b59395723f2bae87a0ae8fbafce47a5 source/welcome/objects.rst
--- a/source/welcome/objects.rst
+++ /dev/null
@@ -1,81 +0,0 @@
-Object Methodology
-------------------
-
-``yt`` follows a strong object-oriented methodology. There is no real
-global state of ``yt``; all state is contained within objects that
-encapsulate an AMR code object or physical region.
-
-Physical Objects vs Code Objects
-++++++++++++++++++++++++++++++++
-
-The best way to think about doing things with ``yt`` is to think first
-of objects. The AMR code puts a number of objects on disk, and ``yt``
-has a matching set of objects to mimic these closely as possible. Your
-code runs (hopefully) a simulacrum of the physical universe, and thus
-in order to make sense of the output data, ``yt`` provides a set of
-objects meant to mimic the kinds of physical regions and processes you
-are interested in. For example, in a simulation of star formation out
-of some larger structure (the cosmic dark matter web, a turbulent
-molecular cloud), you might be interested in a sphere one parsec in
-radius around the point of maximum density. In a simulation of an
-accretion disk, you might want a cylindrical region of 1000 AU in
-radius and 10 AU in height with its axial vector aligned with the net
-angular momentum vector, which may be arbitrary with respect to the
-simulation cardinal axes. These are physical objects, and ``yt`` has a
-set of these too. Finally, you may wish to reduce the data to produce
-some essential data that represent a specific process. These
-reductions are also objects, and they are included in ``yt`` as well.
-
-Somewhat separate from this, but in the same spirit, are plots. In
-``yt``, plots are also objects that one can create, manipulate, and
-save. In the case of plots, however, you tell ``yt`` what you want to
-see, and it can fetch data from the appropriate source.
-
-In list form,
-
- Code Objects
- These are things that are on the disk that the AMR code knows about --
- things like grids, data dumps, the grid hierarchy and so on.
- Physical Objects
- These are objects like spheres, rectangular prisms, slices, and
- so on. These are collections of related data arranged by physical
- properties, and they are not necessarily associated with a single
- code object.
- Reduced Objects
- These are objects created by taking a set of data and reducing it
- into a smaller format, suitable for a specific purpose.
- Histograms, 1-D profiles, and averages are all members of this
- category.
- Plots
- Plots are somewhat different than other objects, as they are
- neither physical nor code. Instead, the plotting interface
- accepts information about what you want to see, then goes and
- fetches what is necessary--from code, physical, and reduced
- objects as necessary.
-
-.. _intro_to_projections:
-
-Flexible Projections: an Example of Reusable Data Reduction
-+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-
-AMR data is best applied when the dynamic range in a quantity of
-interest (length or mass scales, typically) is large, but the volume
-filling factor of such interesting regions is small. In astronomy,
-virtually all available observations are projections on the sky, with
-little radial information about the observed structure. In order to
-compare with these observations, *projections* are an extremely useful
-data reduction for simulations. It is often useful to project to a
-given resolution, which may be as high as the highest subdomain in the
-AMR data set. However, projecting in a given direction through the
-full AMR data set can be quite costly in computing time. ``yt``'s
-project tool saves an *adaptive* projection when it completes this
-costly step, allowing you to make 2D images at whatever resolution you
-like with very modest computational resources. This idea, that of
-saving as much information as you need (and no more) to make the data
-reduction flexible for reuse is another core idea behind ``yt``. You
-should not have to spend computational resources and precious time to
-replot a projection from a 1000x1000 image to a 2000x2000 image. As a
-side note, in this specific case, because the 2D data product ``yt``
-produces is "smart", it never needs to use an array in memory as large
-as the full effective AMR resolution (which could be very large, and
-nearly devoid of unique information).
https://bitbucket.org/yt_analysis/yt-doc/commits/4c30777c6ada/
Changeset: 4c30777c6ada
User: ngoldbaum
Date: 2013-11-04 02:16:29
Summary: Cleaning up the front page, moving a couple of sections to reference/
Affected #: 8 files
diff -r 9868c22a4b59395723f2bae87a0ae8fbafce47a5 -r 4c30777c6ada6e32ae197a94ffb417478103b389 source/faq/index.rst
--- a/source/faq/index.rst
+++ /dev/null
@@ -1,280 +0,0 @@
-.. _faq:
-
-
-Frequently Asked Questions
-==========================
-
-A few problems that people encounter when installing or running ``yt``
-come up regularly. Here are the solutions to some of the most common
-problems.
-
-.. contents::
- :depth: 2
- :local:
- :backlinks: none
-
-.. _faq-scroll-up:
-
-I can't scroll-up to previous commands inside iyt
--------------------------------------------------
-
-If the up-arrow key does not recall the most recent commands, there is
-probably an issue with the readline library. To ensure the yt python
-environment can use readline, run the following command:
-
-.. code-block:: bash
-
- $ ~/yt/bin/pip install readline
-
-.. _faq-new-field:
-
-How do I modify whether or not ``yt`` takes the log of a particular field?
---------------------------------------------------------------------------
-
-``yt`` sets up defaults for many fields for whether or not a field is presented
-in log or linear space. To override this behavior, you can modify the
-``field_info`` dictionary. For example, if you prefer that ``Density`` not be
-logged, you could type:
-
-.. code-block:: python
-
- pf = load("my_data")
- pf.h
- pf.field_info['Density'].take_log = False
-
-From that point forward, data products such as slices, projections, etc., would
-be presented in linear space. Note that you have to instantiate pf.h before you
-can access pf.field info.
-
-.. _faq-handling-log-vs-linear-space:
-
-I added a new field to my simulation data, can ``yt`` see it?
--------------------------------------------------------------
-
-Yes! ``yt`` identifies all the fields in the simulation's output file
-and will add them to its ``field_list`` even if they aren't listed in
-:ref:`field-list`. These can then be accessed in the usual manner. For
-example, if you have created a field for the potential called
-``PotentialField``, you could type:
-
-.. code-block:: python
-
- pf = load("my_data")
- dd = pf.h.all_data()
- potential_field = dd["PotentialField"]
-
-The same applies to fields you might derive inside your ``yt`` script
-via :ref:`creating-derived-fields`. To check what fields are
-available, look at the properties ``field_list`` and ``derived_field_list``:
-
-.. code-block:: python
-
- print pf.h.field_list
- print pf.h.derived_field_list
-
-.. _faq-old-data:
-
-``yt`` seems to be plotting from old data
-------------------------------------------
-
-``yt`` does check the time stamp of the simulation so that if you
-overwrite your data outputs, the new set will be read in fresh by
-``yt``. However, if you have problems or the ``yt`` output seems to be
-in someway corrupted, try deleting the ``.yt`` and
-``.harray`` files from inside your data directory. If this proves to
-be a persistent problem add the line:
-
-.. code-block:: python
-
- from yt.config import ytcfg; ytcfg["yt","serialize"] = "False"
-
-to the very top of your ``yt`` script.
-
-.. _faq-mpi4py:
-
-``yt`` complains that it needs the mpi4py module
-------------------------------------------------
-
-For ``yt`` to be able to incorporate parallelism on any of its analysis,
-it needs to be able to use MPI libraries. This requires the ``mpi4py``
-module to be installed in your version of python. Unfortunately,
-installation of ``mpi4py`` is *just* tricky enough to elude the yt
-batch installer. So if you get an error in yt complaining about mpi4py like:
-
-.. code-block:: bash
-
- ImportError: No module named mpi4py
-
-then you should install ``mpi4py``. The easiest way to install it is through
-the pip interface. At the command line, type:
-
-.. code-block:: bash
-
- pip install mpi4py
-
-What this does is it finds your default installation of python (presumably
-in the yt source directory), and it installs the mpi4py module. If this
-action is successful, you should never have to worry about your aforementioned
-problems again. If, on the other hand, this installation fails (as it does on
-such machines as NICS Kraken, NASA Pleaides and more), then you will have to
-take matters into your own hands. Usually when it fails, it is due to pip
-being unable to find your MPI C/C++ compilers (look at the error message).
-If this is the case, you can specify them explicitly as per:
-
-.. code-block:: bash
-
- env MPICC=/path/to/MPICC pip install mpi4py
-
-So for example, on Kraken, I switch to the gnu C compilers (because yt
-doesn't work with the portland group C compilers), then I discover that
-cc is the mpi-enabled C compiler (and it is in my path), so I run:
-
-.. code-block:: bash
-
- module swap PrgEnv-pgi PrgEnv-gnu
- env MPICC=cc pip install mpi4py
-
-And voila! It installs! If this *still* fails for you, then you can
-build and install from source and specify the mpi-enabled c and c++
-compilers in the mpi.cfg file. See the `mpi4py installation page <http://mpi4py.scipy.org/docs/usrman/install.html>`_ for details.
-
-``yt`` fails saying that it cannot import yt modules
-----------------------------------------------------
-
-This is likely because you need to rebuild the source. You can do
-this automatically by running:
-
-.. code-block:: bash
-
- cd $YT_DEST/src/yt-hg
- python setup.py develop
-
-
-Unresolved Installation Problem on OSX 10.6
--------------------------------------------
-When installing on some instances of OSX 10.6, a few users have noted a failure
-when yt tries to build with OpenMP support:
-
- Symbol not found: _GOMP_barrier
- Referenced from: <YT_DEST>/src/yt-hg/yt/utilities/lib/grid_traversal.so
-
- Expected in: dynamic lookup
-
-To resolve this, please make a symbolic link:
-
-.. code-block:: bash
-
- $ ln -s /usr/local/lib/x86_64 <YT_DEST>/lib64
-
-where ``<YT_DEST>`` is replaced by the path to the root of the directory
-containing the yt install, which will usually be ``yt-<arch>``. After doing so,
-you should be able to cd to <YT_DEST>/src/yt-hg and run:
-
-.. code-block:: bash
-
- $ python setup.py install
-
-.. _plugin-file:
-
-What is the "Plugin File"?
---------------------------
-
-The plugin file is a means of modifying the available fields, quantities, data
-objects and so on without modifying the source code of yt. The plugin file
-will be executed if it is detected, and it must be:
-
-.. code-block:: bash
-
- $HOME/.yt/my_plugins.py
-
-The code in this file can thus add fields, add derived quantities, add
-datatypes, and on and on. It is executed at the bottom of ``yt.mods``, and so
-it is provided with the entire namespace available in the module ``yt.mods`` --
-which is the primary entry point to yt, and which contains most of the
-functionality of yt. For example, if I created a plugin file containing:
-
-.. code-block:: python
-
- def _myfunc(field, data):
- return np.random.random(data["Density"].shape)
- add_field("SomeQuantity", function=_myfunc)
-
-then all of my data objects would have access to the field "SomeQuantity"
-despite its lack of use.
-
-You can also define other convenience functions in your plugin file. For
-instance, you could define some variables or functions, and even import common
-modules:
-
-.. code-block:: python
-
- import os
-
- HOMEDIR="/home/username/"
- RUNDIR="/scratch/runs/"
-
- def load_run(fn):
- if not os.path.exists(RUNDIR + fn):
- return None
- return load(RUNDIR + fn)
-
-In this case, we've written ``load_run`` to look in a specific directory to see
-if it can find an output with the given name. So now we can write scripts that
-use this function:
-
-.. code-block:: python
-
- from yt.mods import *
-
- my_run = load_run("hotgasflow/DD0040/DD0040")
-
-And because we have imported from ``yt.mods`` we have access to the
-``load_run`` function defined in our plugin file.
-
-How do I cite yt?
------------------
-
-If you use yt in a publication, we'd very much appreciate a citation! You
-should feel free to cite the `ApJS paper
-<http://adsabs.harvard.edu/abs/2011ApJS..192....9T>`_ with the following BibTeX
-entry: ::
-
- @ARTICLE{2011ApJS..192....9T,
- author = {{Turk}, M.~J. and {Smith}, B.~D. and {Oishi}, J.~S. and {Skory}, S. and
- {Skillman}, S.~W. and {Abel}, T. and {Norman}, M.~L.},
- title = "{yt: A Multi-code Analysis Toolkit for Astrophysical Simulation Data}",
- journal = {\apjs},
- archivePrefix = "arXiv",
- eprint = {1011.3514},
- primaryClass = "astro-ph.IM",
- keywords = {cosmology: theory, methods: data analysis, methods: numerical },
- year = 2011,
- month = jan,
- volume = 192,
- pages = {9-+},
- doi = {10.1088/0067-0049/192/1/9},
- adsurl = {http://adsabs.harvard.edu/abs/2011ApJS..192....9T},
- adsnote = {Provided by the SAO/NASA Astrophysics Data System}
- }
-
-If you use the Parallel Halo Finder, we have a
-`separate paper <http://adsabs.harvard.edu/abs/2010ApJS..191...43S>`_ that describes
-its implementation: ::
-
- @ARTICLE{2010ApJS..191...43S,
- author = {{Skory}, S. and {Turk}, M.~J. and {Norman}, M.~L. and {Coil}, A.~L.
- },
- title = "{Parallel HOP: A Scalable Halo Finder for Massive Cosmological Data Sets}",
- journal = {\apjs},
- archivePrefix = "arXiv",
- eprint = {1001.3411},
- primaryClass = "astro-ph.CO",
- keywords = {galaxies: halos, methods: data analysis, methods: numerical },
- year = 2010,
- month = nov,
- volume = 191,
- pages = {43-57},
- doi = {10.1088/0067-0049/191/1/43},
- adsurl = {http://adsabs.harvard.edu/abs/2010ApJS..191...43S},
- adsnote = {Provided by the SAO/NASA Astrophysics Data System}
- }
diff -r 9868c22a4b59395723f2bae87a0ae8fbafce47a5 -r 4c30777c6ada6e32ae197a94ffb417478103b389 source/index.rst
--- a/source/index.rst
+++ b/source/index.rst
@@ -37,16 +37,6 @@
<tr valign="top"><td width="25%"><p>
- <a href="overview.html">Overview</a>
- </p>
- </td>
- <td width="75%">
- <p class="linkdescr">What's yt all about?</p>
- </td>
- </tr>
- <tr valign="top">
- <td width="25%">
- <p><a href="bootcamp/index.html">yt Bootcamp</a></p></td>
@@ -124,26 +114,6 @@
<p class="linkdescr">What to do if you run into problems</p></td></tr>
- <tr valign="top">
- <td width="25%">
- <p>
- <a href="faq/index.html">FAQ</a>
- </p>
- </td>
- <td width="75%">
- <p class="linkdescr">Frequently Asked Questions</p>
- </td>
- </tr>
- <tr valign="top">
- <td width="25%">
- <p>
- <a href="sharing_data/index.html">Sharing Data and Code</a>
- </p>
- </td>
- <td width="75%">
- <p class="linkdescr">Sharing Data on the yt Hub</p>
- </td>
- </tr></table>
.. toctree::
@@ -151,7 +121,6 @@
installing
yt Bootcamp <bootcamp/index>
- overview
cookbook/index
visualizing/index
analyzing/index
@@ -159,5 +128,3 @@
developing/index
reference/index
Getting Help <help/index>
- FAQ <faq/index>
- Sharing Data on the yt Hub <sharing_data/index>
diff -r 9868c22a4b59395723f2bae87a0ae8fbafce47a5 -r 4c30777c6ada6e32ae197a94ffb417478103b389 source/overview.rst
--- a/source/overview.rst
+++ /dev/null
@@ -1,278 +0,0 @@
-A Little Bit About yt
-=====================
-
-.. sectionauthor:: J. S. Oishi <jsoishi at gmail.com>
-
-History
--------
-
-yt was originally written by Matthew Turk in the course of his graduate
-studies. However, it is now a community-developed project with contributions
-from many people, the hospitality of several institutions, and benefiting from
-many different grants. With this community-driven approach and contributions
-from many external developers, it has evolved from a simple data-reader and
-exporter into what a fully-featured toolkit for analysis and visualization of
-adaptive mesh refinement data.
-
-yt was designed to be a completely Free (as in beer *and* as in freedom --
-"free and libre" as the saying goes) user-extensible framework for analyzing
-and visualizing astrophysical data, currently working with several different
-codes, including the "flagship" codes Enzo, Orion, Nyx and FLASH. It relies on
-no proprietary software -- although it can be and has been extended to
-interface with proprietary software and libraries -- and has been designed from
-the ground up to enable users to be as immersed in the data as they desire.
-
-yt is currently being developed by a team of developers. We used to include
-the entire list here, but it got too long, so now the best place to find it is
-to take a look at the current `CREDITS
-<http://hg.yt-project.org/yt/src/yt/CREDITS>`_ file. All development is
-conducted in the open, accessible at http://yt-project.org/ .
-
-
-What functionality does yt offer?
----------------------------------
-
-yt has evolved substantially over the time of its development. Here is a
-**non-comprehensive** list of features:
-
-* Data Objects
-
- * Arbitrary data objects (Spheres, cylinders, rectangular prisms, arbitrary index selection)
- * Covering grids (smoothed and raw) for automatic ghost-zone generation
- * Identification of topologically-connected sets in arbitrary fields
- * Projections, orthogonal slices, oblique slices
- * Axially-aligned rays
- * Memory-conserving 1-, 2- and 3-D distribution functions of *arbitrary* fields and objects
- * Halo-finding (HOP) algorithm with full particle information and sphere access
- * Nearly **all** operations can be conducted in parallel
-
-* Data access
-
- * Arbitrary field definition
- * Derived quantities (average values, spin parameter, bulk velocity, etc)
- * Custom C-written HDF5 backend for packed and unpacked AMR, NumPy-based HDF4 backend
- * Flexible units system with CGS by default
- * Per-user field and quantity plugins
-
-* Visualization
-
- * Mathtext TeX-like text formatting
- * Slices, projections, oblique slices
- * Profiles and phase diagrams
- * Linked zooms, colormaps, and saving across multiple plots
- * Contours, vector plots, annotated boxes, grid boundary plot overlays.
- * Parallel volume rendering with arbitrary emission and absorption
- coefficients
- * Off-axis projections and line integrals
-
-* Analysis Modules
-
- * `Parallel Halo Finding <http://adsabs.harvard.edu/abs/2010ApJS..191...43S>`_
- * Light cone generation
- * Halo merger tree creation
- * Level set extraction and clump identification
- * Halo Mass Function
- * SED generation
- * Arbitrary global or sub-region two-point functions
-
-* Command-line tools
-
- * Time-series movies
- * HOP Halo Finding
- * Quick slice and projection images
- * Mapserver
- * Bug reports
- * IPython frontend
-
-* Access to components
-
- * Monetary cost: **FREE**.
- * Source code availability: **FULL**.
- * Portability: **YES**.
-
-
-The Goals and Design of yt
---------------------------
-
-There are many tools available for analysis and visualization of AMR
-data; there are many just for ``enzo``. So why ``yt``? Along the road
-to answering that question, we shall take a somewhat philosophical
-scenic route. For the more pragmatically minded, the answer is simple:
-what ``yt`` does not yet do, you can make it do so. This is not as
-glib as it may seem: it is in fact the main philosophical tennant that
-underlies ``yt``. In this section, it is not our goal to show you just
-how much ``yt`` already does. Instead, we will discuss how it is that
-``yt`` does anything at all. In doing so, we hope to give you a sense
-of whether or not ``yt`` will align with your science goals.
-
-At its core, ``yt`` is not a set of scripts to visualize AMR data, nor
-is it a set of low-level routines that return a homo- or even
-heterogeneous set of gridded data to your favorite scientific
-programming language--though ``yt`` incorporates both of these things,
-if your favorite scientific language is python. Instead, ``yt``
-provides a series of objects, some common AMR code structures (such as
-hierarchies and levels in a nested mesh) and some physical (a
-cylinder, cube, or sphere somewhere in the problem domain), that allow
-you to process AMR data in order to get at the fundamental underlying
-physics.
-
-
-``yt`` evolved naturally out of three design goals, though when Matt
-was busy writing it, he never really thought about them. Over
-time, it became clear that they are real and furthermore that they
-are important to understanding how to use ``yt``. These three goals
-are directed analysis, repeatability, and data exploration.
-
-Directed Analysis: Answering a Question
-+++++++++++++++++++++++++++++++++++++++
-
-One of the main motivators for ``yt`` is to make it possible to sit
-down with a definite question about an AMR dataset and code up a
-script that will provide an answer to that question. Indeed much of its
-object-oriented nature can be viewed as a way perform operations on a
-data object. Given that AMR simulations are usually used to track some
-kind of structure formation, be it shocks, stars, or galaxies, the
-data object may not be the entire domain, but some region within it
-that is interesting. This data object in hand, ``yt`` makes it easy
-(if possible: some tasks ``yt`` can merely make *possible*) to
-manipulate that data in such a way to answer a question related to
-your research.
-
-Repeatability
-+++++++++++++
-
-In any scientific analysis, being able to repeat the set of steps that
-prepared an answer or physical quantity is essential. To that end,
-much of the usage of ``yt`` is focused around running scripts,
-describing actions and plots programmatically. Being able to write a
-script or conducting a set of commands that will reproduce identical
-results is fundamentally important, and ``yt`` will attempt to make
-that easy. It's for this reason that the interactive features of
-``yt`` are not always as advanced as they might otherwise be. We are
-actively working on integrating the SAGE notebook system into ``yt``,
-which our preliminary tests suggest is a nice compromise between
-interactivity and repeatability.
-
-Exploration
-+++++++++++
-
-However, it is the serendipitous nature of science that often finding
-the right question is not obvious at first. This is certainly true for
-astrophysical simulation, especially so for simulations of structure
-formation. What are we looking for, and how will we know when we find
-it?
-
-Quite often, the best way forward is to explore the simulation data as
-freely as possible. Without the ability for spot-examination,
-serendipitous discovery or general wandering, the code would be simply
-a pipeline, rather than a general tool. The flexible extensibility of
-``yt``, that is, the ability to create new derived quantities easily,
-as well as the ability to extract and display data regions in a
-variety of ways allows for this exploration.
-
-Object Methodology
-------------------
-
-``yt`` follows a strong object-oriented methodology. There is no real
-global state of ``yt``; all state is contained within objects that
-encapsulate an AMR code object or physical region.
-
-Physical Objects vs Code Objects
-++++++++++++++++++++++++++++++++
-
-The best way to think about doing things with ``yt`` is to think first
-of objects. The AMR code puts a number of objects on disk, and ``yt``
-has a matching set of objects to mimic these closely as possible. Your
-code runs (hopefully) a simulacrum of the physical universe, and thus
-in order to make sense of the output data, ``yt`` provides a set of
-objects meant to mimic the kinds of physical regions and processes you
-are interested in. For example, in a simulation of star formation out
-of some larger structure (the cosmic dark matter web, a turbulent
-molecular cloud), you might be interested in a sphere one parsec in
-radius around the point of maximum density. In a simulation of an
-accretion disk, you might want a cylindrical region of 1000 AU in
-radius and 10 AU in height with its axial vector aligned with the net
-angular momentum vector, which may be arbitrary with respect to the
-simulation cardinal axes. These are physical objects, and ``yt`` has a
-set of these too. Finally, you may wish to reduce the data to produce
-some essential data that represent a specific process. These
-reductions are also objects, and they are included in ``yt`` as well.
-
-Somewhat separate from this, but in the same spirit, are plots. In
-``yt``, plots are also objects that one can create, manipulate, and
-save. In the case of plots, however, you tell ``yt`` what you want to
-see, and it can fetch data from the appropriate source.
-
-In list form,
-
- Code Objects
- These are things that are on the disk that the AMR code knows about --
- things like grids, data dumps, the grid hierarchy and so on.
- Physical Objects
- These are objects like spheres, rectangular prisms, slices, and
- so on. These are collections of related data arranged by physical
- properties, and they are not necessarily associated with a single
- code object.
- Reduced Objects
- These are objects created by taking a set of data and reducing it
- into a smaller format, suitable for a specific purpose.
- Histograms, 1-D profiles, and averages are all members of this
- category.
- Plots
- Plots are somewhat different than other objects, as they are
- neither physical nor code. Instead, the plotting interface
- accepts information about what you want to see, then goes and
- fetches what is necessary--from code, physical, and reduced
- objects as necessary.
-
-.. _intro_to_projections:
-
-Flexible Projections: an Example of Reusable Data Reduction
-+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-
-AMR data is best applied when the dynamic range in a quantity of
-interest (length or mass scales, typically) is large, but the volume
-filling factor of such interesting regions is small. In astronomy,
-virtually all available observations are projections on the sky, with
-little radial information about the observed structure. In order to
-compare with these observations, *projections* are an extremely useful
-data reduction for simulations. It is often useful to project to a
-given resolution, which may be as high as the highest subdomain in the
-AMR data set. However, projecting in a given direction through the
-full AMR data set can be quite costly in computing time. ``yt``'s
-project tool saves an *adaptive* projection when it completes this
-costly step, allowing you to make 2D images at whatever resolution you
-like with very modest computational resources. This idea, that of
-saving as much information as you need (and no more) to make the data
-reduction flexible for reuse is another core idea behind ``yt``. You
-should not have to spend computational resources and precious time to
-replot a projection from a 1000x1000 image to a 2000x2000 image. As a
-side note, in this specific case, because the 2D data product ``yt``
-produces is "smart", it never needs to use an array in memory as large
-as the full effective AMR resolution (which could be very large, and
-nearly devoid of unique information).
-
-
-Derived Fields and Derived Quantities
--------------------------------------
-
-While the primary attraction of ``yt`` is the large set of basic code,
-physical, reduced, and plot objects already developed, at its core is the fact
-that any of the objects can be used as starting points for creating fields and
-quantities of your own devices. Derived quantities and derived fields are the
-physical objects ``yt`` creates from the "primitive" variables the simulation
-code stores. These may or may not be the so-called primitive variables of fluid
-dynamics (density, velocity, energy): they are whatever your simulation code
-writes to disk.
-
-Derived quantities are those data products derived from these variables such
-that the total amount of returned data is *less* than the number of cells.
-Derived fields, on the other hand, return a field with *equal* numbers of cells
-and the same geometry as the primitive variables from which it was derived. For
-example, ``yt`` could compute the gravitational potential at every point in
-space reconstructed from the density field.
-
-``yt`` already includes a large number of both derived fields and quantities,
-but its real power is that it is easy to create your own. See
-:ref:`creating-derived-fields` for detailed instructions on creating derived
-fields.
diff -r 9868c22a4b59395723f2bae87a0ae8fbafce47a5 -r 4c30777c6ada6e32ae197a94ffb417478103b389 source/reference/faq/index.rst
--- /dev/null
+++ b/source/reference/faq/index.rst
@@ -0,0 +1,280 @@
+.. _faq:
+
+
+Frequently Asked Questions
+==========================
+
+A few problems that people encounter when installing or running ``yt``
+come up regularly. Here are the solutions to some of the most common
+problems.
+
+.. contents::
+ :depth: 2
+ :local:
+ :backlinks: none
+
+.. _faq-scroll-up:
+
+I can't scroll-up to previous commands inside iyt
+-------------------------------------------------
+
+If the up-arrow key does not recall the most recent commands, there is
+probably an issue with the readline library. To ensure the yt python
+environment can use readline, run the following command:
+
+.. code-block:: bash
+
+ $ ~/yt/bin/pip install readline
+
+.. _faq-new-field:
+
+How do I modify whether or not ``yt`` takes the log of a particular field?
+--------------------------------------------------------------------------
+
+``yt`` sets up defaults for many fields for whether or not a field is presented
+in log or linear space. To override this behavior, you can modify the
+``field_info`` dictionary. For example, if you prefer that ``Density`` not be
+logged, you could type:
+
+.. code-block:: python
+
+ pf = load("my_data")
+ pf.h
+ pf.field_info['Density'].take_log = False
+
+From that point forward, data products such as slices, projections, etc., would
+be presented in linear space. Note that you have to instantiate pf.h before you
+can access pf.field info.
+
+.. _faq-handling-log-vs-linear-space:
+
+I added a new field to my simulation data, can ``yt`` see it?
+-------------------------------------------------------------
+
+Yes! ``yt`` identifies all the fields in the simulation's output file
+and will add them to its ``field_list`` even if they aren't listed in
+:ref:`field-list`. These can then be accessed in the usual manner. For
+example, if you have created a field for the potential called
+``PotentialField``, you could type:
+
+.. code-block:: python
+
+ pf = load("my_data")
+ dd = pf.h.all_data()
+ potential_field = dd["PotentialField"]
+
+The same applies to fields you might derive inside your ``yt`` script
+via :ref:`creating-derived-fields`. To check what fields are
+available, look at the properties ``field_list`` and ``derived_field_list``:
+
+.. code-block:: python
+
+ print pf.h.field_list
+ print pf.h.derived_field_list
+
+.. _faq-old-data:
+
+``yt`` seems to be plotting from old data
+------------------------------------------
+
+``yt`` does check the time stamp of the simulation so that if you
+overwrite your data outputs, the new set will be read in fresh by
+``yt``. However, if you have problems or the ``yt`` output seems to be
+in someway corrupted, try deleting the ``.yt`` and
+``.harray`` files from inside your data directory. If this proves to
+be a persistent problem add the line:
+
+.. code-block:: python
+
+ from yt.config import ytcfg; ytcfg["yt","serialize"] = "False"
+
+to the very top of your ``yt`` script.
+
+.. _faq-mpi4py:
+
+``yt`` complains that it needs the mpi4py module
+------------------------------------------------
+
+For ``yt`` to be able to incorporate parallelism on any of its analysis,
+it needs to be able to use MPI libraries. This requires the ``mpi4py``
+module to be installed in your version of python. Unfortunately,
+installation of ``mpi4py`` is *just* tricky enough to elude the yt
+batch installer. So if you get an error in yt complaining about mpi4py like:
+
+.. code-block:: bash
+
+ ImportError: No module named mpi4py
+
+then you should install ``mpi4py``. The easiest way to install it is through
+the pip interface. At the command line, type:
+
+.. code-block:: bash
+
+ pip install mpi4py
+
+What this does is it finds your default installation of python (presumably
+in the yt source directory), and it installs the mpi4py module. If this
+action is successful, you should never have to worry about your aforementioned
+problems again. If, on the other hand, this installation fails (as it does on
+such machines as NICS Kraken, NASA Pleaides and more), then you will have to
+take matters into your own hands. Usually when it fails, it is due to pip
+being unable to find your MPI C/C++ compilers (look at the error message).
+If this is the case, you can specify them explicitly as per:
+
+.. code-block:: bash
+
+ env MPICC=/path/to/MPICC pip install mpi4py
+
+So for example, on Kraken, I switch to the gnu C compilers (because yt
+doesn't work with the portland group C compilers), then I discover that
+cc is the mpi-enabled C compiler (and it is in my path), so I run:
+
+.. code-block:: bash
+
+ module swap PrgEnv-pgi PrgEnv-gnu
+ env MPICC=cc pip install mpi4py
+
+And voila! It installs! If this *still* fails for you, then you can
+build and install from source and specify the mpi-enabled c and c++
+compilers in the mpi.cfg file. See the `mpi4py installation page <http://mpi4py.scipy.org/docs/usrman/install.html>`_ for details.
+
+``yt`` fails saying that it cannot import yt modules
+----------------------------------------------------
+
+This is likely because you need to rebuild the source. You can do
+this automatically by running:
+
+.. code-block:: bash
+
+ cd $YT_DEST/src/yt-hg
+ python setup.py develop
+
+
+Unresolved Installation Problem on OSX 10.6
+-------------------------------------------
+When installing on some instances of OSX 10.6, a few users have noted a failure
+when yt tries to build with OpenMP support:
+
+ Symbol not found: _GOMP_barrier
+ Referenced from: <YT_DEST>/src/yt-hg/yt/utilities/lib/grid_traversal.so
+
+ Expected in: dynamic lookup
+
+To resolve this, please make a symbolic link:
+
+.. code-block:: bash
+
+ $ ln -s /usr/local/lib/x86_64 <YT_DEST>/lib64
+
+where ``<YT_DEST>`` is replaced by the path to the root of the directory
+containing the yt install, which will usually be ``yt-<arch>``. After doing so,
+you should be able to cd to <YT_DEST>/src/yt-hg and run:
+
+.. code-block:: bash
+
+ $ python setup.py install
+
+.. _plugin-file:
+
+What is the "Plugin File"?
+--------------------------
+
+The plugin file is a means of modifying the available fields, quantities, data
+objects and so on without modifying the source code of yt. The plugin file
+will be executed if it is detected, and it must be:
+
+.. code-block:: bash
+
+ $HOME/.yt/my_plugins.py
+
+The code in this file can thus add fields, add derived quantities, add
+datatypes, and on and on. It is executed at the bottom of ``yt.mods``, and so
+it is provided with the entire namespace available in the module ``yt.mods`` --
+which is the primary entry point to yt, and which contains most of the
+functionality of yt. For example, if I created a plugin file containing:
+
+.. code-block:: python
+
+ def _myfunc(field, data):
+ return np.random.random(data["Density"].shape)
+ add_field("SomeQuantity", function=_myfunc)
+
+then all of my data objects would have access to the field "SomeQuantity"
+despite its lack of use.
+
+You can also define other convenience functions in your plugin file. For
+instance, you could define some variables or functions, and even import common
+modules:
+
+.. code-block:: python
+
+ import os
+
+ HOMEDIR="/home/username/"
+ RUNDIR="/scratch/runs/"
+
+ def load_run(fn):
+ if not os.path.exists(RUNDIR + fn):
+ return None
+ return load(RUNDIR + fn)
+
+In this case, we've written ``load_run`` to look in a specific directory to see
+if it can find an output with the given name. So now we can write scripts that
+use this function:
+
+.. code-block:: python
+
+ from yt.mods import *
+
+ my_run = load_run("hotgasflow/DD0040/DD0040")
+
+And because we have imported from ``yt.mods`` we have access to the
+``load_run`` function defined in our plugin file.
+
+How do I cite yt?
+-----------------
+
+If you use yt in a publication, we'd very much appreciate a citation! You
+should feel free to cite the `ApJS paper
+<http://adsabs.harvard.edu/abs/2011ApJS..192....9T>`_ with the following BibTeX
+entry: ::
+
+ @ARTICLE{2011ApJS..192....9T,
+ author = {{Turk}, M.~J. and {Smith}, B.~D. and {Oishi}, J.~S. and {Skory}, S. and
+ {Skillman}, S.~W. and {Abel}, T. and {Norman}, M.~L.},
+ title = "{yt: A Multi-code Analysis Toolkit for Astrophysical Simulation Data}",
+ journal = {\apjs},
+ archivePrefix = "arXiv",
+ eprint = {1011.3514},
+ primaryClass = "astro-ph.IM",
+ keywords = {cosmology: theory, methods: data analysis, methods: numerical },
+ year = 2011,
+ month = jan,
+ volume = 192,
+ pages = {9-+},
+ doi = {10.1088/0067-0049/192/1/9},
+ adsurl = {http://adsabs.harvard.edu/abs/2011ApJS..192....9T},
+ adsnote = {Provided by the SAO/NASA Astrophysics Data System}
+ }
+
+If you use the Parallel Halo Finder, we have a
+`separate paper <http://adsabs.harvard.edu/abs/2010ApJS..191...43S>`_ that describes
+its implementation: ::
+
+ @ARTICLE{2010ApJS..191...43S,
+ author = {{Skory}, S. and {Turk}, M.~J. and {Norman}, M.~L. and {Coil}, A.~L.
+ },
+ title = "{Parallel HOP: A Scalable Halo Finder for Massive Cosmological Data Sets}",
+ journal = {\apjs},
+ archivePrefix = "arXiv",
+ eprint = {1001.3411},
+ primaryClass = "astro-ph.CO",
+ keywords = {galaxies: halos, methods: data analysis, methods: numerical },
+ year = 2010,
+ month = nov,
+ volume = 191,
+ pages = {43-57},
+ doi = {10.1088/0067-0049/191/1/43},
+ adsurl = {http://adsabs.harvard.edu/abs/2010ApJS..191...43S},
+ adsnote = {Provided by the SAO/NASA Astrophysics Data System}
+ }
diff -r 9868c22a4b59395723f2bae87a0ae8fbafce47a5 -r 4c30777c6ada6e32ae197a94ffb417478103b389 source/reference/index.rst
--- a/source/reference/index.rst
+++ b/source/reference/index.rst
@@ -7,10 +7,13 @@
.. toctree::
:maxdepth: 2
+ overview
code_support
command-line
+ faq/index.rst
api/api
python_introduction
configuration
field_list
+ sharing_data
changelog
diff -r 9868c22a4b59395723f2bae87a0ae8fbafce47a5 -r 4c30777c6ada6e32ae197a94ffb417478103b389 source/reference/overview.rst
--- /dev/null
+++ b/source/reference/overview.rst
@@ -0,0 +1,278 @@
+yt Concepts and History
+=======================
+
+.. sectionauthor:: J. S. Oishi <jsoishi at gmail.com>
+
+History
+-------
+
+yt was originally written by Matthew Turk in the course of his graduate
+studies. However, it is now a community-developed project with contributions
+from many people, the hospitality of several institutions, and benefiting from
+many different grants. With this community-driven approach and contributions
+from many external developers, it has evolved from a simple data-reader and
+exporter into what a fully-featured toolkit for analysis and visualization of
+adaptive mesh refinement data.
+
+yt was designed to be a completely Free (as in beer *and* as in freedom --
+"free and libre" as the saying goes) user-extensible framework for analyzing
+and visualizing astrophysical data, currently working with several different
+codes, including the "flagship" codes Enzo, Orion, Nyx and FLASH. It relies on
+no proprietary software -- although it can be and has been extended to
+interface with proprietary software and libraries -- and has been designed from
+the ground up to enable users to be as immersed in the data as they desire.
+
+yt is currently being developed by a team of developers. We used to include
+the entire list here, but it got too long, so now the best place to find it is
+to take a look at the current `CREDITS
+<http://hg.yt-project.org/yt/src/yt/CREDITS>`_ file. All development is
+conducted in the open, accessible at http://yt-project.org/ .
+
+
+What functionality does yt offer?
+---------------------------------
+
+yt has evolved substantially over the time of its development. Here is a
+**non-comprehensive** list of features:
+
+* Data Objects
+
+ * Arbitrary data objects (Spheres, cylinders, rectangular prisms, arbitrary index selection)
+ * Covering grids (smoothed and raw) for automatic ghost-zone generation
+ * Identification of topologically-connected sets in arbitrary fields
+ * Projections, orthogonal slices, oblique slices
+ * Axially-aligned rays
+ * Memory-conserving 1-, 2- and 3-D distribution functions of *arbitrary* fields and objects
+ * Halo-finding (HOP) algorithm with full particle information and sphere access
+ * Nearly **all** operations can be conducted in parallel
+
+* Data access
+
+ * Arbitrary field definition
+ * Derived quantities (average values, spin parameter, bulk velocity, etc)
+ * Custom C-written HDF5 backend for packed and unpacked AMR, NumPy-based HDF4 backend
+ * Flexible units system with CGS by default
+ * Per-user field and quantity plugins
+
+* Visualization
+
+ * Mathtext TeX-like text formatting
+ * Slices, projections, oblique slices
+ * Profiles and phase diagrams
+ * Linked zooms, colormaps, and saving across multiple plots
+ * Contours, vector plots, annotated boxes, grid boundary plot overlays.
+ * Parallel volume rendering with arbitrary emission and absorption
+ coefficients
+ * Off-axis projections and line integrals
+
+* Analysis Modules
+
+ * `Parallel Halo Finding <http://adsabs.harvard.edu/abs/2010ApJS..191...43S>`_
+ * Light cone generation
+ * Halo merger tree creation
+ * Level set extraction and clump identification
+ * Halo Mass Function
+ * SED generation
+ * Arbitrary global or sub-region two-point functions
+
+* Command-line tools
+
+ * Time-series movies
+ * HOP Halo Finding
+ * Quick slice and projection images
+ * Mapserver
+ * Bug reports
+ * IPython frontend
+
+* Access to components
+
+ * Monetary cost: **FREE**.
+ * Source code availability: **FULL**.
+ * Portability: **YES**.
+
+
+The Goals and Design of yt
+--------------------------
+
+There are many tools available for analysis and visualization of AMR
+data; there are many just for ``enzo``. So why ``yt``? Along the road
+to answering that question, we shall take a somewhat philosophical
+scenic route. For the more pragmatically minded, the answer is simple:
+what ``yt`` does not yet do, you can make it do so. This is not as
+glib as it may seem: it is in fact the main philosophical tennant that
+underlies ``yt``. In this section, it is not our goal to show you just
+how much ``yt`` already does. Instead, we will discuss how it is that
+``yt`` does anything at all. In doing so, we hope to give you a sense
+of whether or not ``yt`` will align with your science goals.
+
+At its core, ``yt`` is not a set of scripts to visualize AMR data, nor
+is it a set of low-level routines that return a homo- or even
+heterogeneous set of gridded data to your favorite scientific
+programming language--though ``yt`` incorporates both of these things,
+if your favorite scientific language is python. Instead, ``yt``
+provides a series of objects, some common AMR code structures (such as
+hierarchies and levels in a nested mesh) and some physical (a
+cylinder, cube, or sphere somewhere in the problem domain), that allow
+you to process AMR data in order to get at the fundamental underlying
+physics.
+
+
+``yt`` evolved naturally out of three design goals, though when Matt
+was busy writing it, he never really thought about them. Over
+time, it became clear that they are real and furthermore that they
+are important to understanding how to use ``yt``. These three goals
+are directed analysis, repeatability, and data exploration.
+
+Directed Analysis: Answering a Question
++++++++++++++++++++++++++++++++++++++++
+
+One of the main motivators for ``yt`` is to make it possible to sit
+down with a definite question about an AMR dataset and code up a
+script that will provide an answer to that question. Indeed much of its
+object-oriented nature can be viewed as a way perform operations on a
+data object. Given that AMR simulations are usually used to track some
+kind of structure formation, be it shocks, stars, or galaxies, the
+data object may not be the entire domain, but some region within it
+that is interesting. This data object in hand, ``yt`` makes it easy
+(if possible: some tasks ``yt`` can merely make *possible*) to
+manipulate that data in such a way to answer a question related to
+your research.
+
+Repeatability
++++++++++++++
+
+In any scientific analysis, being able to repeat the set of steps that
+prepared an answer or physical quantity is essential. To that end,
+much of the usage of ``yt`` is focused around running scripts,
+describing actions and plots programmatically. Being able to write a
+script or conducting a set of commands that will reproduce identical
+results is fundamentally important, and ``yt`` will attempt to make
+that easy. It's for this reason that the interactive features of
+``yt`` are not always as advanced as they might otherwise be. We are
+actively working on integrating the SAGE notebook system into ``yt``,
+which our preliminary tests suggest is a nice compromise between
+interactivity and repeatability.
+
+Exploration
++++++++++++
+
+However, it is the serendipitous nature of science that often finding
+the right question is not obvious at first. This is certainly true for
+astrophysical simulation, especially so for simulations of structure
+formation. What are we looking for, and how will we know when we find
+it?
+
+Quite often, the best way forward is to explore the simulation data as
+freely as possible. Without the ability for spot-examination,
+serendipitous discovery or general wandering, the code would be simply
+a pipeline, rather than a general tool. The flexible extensibility of
+``yt``, that is, the ability to create new derived quantities easily,
+as well as the ability to extract and display data regions in a
+variety of ways allows for this exploration.
+
+Object Methodology
+------------------
+
+``yt`` follows a strong object-oriented methodology. There is no real
+global state of ``yt``; all state is contained within objects that
+encapsulate an AMR code object or physical region.
+
+Physical Objects vs Code Objects
+++++++++++++++++++++++++++++++++
+
+The best way to think about doing things with ``yt`` is to think first
+of objects. The AMR code puts a number of objects on disk, and ``yt``
+has a matching set of objects to mimic these closely as possible. Your
+code runs (hopefully) a simulacrum of the physical universe, and thus
+in order to make sense of the output data, ``yt`` provides a set of
+objects meant to mimic the kinds of physical regions and processes you
+are interested in. For example, in a simulation of star formation out
+of some larger structure (the cosmic dark matter web, a turbulent
+molecular cloud), you might be interested in a sphere one parsec in
+radius around the point of maximum density. In a simulation of an
+accretion disk, you might want a cylindrical region of 1000 AU in
+radius and 10 AU in height with its axial vector aligned with the net
+angular momentum vector, which may be arbitrary with respect to the
+simulation cardinal axes. These are physical objects, and ``yt`` has a
+set of these too. Finally, you may wish to reduce the data to produce
+some essential data that represent a specific process. These
+reductions are also objects, and they are included in ``yt`` as well.
+
+Somewhat separate from this, but in the same spirit, are plots. In
+``yt``, plots are also objects that one can create, manipulate, and
+save. In the case of plots, however, you tell ``yt`` what you want to
+see, and it can fetch data from the appropriate source.
+
+In list form,
+
+ Code Objects
+ These are things that are on the disk that the AMR code knows about --
+ things like grids, data dumps, the grid hierarchy and so on.
+ Physical Objects
+ These are objects like spheres, rectangular prisms, slices, and
+ so on. These are collections of related data arranged by physical
+ properties, and they are not necessarily associated with a single
+ code object.
+ Reduced Objects
+ These are objects created by taking a set of data and reducing it
+ into a smaller format, suitable for a specific purpose.
+ Histograms, 1-D profiles, and averages are all members of this
+ category.
+ Plots
+ Plots are somewhat different than other objects, as they are
+ neither physical nor code. Instead, the plotting interface
+ accepts information about what you want to see, then goes and
+ fetches what is necessary--from code, physical, and reduced
+ objects as necessary.
+
+.. _intro_to_projections:
+
+Flexible Projections: an Example of Reusable Data Reduction
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+
+AMR data is best applied when the dynamic range in a quantity of
+interest (length or mass scales, typically) is large, but the volume
+filling factor of such interesting regions is small. In astronomy,
+virtually all available observations are projections on the sky, with
+little radial information about the observed structure. In order to
+compare with these observations, *projections* are an extremely useful
+data reduction for simulations. It is often useful to project to a
+given resolution, which may be as high as the highest subdomain in the
+AMR data set. However, projecting in a given direction through the
+full AMR data set can be quite costly in computing time. ``yt``'s
+project tool saves an *adaptive* projection when it completes this
+costly step, allowing you to make 2D images at whatever resolution you
+like with very modest computational resources. This idea, that of
+saving as much information as you need (and no more) to make the data
+reduction flexible for reuse is another core idea behind ``yt``. You
+should not have to spend computational resources and precious time to
+replot a projection from a 1000x1000 image to a 2000x2000 image. As a
+side note, in this specific case, because the 2D data product ``yt``
+produces is "smart", it never needs to use an array in memory as large
+as the full effective AMR resolution (which could be very large, and
+nearly devoid of unique information).
+
+
+Derived Fields and Derived Quantities
+-------------------------------------
+
+While the primary attraction of ``yt`` is the large set of basic code,
+physical, reduced, and plot objects already developed, at its core is the fact
+that any of the objects can be used as starting points for creating fields and
+quantities of your own devices. Derived quantities and derived fields are the
+physical objects ``yt`` creates from the "primitive" variables the simulation
+code stores. These may or may not be the so-called primitive variables of fluid
+dynamics (density, velocity, energy): they are whatever your simulation code
+writes to disk.
+
+Derived quantities are those data products derived from these variables such
+that the total amount of returned data is *less* than the number of cells.
+Derived fields, on the other hand, return a field with *equal* numbers of cells
+and the same geometry as the primitive variables from which it was derived. For
+example, ``yt`` could compute the gravitational potential at every point in
+space reconstructed from the density field.
+
+``yt`` already includes a large number of both derived fields and quantities,
+but its real power is that it is easy to create your own. See
+:ref:`creating-derived-fields` for detailed instructions on creating derived
+fields.
diff -r 9868c22a4b59395723f2bae87a0ae8fbafce47a5 -r 4c30777c6ada6e32ae197a94ffb417478103b389 source/reference/sharing_data.rst
--- /dev/null
+++ b/source/reference/sharing_data.rst
@@ -0,0 +1,108 @@
+What is the yt Hub?
+===================
+
+The yt data hub is a mechanism by which images, data objects and projects can
+be shared with other people. For instance, one can upload projections and
+browse them with an interface similar to Google Maps.
+
+.. note:: All items posted on the hub are public!
+
+Over time, more widgets will be added, and more datatypes will be able to be
+uploaded. If you are interested in adding more ways of sharing data, please
+email the developers' list. We would like to add support for 3D widgets such
+as isocontours as well as interactive binning and rebinning of data from yt
+data objects, to be displayed as phase plots and profiles.
+
+Registering a User
+------------------
+
+Because of problems with spammers, registering a user can only be done from the
+yt command line. Once you have registered a user, you can log on to the
+website and obtain an API key.
+
+To register a user:
+
+.. code-block:: bash
+
+ $ yt hub_register
+
+This will walk you through the process of registering. You will need to supply
+a name, a username, a password and an email address. Once you have gotten that
+out of the way, you can go to http://hub.yt-project.org/login and log in with
+your new password. You can then receive your API key by clicking on your
+username in the upper left.
+
+After you have gotten your API key, place it in in your ``~/.yt/config`` file:
+
+.. code-block:: none
+
+ [yt]
+ hub_api_key = 3fd8de56c2884c13a2de4dd51a80974b
+
+Replace ``3fd8de56c2884c13a2de4dd51a80974b`` with your API key. At this point,
+you're ready to go!
+
+What Can Be Uploaded
+--------------------
+
+Currently, the yt hub can accept these types of data:
+
+ * Projects and script repositories: these will be displayed with an optional
+ image, a description, and a link to the source repository.
+ * Projections and Slices: these will be displayed in a maps-like interface,
+ for interactive panning and zooming
+ * Plot collections: these will be displayed as a list of images
+
+How to Upload Data
+------------------
+
+Uploading data takes place inside scripts. For the most part, it is relatively
+simple to do: you construct the object you would like to share, and then you
+upload it.
+
+Uploading Projects
+~~~~~~~~~~~~~~~~~~
+
+For information on how to share a project or a set of scripts, see
+:ref:`share-your-scripts`.
+
+Uploading Projections and Slices
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Projections and slices both have a ``hub_upload`` method. Here is an example
+of uploading a projection:
+
+.. code-block:: python
+
+ from yt.mods import *
+ pf = load("IsolatedGalaxy/galaxy0030/galaxy0030")
+ proj = pf.h.proj(0, "Density", weight="Density")
+ proj.hub_upload()
+
+Here is an example of uploading a slice:
+
+.. code-block:: python
+
+ from yt.mods import *
+ pf = load("JHK-DD0030/galaxy0030")
+ sl = pf.h.slice(0, 0.5, fields=["Density"])
+ sl.hub_upload()
+
+Uploading Plot Collections
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Plot collections can be uploaded and viewed as a selection of images. To
+upload a plot collection, call ``hub_upload`` on the plot collection.
+
+.. code-block:: python
+
+ from yt.mods import *
+ pf = load("DD0252/DD0252")
+ pc = PlotCollection(pf, 'c')
+ pc.add_projection("Density", 0)
+ pc.add_slice("Temperature", 1)
+ pc.add_profile_sphere(0.2, 'unitary', ["Density", "Temperature"])
+ dd = pf.h.all_data()
+ pc.add_phase_object(dd, ["Density", "Temperature", "CellMassMsun"],
+ weight=None)
+ pc.hub_upload()
diff -r 9868c22a4b59395723f2bae87a0ae8fbafce47a5 -r 4c30777c6ada6e32ae197a94ffb417478103b389 source/sharing_data/index.rst
--- a/source/sharing_data/index.rst
+++ /dev/null
@@ -1,108 +0,0 @@
-What is the yt Hub?
-===================
-
-The yt data hub is a mechanism by which images, data objects and projects can
-be shared with other people. For instance, one can upload projections and
-browse them with an interface similar to Google Maps.
-
-.. note:: All items posted on the hub are public!
-
-Over time, more widgets will be added, and more datatypes will be able to be
-uploaded. If you are interested in adding more ways of sharing data, please
-email the developers' list. We would like to add support for 3D widgets such
-as isocontours as well as interactive binning and rebinning of data from yt
-data objects, to be displayed as phase plots and profiles.
-
-Registering a User
-------------------
-
-Because of problems with spammers, registering a user can only be done from the
-yt command line. Once you have registered a user, you can log on to the
-website and obtain an API key.
-
-To register a user:
-
-.. code-block:: bash
-
- $ yt hub_register
-
-This will walk you through the process of registering. You will need to supply
-a name, a username, a password and an email address. Once you have gotten that
-out of the way, you can go to http://hub.yt-project.org/login and log in with
-your new password. You can then receive your API key by clicking on your
-username in the upper left.
-
-After you have gotten your API key, place it in in your ``~/.yt/config`` file:
-
-.. code-block:: none
-
- [yt]
- hub_api_key = 3fd8de56c2884c13a2de4dd51a80974b
-
-Replace ``3fd8de56c2884c13a2de4dd51a80974b`` with your API key. At this point,
-you're ready to go!
-
-What Can Be Uploaded
---------------------
-
-Currently, the yt hub can accept these types of data:
-
- * Projects and script repositories: these will be displayed with an optional
- image, a description, and a link to the source repository.
- * Projections and Slices: these will be displayed in a maps-like interface,
- for interactive panning and zooming
- * Plot collections: these will be displayed as a list of images
-
-How to Upload Data
-------------------
-
-Uploading data takes place inside scripts. For the most part, it is relatively
-simple to do: you construct the object you would like to share, and then you
-upload it.
-
-Uploading Projects
-~~~~~~~~~~~~~~~~~~
-
-For information on how to share a project or a set of scripts, see
-:ref:`share-your-scripts`.
-
-Uploading Projections and Slices
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Projections and slices both have a ``hub_upload`` method. Here is an example
-of uploading a projection:
-
-.. code-block:: python
-
- from yt.mods import *
- pf = load("IsolatedGalaxy/galaxy0030/galaxy0030")
- proj = pf.h.proj(0, "Density", weight="Density")
- proj.hub_upload()
-
-Here is an example of uploading a slice:
-
-.. code-block:: python
-
- from yt.mods import *
- pf = load("JHK-DD0030/galaxy0030")
- sl = pf.h.slice(0, 0.5, fields=["Density"])
- sl.hub_upload()
-
-Uploading Plot Collections
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Plot collections can be uploaded and viewed as a selection of images. To
-upload a plot collection, call ``hub_upload`` on the plot collection.
-
-.. code-block:: python
-
- from yt.mods import *
- pf = load("DD0252/DD0252")
- pc = PlotCollection(pf, 'c')
- pc.add_projection("Density", 0)
- pc.add_slice("Temperature", 1)
- pc.add_profile_sphere(0.2, 'unitary', ["Density", "Temperature"])
- dd = pf.h.all_data()
- pc.add_phase_object(dd, ["Density", "Temperature", "CellMassMsun"],
- weight=None)
- pc.hub_upload()
Repository URL: https://bitbucket.org/yt_analysis/yt-doc/
--
This is a commit notification from bitbucket.org. You are receiving
this because you have the service enabled, addressing the recipient of
this email.
More information about the yt-svn
mailing list