[yt-svn] commit/yt-doc: 14 new changesets
Bitbucket
commits-noreply at bitbucket.org
Tue Nov 22 12:59:09 PST 2011
14 new commits in yt-doc:
https://bitbucket.org/yt_analysis/yt-doc/changeset/955e7ceff725/
changeset: 955e7ceff725
user: chummels
date: 2011-10-18 21:08:09
summary: Correcting an old reference to raven.
affected #: 1 file
diff -r b661fc15f7b9053a6ab59eb1f7207ac74093fc96 -r 955e7ceff72570ded93bb9034d6de0b41a7a2791 source/reference/api/derived_datatypes.rst
--- a/source/reference/api/derived_datatypes.rst
+++ b/source/reference/api/derived_datatypes.rst
@@ -7,7 +7,7 @@
These types are used to sum data up and either return that sum or return an
average. Typically they are more easily used through the
-`yt.raven.plot_collection` interface.
+`yt.visualization.plot_collection` interface.
.. py:module:: yt.data_objects
https://bitbucket.org/yt_analysis/yt-doc/changeset/a7f0690b4b82/
changeset: a7f0690b4b82
user: chummels
date: 2011-10-19 06:14:59
summary: Updating references to lagos in docs to be to updated classes/modules.
affected #: 3 files
diff -r 955e7ceff72570ded93bb9034d6de0b41a7a2791 -r a7f0690b4b826033ffed7bf57c8bb093c8ce019d source/analyzing/creating_derived_fields.rst
--- a/source/analyzing/creating_derived_fields.rst
+++ b/source/analyzing/creating_derived_fields.rst
@@ -103,8 +103,8 @@
objects define the way in which the field is generated, and when it is able to
be created. In this case, we mandate that parameters *center* and
*height_vector* are set before creating the field. These are set via
-:meth:`~yt.lagos.EnzoData.set_field_parameter`, which can be called on any
-object that has fields.
+:meth:`~yt.data_objects.data_containers.set_field_parameter`, which can
+be called on any object that has fields.
We can also define vector fields.
diff -r 955e7ceff72570ded93bb9034d6de0b41a7a2791 -r a7f0690b4b826033ffed7bf57c8bb093c8ce019d source/analyzing/objects.rst
--- a/source/analyzing/objects.rst
+++ b/source/analyzing/objects.rst
@@ -39,7 +39,7 @@
Information about how to create a new type of object can be found in
:ref:`creating-objects`. The field is returned as a single, flattened
array without spatial information. The best mechanism for
-manipulating spatial data is the :class:`~yt.lagos.CoveringGridBase` object.
+manipulating spatial data is the :class:`~yt.data_objects.data_containers.AMRCoveringGridBase` object.
The full list of fields that are available can be found as a property of the
Hierarchy or Static Output object that you wish to access. This property is
@@ -66,7 +66,7 @@
print pf.field_info["Pressure"].get_units()
This is a fast way to examine the units of a given field, and additionally you
-can use :meth:`yt.lagos.DerivedField.get_source` to get the source code:
+can use :meth:`yt.utilities.pydot.get_source` to get the source code:
.. code-block:: python
@@ -154,9 +154,11 @@
convenient to save an object or multiple objects out to disk and then restart
the calculation later. Personally, I found this most useful when dealing with
identification of clumps and contours (see :ref:`cookbook` for a recipe on how
-to find clumps and the API documentation for both :mod:`~yt.lagos.ContourFinder`
-and :mod:`~yt.lagos.Clump`) where the identification step can be quite
-time-consuming, but the analysis may be relatively fast.
+to find clumps and the API documentation for both
+:mod:`~yt.analysis_modules.level_sets.contour_finder.identify_contours`
+and :mod:`~yt.analysis_modules.level_sets.clump_handling.Clump`) where
+the identification step can be quite time-consuming, but the analysis
+may be relatively fast.
Typically, the save and load operations are used on 3D data objects. ``yt``
has a separate set of serialization operations for 2D objects such as
@@ -178,11 +180,11 @@
simulation time. These three characteristics should never be changed outside
of a simulation, they are independent of the file location on disk, and in
conjunction they should be uniquely identifying. (This process is all done in
-:mod:`~yt.fido` via :class:`~yt.fido.ParameterFileStore`.)
+:mod:`~yt.utilities.ParameterFileStorage` via :class:`~yt.utilities.ParameterFileStorage.ParameterFileStore`.)
To save an object, you can either save it in the ``.yt`` file affiliated with
the hierarchy or as a standalone file. For instance, using
-:meth:`~yt.lagos.AMRHierarchy.save_object` we can save a sphere.
+:meth:`~yt.data_objects.hierarchy.save_object` we can save a sphere.
.. code-block:: python
@@ -194,7 +196,7 @@
In a later session, we can load it using
-:meth:`~yt.lagos.AMRHierarchy.save_object`:
+:meth:`~yt.data_objects.hierarchy.load_object`:
.. code-block:: python
diff -r 955e7ceff72570ded93bb9034d6de0b41a7a2791 -r a7f0690b4b826033ffed7bf57c8bb093c8ce019d source/analyzing/particles.rst
--- a/source/analyzing/particles.rst
+++ b/source/analyzing/particles.rst
@@ -19,7 +19,8 @@
reduce memory usage as well as handle any problems that might arise from
spatial selection of particles.
-For instance, :class:`~yt.lagos.Halo` objects have a number of operations that
+For instance, :class:`~yt.analysis_modules.halo_finding.halo_objects.Halo`
+objects have a number of operations that
can transparently calculate center of mass of particles, bulk velocity, and so
on. Use those instead of obtaining the fields directly. Furthermore, any of
the spatially-addressable objects described in :ref:`using-objects` will
@@ -101,8 +102,8 @@
For the grids in the former category, the full set of particles residing in
those grids are loaded. The ones in the second require that a
-:class:`~yt.lagos.FakeGridForParticles` be created so that the particles
-residing in the region (as determined by their values of
+:class:`~yt.data_objects.data_containers.FakeGridForParticles` be created so
+that the particles residing in the region (as determined by their values of
``particle_position_x``, ``particle_position_y`` and ``particle_position_z``,
which must be loaded from disk) can be selected and cut from the full set of
particles. This requires that the full position information for the particles
https://bitbucket.org/yt_analysis/yt-doc/changeset/e964c0185abd/
changeset: e964c0185abd
user: chummels
date: 2011-10-19 06:33:43
summary: One more update to remove lagos references in docs.
affected #: 1 file
diff -r a7f0690b4b826033ffed7bf57c8bb093c8ce019d -r e964c0185abdef7b9dd4de46e7bb27fc9d39b659 source/visualizing/_cb_docstrings.inc
--- a/source/visualizing/_cb_docstrings.inc
+++ b/source/visualizing/_cb_docstrings.inc
@@ -65,7 +65,7 @@
(This is a proxy for :class:`~yt.visualization.plot_modifications.HopCircleCallback`.)
- Accepts a :class:`yt.lagos.HopList` *hop_output* and
+ Accepts a :class:`yt.HopList` *hop_output* and
plots up to *max_number* (None for unlimited) halos as
circles.
https://bitbucket.org/yt_analysis/yt-doc/changeset/07c0be6f850a/
changeset: 07c0be6f850a
user: jsoishi
date: 2011-10-19 16:10:50
summary: changed script-generated object list
affected #: 3 files
diff -r b661fc15f7b9053a6ab59eb1f7207ac74093fc96 -r 07c0be6f850aa0cf1c24b4bbe6dc5c97c37f421a helper_scripts/parse_object_list.py
--- a/helper_scripts/parse_object_list.py
+++ b/helper_scripts/parse_object_list.py
@@ -2,7 +2,7 @@
import inspect
from textwrap import TextWrapper
-pf = load("/Users/matthewturk/Research/data/RD0005-mine/RedshiftOutput0005")
+pf = load("/home/jsoishi/data/enzo/RD0005-mine/RedshiftOutput0005")
output = open("source/analyzing/_obj_docstrings.inc", "w")
@@ -10,9 +10,8 @@
.. class:: %(clsname)s%(sig)s:
+ For more information, see :ref:`%(docstring)s`
(This is a proxy for :class:`~%(clsproxy)sBase`.)
-%(docstring)s
-
"""
tw = TextWrapper(initial_indent=' ', subsequent_indent=' ', width=60)
@@ -26,7 +25,7 @@
sig = sig.replace("**kwargs", "**field_parameters")
clsproxy = "yt.data_objects.data_containers.%s" % (cls.__name__)
f.write(template % dict(clsname = clsname, sig = sig, clsproxy=clsproxy,
- docstring = "\n".join(tw.wrap(docstring))))
+ docstring = 'physical-object-api'))
for n,c in sorted(pf.h.__dict__.items()):
if hasattr(c, '_con_args'):
diff -r b661fc15f7b9053a6ab59eb1f7207ac74093fc96 -r 07c0be6f850aa0cf1c24b4bbe6dc5c97c37f421a source/analyzing/_obj_docstrings.inc
--- a/source/analyzing/_obj_docstrings.inc
+++ b/source/analyzing/_obj_docstrings.inc
@@ -2,196 +2,119 @@
.. class:: covering_grid(self, level, left_edge, dims, fields=None, pf=None, num_ghost_zones=0, use_pbar=True, **field_parameters):
+For more information, see :ref:`physical-object-api`
(This is a proxy for :class:`~yt.data_objects.data_containers.AMRCoveringGridBase`.)
- Returns an instance of AMR3DData, or prepares one.
- Usually only used as a base class. Note that *center* is
- supplied, but only used for fields and quantities that
- require it.
-
.. class:: cutting(self, normal, center, fields=None, node_name=None, **field_parameters):
+For more information, see :ref:`physical-object-api`
(This is a proxy for :class:`~yt.data_objects.data_containers.AMRCuttingPlaneBase`.)
- The Cutting Plane slices at an oblique angle, where we
- use the *normal* vector and the *center* to define the
- viewing plane. The 'up' direction is guessed at
- automatically.
-
.. class:: disk(self, center, normal, radius, height, fields=None, pf=None, **field_parameters):
+For more information, see :ref:`physical-object-api`
(This is a proxy for :class:`~yt.data_objects.data_containers.AMRCylinderBase`.)
- By providing a *center*, a *normal*, a *radius* and a
- *height* we can define a cylinder of any proportion.
- Only cells whose centers are within the cylinder will be
- selected.
-
.. class:: extracted_region(self, base_region, indices, force_refresh=True, **field_parameters):
+For more information, see :ref:`physical-object-api`
(This is a proxy for :class:`~yt.data_objects.data_containers.ExtractedRegionBase`.)
- Returns an instance of AMR3DData, or prepares one.
- Usually only used as a base class. Note that *center* is
- supplied, but only used for fields and quantities that
- require it.
-
.. class:: fixed_res_cutting(self, normal, center, width, dims, fields=None, node_name=None, **field_parameters):
+For more information, see :ref:`physical-object-api`
(This is a proxy for :class:`~yt.data_objects.data_containers.AMRFixedResCuttingPlaneBase`.)
- The fixed resolution Cutting Plane slices at an oblique
- angle, where we use the *normal* vector at the *center*
- to define the viewing plane. The plane is *width* units
- wide. The 'up' direction is guessed at automatically if
- not given.
-
.. class:: fixed_res_proj(self, axis, level, left_edge, dims, fields=None, pf=None, **field_parameters):
+For more information, see :ref:`physical-object-api`
(This is a proxy for :class:`~yt.data_objects.data_containers.AMRFixedResProjectionBase`.)
- A projection that provides fixed resolution output,
- operating in a grid-by-grid fashion.
-
-
-
-.. class:: float_covering_grid(self, level, left_edge, right_edge, dims, fields=None, pf=None, num_ghost_zones=0, use_pbar=True, **field_parameters):
-
- (This is a proxy for :class:`~yt.data_objects.data_containers.AMRFloatCoveringGridBase`.)
- The data object returned will consider grids up to
- *level* in generating fixed resolution data between
- *left_edge* and *right_edge* that is *dims* (3-values) on
- a side.
-
.. class:: grid_collection(self, center, grid_list, fields=None, pf=None, **field_parameters):
+For more information, see :ref:`physical-object-api`
(This is a proxy for :class:`~yt.data_objects.data_containers.AMRGridCollectionBase`.)
- By selecting an arbitrary *grid_list*, we can act on
- those grids. Child cells are not returned.
-
.. class:: inclined_box(self, origin, box_vectors, fields=None, pf=None, **field_parameters):
+For more information, see :ref:`physical-object-api`
(This is a proxy for :class:`~yt.data_objects.data_containers.AMRInclinedBoxBase`.)
- A rectangular prism with arbitrary alignment to the
- computational domain. *origin* is the origin of the box,
- while *box_vectors* is an array of ordering [ax, ijk]
- that describes the three vectors that describe the box.
- No checks are done to ensure that the box satisfies a
- right-hand rule, but if it doesn't, behavior is
- undefined.
-
.. class:: ortho_ray(self, axis, coords, fields=None, pf=None, **field_parameters):
+For more information, see :ref:`physical-object-api`
(This is a proxy for :class:`~yt.data_objects.data_containers.AMROrthoRayBase`.)
- Dimensionality is reduced to one, and an ordered list of
- points at an (x,y) tuple along *axis* are available.
+.. class:: overlap_proj(self, axis, field, weight_field=None, max_level=None, center=None, pf=None, source=None, node_name=None, field_cuts=None, preload_style='level', serialize=True, **field_parameters):
+
+For more information, see :ref:`physical-object-api`
+ (This is a proxy for :class:`~yt.data_objects.data_containers.AMRProjBase`.)
+
.. class:: periodic_region(self, center, left_edge, right_edge, fields=None, pf=None, **field_parameters):
+For more information, see :ref:`physical-object-api`
(This is a proxy for :class:`~yt.data_objects.data_containers.AMRPeriodicRegionBase`.)
- We create an object with a set of three *left_edge*
- coordinates, three *right_edge* coordinates, and a
- *center* that need not be the center.
-
.. class:: periodic_region_strict(self, center, left_edge, right_edge, fields=None, pf=None, **field_parameters):
+For more information, see :ref:`physical-object-api`
(This is a proxy for :class:`~yt.data_objects.data_containers.AMRPeriodicRegionStrictBase`.)
- We create an object with a set of three *left_edge*
- coordinates, three *right_edge* coordinates, and a
- *center* that need not be the center.
-
.. class:: proj(self, axis, field, weight_field=None, max_level=None, center=None, pf=None, source=None, node_name=None, field_cuts=None, preload_style='level', serialize=True, **field_parameters):
- (This is a proxy for :class:`~yt.data_objects.data_containers.AMRProjBase`.)
- AMRProj is a projection of a *field* along an *axis*.
- The field can have an associated *weight_field*, in which
- case the values are multiplied by a weight before being
- summed, and then divided by the sum of that weight.
-
-
-
-.. class:: quad_proj(self, axis, field, weight_field=None, max_level=None, center=None, pf=None, source=None, node_name=None, field_cuts=None, preload_style='level', serialize=True, **field_parameters):
-
+For more information, see :ref:`physical-object-api`
(This is a proxy for :class:`~yt.data_objects.data_containers.AMRQuadTreeProjBase`.)
- AMRProj is a projection of a *field* along an *axis*.
- The field can have an associated *weight_field*, in which
- case the values are multiplied by a weight before being
- summed, and then divided by the sum of that weight.
-
.. class:: ray(self, start_point, end_point, fields=None, pf=None, **field_parameters):
+For more information, see :ref:`physical-object-api`
(This is a proxy for :class:`~yt.data_objects.data_containers.AMRRayBase`.)
- We accept a start point and an end point and then get all
- the data between those two.
-
.. class:: region(self, center, left_edge, right_edge, fields=None, pf=None, **field_parameters):
+For more information, see :ref:`physical-object-api`
(This is a proxy for :class:`~yt.data_objects.data_containers.AMRRegionBase`.)
- We create an object with a set of three *left_edge*
- coordinates, three *right_edge* coordinates, and a
- *center* that need not be the center.
-
.. class:: region_strict(self, center, left_edge, right_edge, fields=None, pf=None, **field_parameters):
+For more information, see :ref:`physical-object-api`
(This is a proxy for :class:`~yt.data_objects.data_containers.AMRRegionStrictBase`.)
- We create an object with a set of three *left_edge*
- coordinates, three *right_edge* coordinates, and a
- *center* that need not be the center.
-
-
-
-.. class:: si_covering_grid(self, *args, **field_parameters):
-
- (This is a proxy for :class:`~yt.data_objects.data_containers.AMRIntSmoothedCoveringGridBase`.)
- Returns an instance of AMR3DData, or prepares one.
- Usually only used as a base class. Note that *center* is
- supplied, but only used for fields and quantities that
- require it.
-
.. class:: slice(self, axis, coord, fields=None, center=None, pf=None, node_name=False, **field_parameters):
+For more information, see :ref:`physical-object-api`
(This is a proxy for :class:`~yt.data_objects.data_containers.AMRSliceBase`.)
- Slice along *axis*, at the coordinate *coord*. Optionally supply fields.
-
.. class:: smoothed_covering_grid(self, *args, **field_parameters):
+For more information, see :ref:`physical-object-api`
(This is a proxy for :class:`~yt.data_objects.data_containers.AMRSmoothedCoveringGridBase`.)
- The data object returned will consider grids up to
- *level* in generating fixed resolution data between
- *left_edge* and *right_edge* that is *dims* (3-values) on
- a side.
-
.. class:: sphere(self, center, radius, fields=None, pf=None, **field_parameters):
+For more information, see :ref:`physical-object-api`
(This is a proxy for :class:`~yt.data_objects.data_containers.AMRSphereBase`.)
- The most famous of all the data objects, we define it via
- a *center* and a *radius*.
+
+.. class:: streamline(self, positions, fields=None, pf=None, **field_parameters):
+
+For more information, see :ref:`physical-object-api`
+ (This is a proxy for :class:`~yt.data_objects.data_containers.AMRStreamlineBase`.)
diff -r b661fc15f7b9053a6ab59eb1f7207ac74093fc96 -r 07c0be6f850aa0cf1c24b4bbe6dc5c97c37f421a source/reference/api/data_sources.rst
--- a/source/reference/api/data_sources.rst
+++ b/source/reference/api/data_sources.rst
@@ -3,6 +3,8 @@
.. py:module:: yt.data_objects
+.. _physical-object-api:
+
Physical Objects
----------------
https://bitbucket.org/yt_analysis/yt-doc/changeset/d37de90ab8c1/
changeset: d37de90ab8c1
user: jsoishi
date: 2011-10-19 16:11:17
summary: merged.
affected #: 5 files
diff -r 07c0be6f850aa0cf1c24b4bbe6dc5c97c37f421a -r d37de90ab8c1a6601e51577697631a8bb41983f5 source/analyzing/creating_derived_fields.rst
--- a/source/analyzing/creating_derived_fields.rst
+++ b/source/analyzing/creating_derived_fields.rst
@@ -103,8 +103,8 @@
objects define the way in which the field is generated, and when it is able to
be created. In this case, we mandate that parameters *center* and
*height_vector* are set before creating the field. These are set via
-:meth:`~yt.lagos.EnzoData.set_field_parameter`, which can be called on any
-object that has fields.
+:meth:`~yt.data_objects.data_containers.set_field_parameter`, which can
+be called on any object that has fields.
We can also define vector fields.
diff -r 07c0be6f850aa0cf1c24b4bbe6dc5c97c37f421a -r d37de90ab8c1a6601e51577697631a8bb41983f5 source/analyzing/objects.rst
--- a/source/analyzing/objects.rst
+++ b/source/analyzing/objects.rst
@@ -39,7 +39,7 @@
Information about how to create a new type of object can be found in
:ref:`creating-objects`. The field is returned as a single, flattened
array without spatial information. The best mechanism for
-manipulating spatial data is the :class:`~yt.lagos.CoveringGridBase` object.
+manipulating spatial data is the :class:`~yt.data_objects.data_containers.AMRCoveringGridBase` object.
The full list of fields that are available can be found as a property of the
Hierarchy or Static Output object that you wish to access. This property is
@@ -66,7 +66,7 @@
print pf.field_info["Pressure"].get_units()
This is a fast way to examine the units of a given field, and additionally you
-can use :meth:`yt.lagos.DerivedField.get_source` to get the source code:
+can use :meth:`yt.utilities.pydot.get_source` to get the source code:
.. code-block:: python
@@ -154,9 +154,11 @@
convenient to save an object or multiple objects out to disk and then restart
the calculation later. Personally, I found this most useful when dealing with
identification of clumps and contours (see :ref:`cookbook` for a recipe on how
-to find clumps and the API documentation for both :mod:`~yt.lagos.ContourFinder`
-and :mod:`~yt.lagos.Clump`) where the identification step can be quite
-time-consuming, but the analysis may be relatively fast.
+to find clumps and the API documentation for both
+:mod:`~yt.analysis_modules.level_sets.contour_finder.identify_contours`
+and :mod:`~yt.analysis_modules.level_sets.clump_handling.Clump`) where
+the identification step can be quite time-consuming, but the analysis
+may be relatively fast.
Typically, the save and load operations are used on 3D data objects. ``yt``
has a separate set of serialization operations for 2D objects such as
@@ -178,11 +180,11 @@
simulation time. These three characteristics should never be changed outside
of a simulation, they are independent of the file location on disk, and in
conjunction they should be uniquely identifying. (This process is all done in
-:mod:`~yt.fido` via :class:`~yt.fido.ParameterFileStore`.)
+:mod:`~yt.utilities.ParameterFileStorage` via :class:`~yt.utilities.ParameterFileStorage.ParameterFileStore`.)
To save an object, you can either save it in the ``.yt`` file affiliated with
the hierarchy or as a standalone file. For instance, using
-:meth:`~yt.lagos.AMRHierarchy.save_object` we can save a sphere.
+:meth:`~yt.data_objects.hierarchy.save_object` we can save a sphere.
.. code-block:: python
@@ -194,7 +196,7 @@
In a later session, we can load it using
-:meth:`~yt.lagos.AMRHierarchy.save_object`:
+:meth:`~yt.data_objects.hierarchy.load_object`:
.. code-block:: python
diff -r 07c0be6f850aa0cf1c24b4bbe6dc5c97c37f421a -r d37de90ab8c1a6601e51577697631a8bb41983f5 source/analyzing/particles.rst
--- a/source/analyzing/particles.rst
+++ b/source/analyzing/particles.rst
@@ -19,7 +19,8 @@
reduce memory usage as well as handle any problems that might arise from
spatial selection of particles.
-For instance, :class:`~yt.lagos.Halo` objects have a number of operations that
+For instance, :class:`~yt.analysis_modules.halo_finding.halo_objects.Halo`
+objects have a number of operations that
can transparently calculate center of mass of particles, bulk velocity, and so
on. Use those instead of obtaining the fields directly. Furthermore, any of
the spatially-addressable objects described in :ref:`using-objects` will
@@ -101,8 +102,8 @@
For the grids in the former category, the full set of particles residing in
those grids are loaded. The ones in the second require that a
-:class:`~yt.lagos.FakeGridForParticles` be created so that the particles
-residing in the region (as determined by their values of
+:class:`~yt.data_objects.data_containers.FakeGridForParticles` be created so
+that the particles residing in the region (as determined by their values of
``particle_position_x``, ``particle_position_y`` and ``particle_position_z``,
which must be loaded from disk) can be selected and cut from the full set of
particles. This requires that the full position information for the particles
diff -r 07c0be6f850aa0cf1c24b4bbe6dc5c97c37f421a -r d37de90ab8c1a6601e51577697631a8bb41983f5 source/reference/api/derived_datatypes.rst
--- a/source/reference/api/derived_datatypes.rst
+++ b/source/reference/api/derived_datatypes.rst
@@ -7,7 +7,7 @@
These types are used to sum data up and either return that sum or return an
average. Typically they are more easily used through the
-`yt.raven.plot_collection` interface.
+`yt.visualization.plot_collection` interface.
.. py:module:: yt.data_objects
diff -r 07c0be6f850aa0cf1c24b4bbe6dc5c97c37f421a -r d37de90ab8c1a6601e51577697631a8bb41983f5 source/visualizing/_cb_docstrings.inc
--- a/source/visualizing/_cb_docstrings.inc
+++ b/source/visualizing/_cb_docstrings.inc
@@ -65,7 +65,7 @@
(This is a proxy for :class:`~yt.visualization.plot_modifications.HopCircleCallback`.)
- Accepts a :class:`yt.lagos.HopList` *hop_output* and
+ Accepts a :class:`yt.HopList` *hop_output* and
plots up to *max_number* (None for unlimited) halos as
circles.
https://bitbucket.org/yt_analysis/yt-doc/changeset/cbdf91c4ab67/
changeset: cbdf91c4ab67
user: jsoishi
date: 2011-10-19 17:23:17
summary: rearranged table of contents.
affected #: 1 file
diff -r d37de90ab8c1a6601e51577697631a8bb41983f5 -r cbdf91c4ab67b51e2a19dd11a882deaa3b0c113a source/index.rst
--- a/source/index.rst
+++ b/source/index.rst
@@ -47,8 +47,7 @@
.. raw:: html
- <h2>Analysis and Visualization with yt</h2>
-
+ <h2>Getting Started</h2><table class="contentstable" align="center"><tr valign="top"><td width="50%">
@@ -59,7 +58,6 @@
What's yt all about?
</span></p></td>
-
<td width="50%"><p class="biglink"><a class="biglink" href="orientation.html">
@@ -72,13 +70,19 @@
<tr valign="top"><td width="50%"><p class="biglink">
- <a class="biglink" href="interacting_with_yt.html">
- Interacting with yt</a><br>
+ <a class="biglink" href="askingforhelp.html">
+ How to Ask for Help</a><br><span class="linkdescr">
- Different ways -- scripting, GUIs, prompts, explorers -- to explore
- your data.
+ Some guidelines on how and where to ask for help with yt
</span></p></td>
+ </tr>
+ </table>
+
+ <h2>Intermediate</h2>
+
+ <table class="contentstable" align="center">
+ <tr valign="top"><td width="50%"><p class="biglink"><a class="biglink" href="analyzing/index.html">
@@ -87,8 +91,6 @@
An overview of different ways to handle and process data
</span></p></td>
- </tr>
- <tr valign="top"><td width="50%"><p class="biglink"><a class="biglink" href="visualizing/index.html">
@@ -97,6 +99,16 @@
An overview of different ways to visualize data: projections,
slices, phase plots, and volume rendering
</span></p>
+ </td></tr>
+ <tr valign="top">
+ <td width="50%">
+ <p class="biglink">
+ <a class="biglink" href="interacting_with_yt.html">
+ Interacting with yt</a><br>
+ <span class="linkdescr">
+ Different ways -- scripting, GUIs, prompts, explorers -- to explore
+ your data.
+ </span></p></td><td width="50%"><p class="biglink">
@@ -108,61 +120,55 @@
</span></p></td></tr></table>
- <h2>Community, Developing, and Reference Materials</h2>
+ <h2>Advanced</h2>
+ <table class="contentstable" align="center">
+ <tr valign="top">
+ <td width="50%">
+ <p class="biglink">
+ <a class="biglink" href="advanced/index.html">
+ Advanced yt usage</a><br>
+ <span class="linkdescr">
+ Advanced topics: parallelism, debugging, ways to drive yt,
+ developing
+ </span></p>
+ </td>
+ <td width="50%">
+ <p class="biglink">
+ <a class="biglink" href="getting_involved.html">
+ Getting Involved</a><br>
+ <span class="linkdescr">
+ How to participate in the community, contribute code and share
+ scripts
+ </span></p>
+ </td>
+ </tr>
+ </table>
+
+ <h2>Reference Materials</h2>
+ <table class="contentstable" align="center">
+ <tr valign="top">
+ <td width="50%">
+ <p class="biglink">
+ <a class="biglink" href="cookbook/recipes.html">
+ The Cookbook</a><br>
+ <span class="linkdescr">
+ A bunch of illustrated examples of how to do things
+ </span></p>
+ </td>
+ <td width="50%">
+ <p class="biglink">
+ <a class="biglink" href="reference/index.html">
+ Reference Materials</a><br>
+ <span class="linkdescr">
+ A list of all bundled fields, API documentation, the Change Log...
+ </span></p>
+ <tr valign="top">
+ <td width="50%">
+ <p class="biglink">
+ <a class="biglink" href="faq.html">
+ FAQ</a><br>
+ <span class="linkdescr">
+ Frequently Asked Questions: answered for you!
+ </span></p>
+ </td></tr></table>
- <table class="contentstable" align="center">
- <tr valign="top">
- <td width="50%">
- <p class="biglink">
- <a class="biglink" href="cookbook/recipes.html">
- The Cookbook</a><br>
- <span class="linkdescr">
- A bunch of illustrated examples of how to do things
- </span></p>
- </td>
- <td width="50%">
- <p class="biglink">
- <a class="biglink" href="advanced/index.html">
- Advanced yt usage</a><br>
- <span class="linkdescr">
- Advanced topics: parallelism, debugging, ways to drive yt,
- developing
- </span></p>
- </td>
- </tr>
- <tr valign="top">
- <td width="50%">
- <p class="biglink">
- <a class="biglink" href="faq.html">
- FAQ</a><br>
- <span class="linkdescr">
- Frequently Asked Questions: answered for you!
- </span></p>
- </td>
- <td width="50%">
- <p class="biglink">
- <a class="biglink" href="getting_involved.html">
- Getting Involved</a><br>
- <span class="linkdescr">
- How to participate in the community, contribute code and share
- scripts
- </span></p>
- </td>
- </tr>
- <tr valign="top">
- <td width="50%">
- <p class="biglink">
- <a class="biglink" href="askingforhelp.html">
- How to Ask for Help</a><br>
- <span class="linkdescr">
- Some guidelines on how and where to ask for help with yt
- </span></p>
- </td>
- <td width="50%">
- <p class="biglink">
- <a class="biglink" href="reference/index.html">
- Reference Materials</a><br>
- <span class="linkdescr">
- A list of all bundled fields, API documentation, the Change Log...
- </span></p>
- </td></tr></table>
https://bitbucket.org/yt_analysis/yt-doc/changeset/ca707b44b77c/
changeset: ca707b44b77c
user: chummels
date: 2011-10-19 18:06:19
summary: Breaking up the head pages (welcome, orientation, interacting with yt, etc.) into individual subpages with individual tables of contents. This is useful for organizational purposes and not overwhelming the user.
affected #: 34 files
Diff too large to display.
https://bitbucket.org/yt_analysis/yt-doc/changeset/d397ac066416/
changeset: d397ac066416
user: chummels
date: 2011-10-19 18:07:03
summary: Merging.
affected #: 4 files
diff -r ca707b44b77c38e5e28d5f6bb276e20b9a89e6d6 -r d397ac066416129158633f8b768809d0dd173114 helper_scripts/parse_object_list.py
--- a/helper_scripts/parse_object_list.py
+++ b/helper_scripts/parse_object_list.py
@@ -2,7 +2,7 @@
import inspect
from textwrap import TextWrapper
-pf = load("/Users/matthewturk/Research/data/RD0005-mine/RedshiftOutput0005")
+pf = load("/home/jsoishi/data/enzo/RD0005-mine/RedshiftOutput0005")
output = open("source/analyzing/_obj_docstrings.inc", "w")
@@ -10,9 +10,8 @@
.. class:: %(clsname)s%(sig)s:
+ For more information, see :ref:`%(docstring)s`
(This is a proxy for :class:`~%(clsproxy)sBase`.)
-%(docstring)s
-
"""
tw = TextWrapper(initial_indent=' ', subsequent_indent=' ', width=60)
@@ -26,7 +25,7 @@
sig = sig.replace("**kwargs", "**field_parameters")
clsproxy = "yt.data_objects.data_containers.%s" % (cls.__name__)
f.write(template % dict(clsname = clsname, sig = sig, clsproxy=clsproxy,
- docstring = "\n".join(tw.wrap(docstring))))
+ docstring = 'physical-object-api'))
for n,c in sorted(pf.h.__dict__.items()):
if hasattr(c, '_con_args'):
diff -r ca707b44b77c38e5e28d5f6bb276e20b9a89e6d6 -r d397ac066416129158633f8b768809d0dd173114 source/analyzing/_obj_docstrings.inc
--- a/source/analyzing/_obj_docstrings.inc
+++ b/source/analyzing/_obj_docstrings.inc
@@ -2,196 +2,119 @@
.. class:: covering_grid(self, level, left_edge, dims, fields=None, pf=None, num_ghost_zones=0, use_pbar=True, **field_parameters):
+For more information, see :ref:`physical-object-api`
(This is a proxy for :class:`~yt.data_objects.data_containers.AMRCoveringGridBase`.)
- Returns an instance of AMR3DData, or prepares one.
- Usually only used as a base class. Note that *center* is
- supplied, but only used for fields and quantities that
- require it.
-
.. class:: cutting(self, normal, center, fields=None, node_name=None, **field_parameters):
+For more information, see :ref:`physical-object-api`
(This is a proxy for :class:`~yt.data_objects.data_containers.AMRCuttingPlaneBase`.)
- The Cutting Plane slices at an oblique angle, where we
- use the *normal* vector and the *center* to define the
- viewing plane. The 'up' direction is guessed at
- automatically.
-
.. class:: disk(self, center, normal, radius, height, fields=None, pf=None, **field_parameters):
+For more information, see :ref:`physical-object-api`
(This is a proxy for :class:`~yt.data_objects.data_containers.AMRCylinderBase`.)
- By providing a *center*, a *normal*, a *radius* and a
- *height* we can define a cylinder of any proportion.
- Only cells whose centers are within the cylinder will be
- selected.
-
.. class:: extracted_region(self, base_region, indices, force_refresh=True, **field_parameters):
+For more information, see :ref:`physical-object-api`
(This is a proxy for :class:`~yt.data_objects.data_containers.ExtractedRegionBase`.)
- Returns an instance of AMR3DData, or prepares one.
- Usually only used as a base class. Note that *center* is
- supplied, but only used for fields and quantities that
- require it.
-
.. class:: fixed_res_cutting(self, normal, center, width, dims, fields=None, node_name=None, **field_parameters):
+For more information, see :ref:`physical-object-api`
(This is a proxy for :class:`~yt.data_objects.data_containers.AMRFixedResCuttingPlaneBase`.)
- The fixed resolution Cutting Plane slices at an oblique
- angle, where we use the *normal* vector at the *center*
- to define the viewing plane. The plane is *width* units
- wide. The 'up' direction is guessed at automatically if
- not given.
-
.. class:: fixed_res_proj(self, axis, level, left_edge, dims, fields=None, pf=None, **field_parameters):
+For more information, see :ref:`physical-object-api`
(This is a proxy for :class:`~yt.data_objects.data_containers.AMRFixedResProjectionBase`.)
- A projection that provides fixed resolution output,
- operating in a grid-by-grid fashion.
-
-
-
-.. class:: float_covering_grid(self, level, left_edge, right_edge, dims, fields=None, pf=None, num_ghost_zones=0, use_pbar=True, **field_parameters):
-
- (This is a proxy for :class:`~yt.data_objects.data_containers.AMRFloatCoveringGridBase`.)
- The data object returned will consider grids up to
- *level* in generating fixed resolution data between
- *left_edge* and *right_edge* that is *dims* (3-values) on
- a side.
-
.. class:: grid_collection(self, center, grid_list, fields=None, pf=None, **field_parameters):
+For more information, see :ref:`physical-object-api`
(This is a proxy for :class:`~yt.data_objects.data_containers.AMRGridCollectionBase`.)
- By selecting an arbitrary *grid_list*, we can act on
- those grids. Child cells are not returned.
-
.. class:: inclined_box(self, origin, box_vectors, fields=None, pf=None, **field_parameters):
+For more information, see :ref:`physical-object-api`
(This is a proxy for :class:`~yt.data_objects.data_containers.AMRInclinedBoxBase`.)
- A rectangular prism with arbitrary alignment to the
- computational domain. *origin* is the origin of the box,
- while *box_vectors* is an array of ordering [ax, ijk]
- that describes the three vectors that describe the box.
- No checks are done to ensure that the box satisfies a
- right-hand rule, but if it doesn't, behavior is
- undefined.
-
.. class:: ortho_ray(self, axis, coords, fields=None, pf=None, **field_parameters):
+For more information, see :ref:`physical-object-api`
(This is a proxy for :class:`~yt.data_objects.data_containers.AMROrthoRayBase`.)
- Dimensionality is reduced to one, and an ordered list of
- points at an (x,y) tuple along *axis* are available.
+.. class:: overlap_proj(self, axis, field, weight_field=None, max_level=None, center=None, pf=None, source=None, node_name=None, field_cuts=None, preload_style='level', serialize=True, **field_parameters):
+
+For more information, see :ref:`physical-object-api`
+ (This is a proxy for :class:`~yt.data_objects.data_containers.AMRProjBase`.)
+
.. class:: periodic_region(self, center, left_edge, right_edge, fields=None, pf=None, **field_parameters):
+For more information, see :ref:`physical-object-api`
(This is a proxy for :class:`~yt.data_objects.data_containers.AMRPeriodicRegionBase`.)
- We create an object with a set of three *left_edge*
- coordinates, three *right_edge* coordinates, and a
- *center* that need not be the center.
-
.. class:: periodic_region_strict(self, center, left_edge, right_edge, fields=None, pf=None, **field_parameters):
+For more information, see :ref:`physical-object-api`
(This is a proxy for :class:`~yt.data_objects.data_containers.AMRPeriodicRegionStrictBase`.)
- We create an object with a set of three *left_edge*
- coordinates, three *right_edge* coordinates, and a
- *center* that need not be the center.
-
.. class:: proj(self, axis, field, weight_field=None, max_level=None, center=None, pf=None, source=None, node_name=None, field_cuts=None, preload_style='level', serialize=True, **field_parameters):
- (This is a proxy for :class:`~yt.data_objects.data_containers.AMRProjBase`.)
- AMRProj is a projection of a *field* along an *axis*.
- The field can have an associated *weight_field*, in which
- case the values are multiplied by a weight before being
- summed, and then divided by the sum of that weight.
-
-
-
-.. class:: quad_proj(self, axis, field, weight_field=None, max_level=None, center=None, pf=None, source=None, node_name=None, field_cuts=None, preload_style='level', serialize=True, **field_parameters):
-
+For more information, see :ref:`physical-object-api`
(This is a proxy for :class:`~yt.data_objects.data_containers.AMRQuadTreeProjBase`.)
- AMRProj is a projection of a *field* along an *axis*.
- The field can have an associated *weight_field*, in which
- case the values are multiplied by a weight before being
- summed, and then divided by the sum of that weight.
-
.. class:: ray(self, start_point, end_point, fields=None, pf=None, **field_parameters):
+For more information, see :ref:`physical-object-api`
(This is a proxy for :class:`~yt.data_objects.data_containers.AMRRayBase`.)
- We accept a start point and an end point and then get all
- the data between those two.
-
.. class:: region(self, center, left_edge, right_edge, fields=None, pf=None, **field_parameters):
+For more information, see :ref:`physical-object-api`
(This is a proxy for :class:`~yt.data_objects.data_containers.AMRRegionBase`.)
- We create an object with a set of three *left_edge*
- coordinates, three *right_edge* coordinates, and a
- *center* that need not be the center.
-
.. class:: region_strict(self, center, left_edge, right_edge, fields=None, pf=None, **field_parameters):
+For more information, see :ref:`physical-object-api`
(This is a proxy for :class:`~yt.data_objects.data_containers.AMRRegionStrictBase`.)
- We create an object with a set of three *left_edge*
- coordinates, three *right_edge* coordinates, and a
- *center* that need not be the center.
-
-
-
-.. class:: si_covering_grid(self, *args, **field_parameters):
-
- (This is a proxy for :class:`~yt.data_objects.data_containers.AMRIntSmoothedCoveringGridBase`.)
- Returns an instance of AMR3DData, or prepares one.
- Usually only used as a base class. Note that *center* is
- supplied, but only used for fields and quantities that
- require it.
-
.. class:: slice(self, axis, coord, fields=None, center=None, pf=None, node_name=False, **field_parameters):
+For more information, see :ref:`physical-object-api`
(This is a proxy for :class:`~yt.data_objects.data_containers.AMRSliceBase`.)
- Slice along *axis*, at the coordinate *coord*. Optionally supply fields.
-
.. class:: smoothed_covering_grid(self, *args, **field_parameters):
+For more information, see :ref:`physical-object-api`
(This is a proxy for :class:`~yt.data_objects.data_containers.AMRSmoothedCoveringGridBase`.)
- The data object returned will consider grids up to
- *level* in generating fixed resolution data between
- *left_edge* and *right_edge* that is *dims* (3-values) on
- a side.
-
.. class:: sphere(self, center, radius, fields=None, pf=None, **field_parameters):
+For more information, see :ref:`physical-object-api`
(This is a proxy for :class:`~yt.data_objects.data_containers.AMRSphereBase`.)
- The most famous of all the data objects, we define it via
- a *center* and a *radius*.
+
+.. class:: streamline(self, positions, fields=None, pf=None, **field_parameters):
+
+For more information, see :ref:`physical-object-api`
+ (This is a proxy for :class:`~yt.data_objects.data_containers.AMRStreamlineBase`.)
diff -r ca707b44b77c38e5e28d5f6bb276e20b9a89e6d6 -r d397ac066416129158633f8b768809d0dd173114 source/index.rst
--- a/source/index.rst
+++ b/source/index.rst
@@ -47,8 +47,7 @@
.. raw:: html
- <h2>Analysis and Visualization with yt</h2>
-
+ <h2>Getting Started</h2><table class="contentstable" align="center"><tr valign="top"><td width="50%">
@@ -59,7 +58,6 @@
What's yt all about?
</span></p></td>
-
<td width="50%"><p class="biglink"><a class="biglink" href="orientation.html">
@@ -72,13 +70,19 @@
<tr valign="top"><td width="50%"><p class="biglink">
- <a class="biglink" href="interacting_with_yt.html">
- Interacting with yt</a><br>
+ <a class="biglink" href="askingforhelp.html">
+ How to Ask for Help</a><br><span class="linkdescr">
- Different ways -- scripting, GUIs, prompts, explorers -- to explore
- your data.
+ Some guidelines on how and where to ask for help with yt
</span></p></td>
+ </tr>
+ </table>
+
+ <h2>Intermediate</h2>
+
+ <table class="contentstable" align="center">
+ <tr valign="top"><td width="50%"><p class="biglink"><a class="biglink" href="analyzing/index.html">
@@ -87,8 +91,6 @@
An overview of different ways to handle and process data
</span></p></td>
- </tr>
- <tr valign="top"><td width="50%"><p class="biglink"><a class="biglink" href="visualizing/index.html">
@@ -97,6 +99,16 @@
An overview of different ways to visualize data: projections,
slices, phase plots, and volume rendering
</span></p>
+ </td></tr>
+ <tr valign="top">
+ <td width="50%">
+ <p class="biglink">
+ <a class="biglink" href="interacting_with_yt.html">
+ Interacting with yt</a><br>
+ <span class="linkdescr">
+ Different ways -- scripting, GUIs, prompts, explorers -- to explore
+ your data.
+ </span></p></td><td width="50%"><p class="biglink">
@@ -108,61 +120,55 @@
</span></p></td></tr></table>
- <h2>Community, Developing, and Reference Materials</h2>
+ <h2>Advanced</h2>
+ <table class="contentstable" align="center">
+ <tr valign="top">
+ <td width="50%">
+ <p class="biglink">
+ <a class="biglink" href="advanced/index.html">
+ Advanced yt usage</a><br>
+ <span class="linkdescr">
+ Advanced topics: parallelism, debugging, ways to drive yt,
+ developing
+ </span></p>
+ </td>
+ <td width="50%">
+ <p class="biglink">
+ <a class="biglink" href="getting_involved.html">
+ Getting Involved</a><br>
+ <span class="linkdescr">
+ How to participate in the community, contribute code and share
+ scripts
+ </span></p>
+ </td>
+ </tr>
+ </table>
+
+ <h2>Reference Materials</h2>
+ <table class="contentstable" align="center">
+ <tr valign="top">
+ <td width="50%">
+ <p class="biglink">
+ <a class="biglink" href="cookbook/recipes.html">
+ The Cookbook</a><br>
+ <span class="linkdescr">
+ A bunch of illustrated examples of how to do things
+ </span></p>
+ </td>
+ <td width="50%">
+ <p class="biglink">
+ <a class="biglink" href="reference/index.html">
+ Reference Materials</a><br>
+ <span class="linkdescr">
+ A list of all bundled fields, API documentation, the Change Log...
+ </span></p>
+ <tr valign="top">
+ <td width="50%">
+ <p class="biglink">
+ <a class="biglink" href="faq.html">
+ FAQ</a><br>
+ <span class="linkdescr">
+ Frequently Asked Questions: answered for you!
+ </span></p>
+ </td></tr></table>
- <table class="contentstable" align="center">
- <tr valign="top">
- <td width="50%">
- <p class="biglink">
- <a class="biglink" href="cookbook/recipes.html">
- The Cookbook</a><br>
- <span class="linkdescr">
- A bunch of illustrated examples of how to do things
- </span></p>
- </td>
- <td width="50%">
- <p class="biglink">
- <a class="biglink" href="advanced/index.html">
- Advanced yt usage</a><br>
- <span class="linkdescr">
- Advanced topics: parallelism, debugging, ways to drive yt,
- developing
- </span></p>
- </td>
- </tr>
- <tr valign="top">
- <td width="50%">
- <p class="biglink">
- <a class="biglink" href="faq.html">
- FAQ</a><br>
- <span class="linkdescr">
- Frequently Asked Questions: answered for you!
- </span></p>
- </td>
- <td width="50%">
- <p class="biglink">
- <a class="biglink" href="getting_involved.html">
- Getting Involved</a><br>
- <span class="linkdescr">
- How to participate in the community, contribute code and share
- scripts
- </span></p>
- </td>
- </tr>
- <tr valign="top">
- <td width="50%">
- <p class="biglink">
- <a class="biglink" href="askingforhelp.html">
- How to Ask for Help</a><br>
- <span class="linkdescr">
- Some guidelines on how and where to ask for help with yt
- </span></p>
- </td>
- <td width="50%">
- <p class="biglink">
- <a class="biglink" href="reference/index.html">
- Reference Materials</a><br>
- <span class="linkdescr">
- A list of all bundled fields, API documentation, the Change Log...
- </span></p>
- </td></tr></table>
diff -r ca707b44b77c38e5e28d5f6bb276e20b9a89e6d6 -r d397ac066416129158633f8b768809d0dd173114 source/reference/api/data_sources.rst
--- a/source/reference/api/data_sources.rst
+++ b/source/reference/api/data_sources.rst
@@ -3,6 +3,8 @@
.. py:module:: yt.data_objects
+.. _physical-object-api:
+
Physical Objects
----------------
https://bitbucket.org/yt_analysis/yt-doc/changeset/b061e73269d9/
changeset: b061e73269d9
user: chummels
date: 2011-10-19 18:50:24
summary: Linking front page to new topical subpages.
affected #: 7 files
diff -r d397ac066416129158633f8b768809d0dd173114 -r b061e73269d9cceff33f2112c3f81ea9ee0420bc source/cookbook/index.rst
--- /dev/null
+++ b/source/cookbook/index.rst
@@ -0,0 +1,55 @@
+.. _cookbook:
+
+Cookbook
+========
+
+
+yt scripts can be a bit intimidating, and at times a bit obtuse. But there's a
+lot you can do, and this section of the manual will assist with figuring out
+how to do some fairly common tasks -- which can lead to combining these, with
+other Python code, into more complicated and advanced tasks.
+
+.. note::
+ All of these scripts are located in the mercurial repository at
+ http://hg.yt-project.org/cookbook/ . If you want to take a look at more
+ complex recipes, or submit your own, check out the `yt Hub
+ <http://hub.yt-project.org>`.
+
+.. contents::
+ :depth: 1
+ :local:
+ :backlinks: none
+
+.. include:: simple_slice.inc
+.. include:: simple_projection.inc
+.. include:: aligned_cutting_plane.inc
+.. include:: sum_mass_in_sphere.inc
+.. include:: simple_phase.inc
+.. include:: simple_profile.inc
+.. include:: simple_radial_profile.inc
+.. include:: halo_finding.inc
+.. include:: halo_plotting.inc
+.. include:: halo_particle_plotting.inc
+.. include:: arbitrary_vectors_on_slice.inc
+.. include:: contours_on_slice.inc
+.. include:: velocity_vectors_on_slice.inc
+.. include:: average_value.inc
+.. include:: find_clumps.inc
+.. include:: global_phase_plots.inc
+.. include:: halo_mass_info.inc
+.. include:: multi_width_save.inc
+.. include:: zoomin_frames.inc
+.. include:: overplot_particles.inc
+.. include:: multi_plot.inc
+.. include:: multi_plot_3x2.inc
+.. include:: time_series_phase.inc
+.. include:: time_series_quantity.inc
+.. include:: extract_fixed_resolution_data.inc
+.. include:: run_halo_profiler.inc
+.. include:: simulation_halo_profiler.inc
+.. include:: make_light_cone.inc
+.. include:: unique_light_cones.inc
+.. include:: light_cone_halo_mask.inc
+.. include:: make_light_ray.inc
+.. include:: simple_volume_rendering.inc
+.. include:: offaxis_projection.inc
diff -r d397ac066416129158633f8b768809d0dd173114 -r b061e73269d9cceff33f2112c3f81ea9ee0420bc source/cookbook/recipes.rst
--- a/source/cookbook/recipes.rst
+++ /dev/null
@@ -1,55 +0,0 @@
-.. _cookbook:
-
-Cookbook
-========
-
-
-yt scripts can be a bit intimidating, and at times a bit obtuse. But there's a
-lot you can do, and this section of the manual will assist with figuring out
-how to do some fairly common tasks -- which can lead to combining these, with
-other Python code, into more complicated and advanced tasks.
-
-.. note::
- All of these scripts are located in the mercurial repository at
- http://hg.yt-project.org/cookbook/ . If you want to take a look at more
- complex recipes, or submit your own, check out the `yt Hub
- <http://hub.yt-project.org>`.
-
-.. contents::
- :depth: 1
- :local:
- :backlinks: none
-
-.. include:: simple_slice.inc
-.. include:: simple_projection.inc
-.. include:: aligned_cutting_plane.inc
-.. include:: sum_mass_in_sphere.inc
-.. include:: simple_phase.inc
-.. include:: simple_profile.inc
-.. include:: simple_radial_profile.inc
-.. include:: halo_finding.inc
-.. include:: halo_plotting.inc
-.. include:: halo_particle_plotting.inc
-.. include:: arbitrary_vectors_on_slice.inc
-.. include:: contours_on_slice.inc
-.. include:: velocity_vectors_on_slice.inc
-.. include:: average_value.inc
-.. include:: find_clumps.inc
-.. include:: global_phase_plots.inc
-.. include:: halo_mass_info.inc
-.. include:: multi_width_save.inc
-.. include:: zoomin_frames.inc
-.. include:: overplot_particles.inc
-.. include:: multi_plot.inc
-.. include:: multi_plot_3x2.inc
-.. include:: time_series_phase.inc
-.. include:: time_series_quantity.inc
-.. include:: extract_fixed_resolution_data.inc
-.. include:: run_halo_profiler.inc
-.. include:: simulation_halo_profiler.inc
-.. include:: make_light_cone.inc
-.. include:: unique_light_cones.inc
-.. include:: light_cone_halo_mask.inc
-.. include:: make_light_ray.inc
-.. include:: simple_volume_rendering.inc
-.. include:: offaxis_projection.inc
diff -r d397ac066416129158633f8b768809d0dd173114 -r b061e73269d9cceff33f2112c3f81ea9ee0420bc source/faq/faq.rst
--- a/source/faq/faq.rst
+++ /dev/null
@@ -1,122 +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:
-
-.. _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:
-
-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.
-
diff -r d397ac066416129158633f8b768809d0dd173114 -r b061e73269d9cceff33f2112c3f81ea9ee0420bc source/faq/index.rst
--- /dev/null
+++ b/source/faq/index.rst
@@ -0,0 +1,122 @@
+.. _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:
+
+.. _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:
+
+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.
+
diff -r d397ac066416129158633f8b768809d0dd173114 -r b061e73269d9cceff33f2112c3f81ea9ee0420bc source/getting_involved/getting_involved.rst
--- a/source/getting_involved/getting_involved.rst
+++ /dev/null
@@ -1,155 +0,0 @@
-.. _getting-involved:
-
-Getting Involved
-================
-
-There are *lots* of ways to get involved with yt, as a community and as a
-technical system -- not all of them just contributing code, but also
-participating in the community, helping us with designing the websites, adding
-documentation, and sharing your scripts with others.
-
-Coding is only one way to be involved!
-
-Communication Channels
-----------------------
-
-There are four main communication channels for yt:
-
- * We also have an IRC channel, on ``irc.freenode.net`` in ``#yt``, which can be a
- bit less on-topic than the mailing lists. You can connect through our web
- gateway without any special client, at http://yt-project.org/irc.html .
- *IRC is the first stop for conversation!*
- * `yt-users <http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org>`_
- is a relatively high-traffic mailing list where people are encouraged to ask
- questions about the code, figure things out and so on.
- * `yt-dev <http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org>`_ is
- a much lower-traffic mailing list designed to focus on discussions of
- improvements to the code, ideas about planning, development issues, and so
- on.
- * `yt-svn <http://lists.spacepope.org/listinfo.cgi/yt-svn-spacepope.org>`_ is
- the (now-inaccurately titled) mailing list where all pushes to the primary
- repository are sent.
-
-The easiest way to get involved with yt is to read the mailing lists, hang out
-in IRC, and participate. If someone asks a question you know the answer to (or
-have your own question about!) write back and answer it.
-
-If you have an idea about something, suggest it! We not only welcome
-participation, we encourage it.
-
-.. _share-your-scripts:
-
-Share Your Scripts
-------------------
-
-The next easiest way to get involved with yt is to participate in the `yt Hub
-<http://hub.yt-project.org/>`_. This is a place where scripts, paper
-repositories, documents and so on can be submitted to share with the broader
-community.
-
-If you have a repository on `BitBucket <https://bitbucket.org/>`_ then you can
-simply submit it through the ytHub submit link. Otherwise, we provide the
-``yt hubsubmit`` command, which will guide you through the process of creating
-a mercurial repository, uploading it to BitBucket, and then submitting it
-directly to the Hub.
-
-This is one of the best ways to get involved in the community! We would love
-to have more examples that show complex or advanced behavior -- and if you have
-used such scripts to write a paper, that too would be an amazing contribution.
-
-Documentation and Screencasts
------------------------------
-
-The yt documentation -- which you are reading right now -- is constantly being
-updated, and it is a task we would very much appreciate assistance with.
-Whether that is adding a section, updating an outdated section, contributing
-typo or grammatical fixes, adding a FAQ, or increasing coverage of
-functionality, it would be very helpful if you wanted to help out.
-
-The easiest way to help out is to fork the repository:
-
-http://hg.yt-project.org/yt-doc/fork
-
-and then make your changes in your own fork. When you are done, issue a pull
-request through the website for your new fork, and we can comment back and
-forth and eventually accept your changes.
-
-One of the more interesting ways we are attempting to do lately is to add
-screencasts to the documentation -- these are recordings of people executing
-sessions in a terminal or in a web browser, showing off functionality and
-describing how to do various things. These provide a more dynamic and
-engaging way of demonstrating functionality and teaching methods.
-
-One easy place to record screencasts is with `Screencast-O-Matic
-<http://www.screencast-o-matic.com/>`_ but there are many to choose from. Once
-you have recorded it, let us know and be sure to add it to the
-`yt Vimeo group <http://vimeo.com/groups/ytgallery>`_. We'll then link to it
-from the documentation!
-
-Gallery Images and Videos
--------------------------
-
-If you have an image or video you'd like to display in the image or video
-galleries, getting it included it easy! For the image, you can either fork the
-`yt homepage repository <http://bitbucket.org/MatthewTurk/yt-homepage>`_ and
-add it there, or email it to us and we'll add it to the `Image Gallery
-<http://hg.yt-project.org/yt/wiki/ImageGallery>`_. If you have a video, just
-add it to the `yt Vimeo group <http://vimeo.com/groups/ytgallery>`_.
-
-We're eager to show off the images you make with yt, so please feel free to
-drop `us <http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org>`_ a
-line and let us know if you've got something great!
-
-Technical Contributions
------------------------
-
-Contributing code is another excellent way to participate -- whether it's
-bug fixes, new features, analysis modules, or a new code frontend.
-
-The process is pretty simple: fork on BitBucket, make changes, issue a pull
-request. We can then go back and forth with comments in the pull request, but
-usually we end up accepting.
-
-For more information, see :ref:`contributing-code`, where we spell out how to
-get up and running with a development environment, how to commit, and how to
-use BitBucket.
-
-Online Presence
----------------
-
-Some of these fall under the other items, but if you'd like to help out with
-the website or any of the other ways yt is presented online, please feel free!
-Almost everything is kept in hg repositories on BitBucket, and it is very easy
-to fork and contribute back changes.
-
-Please feel free to dig in and contribute changes.
-
-Word of Mouth
--------------
-
-If you're using yt and it has increased your productivity, please feel
-encouraged to share that information. Cite our `paper
-<http://adsabs.harvard.edu/abs/2011ApJS..192....9T>`_, tell your colleagues,
-and just spread word of mouth. By telling people about your successes, you'll
-help bring more eyes and hands to the table -- in this manner, by increasing
-participation, collaboration, and simply spreading the limits of what the code
-is asked to do, we hope to help scale the utility and capability of yt with the
-community size.
-
-Feel free to `blog <http://blog.yt-project.org/>`_ about, `tweet
-<http://twitter.com/yt_astro>`_ about and talk about what you are up to!
-
-Long-Term Projects
-------------------
-
-There are some wild-eyed, out-there ideas that have been bandied about for the
-future directions of yt -- some of them even written into the mission
-statement. The ultimate goal is to move past simple analysis and visualization
-of data and begin to approach it from the other side, of generating data,
-running solvers. We also hope to increase its ability to act as an in situ
-analysis code, by presenting a unified protocol. Other projects include
-interfacing with ParaView and VisIt, creating a web GUI for running
-simulations, creating a run-tracker that follows simulations in progress, a
-federated database for simulation outputs, and so on and so forth.
-
-yt is an ambitious project. Let's be ambitious together.
diff -r d397ac066416129158633f8b768809d0dd173114 -r b061e73269d9cceff33f2112c3f81ea9ee0420bc source/getting_involved/index.rst
--- /dev/null
+++ b/source/getting_involved/index.rst
@@ -0,0 +1,155 @@
+.. _getting-involved:
+
+Getting Involved
+================
+
+There are *lots* of ways to get involved with yt, as a community and as a
+technical system -- not all of them just contributing code, but also
+participating in the community, helping us with designing the websites, adding
+documentation, and sharing your scripts with others.
+
+Coding is only one way to be involved!
+
+Communication Channels
+----------------------
+
+There are four main communication channels for yt:
+
+ * We also have an IRC channel, on ``irc.freenode.net`` in ``#yt``, which can be a
+ bit less on-topic than the mailing lists. You can connect through our web
+ gateway without any special client, at http://yt-project.org/irc.html .
+ *IRC is the first stop for conversation!*
+ * `yt-users <http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org>`_
+ is a relatively high-traffic mailing list where people are encouraged to ask
+ questions about the code, figure things out and so on.
+ * `yt-dev <http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org>`_ is
+ a much lower-traffic mailing list designed to focus on discussions of
+ improvements to the code, ideas about planning, development issues, and so
+ on.
+ * `yt-svn <http://lists.spacepope.org/listinfo.cgi/yt-svn-spacepope.org>`_ is
+ the (now-inaccurately titled) mailing list where all pushes to the primary
+ repository are sent.
+
+The easiest way to get involved with yt is to read the mailing lists, hang out
+in IRC, and participate. If someone asks a question you know the answer to (or
+have your own question about!) write back and answer it.
+
+If you have an idea about something, suggest it! We not only welcome
+participation, we encourage it.
+
+.. _share-your-scripts:
+
+Share Your Scripts
+------------------
+
+The next easiest way to get involved with yt is to participate in the `yt Hub
+<http://hub.yt-project.org/>`_. This is a place where scripts, paper
+repositories, documents and so on can be submitted to share with the broader
+community.
+
+If you have a repository on `BitBucket <https://bitbucket.org/>`_ then you can
+simply submit it through the ytHub submit link. Otherwise, we provide the
+``yt hubsubmit`` command, which will guide you through the process of creating
+a mercurial repository, uploading it to BitBucket, and then submitting it
+directly to the Hub.
+
+This is one of the best ways to get involved in the community! We would love
+to have more examples that show complex or advanced behavior -- and if you have
+used such scripts to write a paper, that too would be an amazing contribution.
+
+Documentation and Screencasts
+-----------------------------
+
+The yt documentation -- which you are reading right now -- is constantly being
+updated, and it is a task we would very much appreciate assistance with.
+Whether that is adding a section, updating an outdated section, contributing
+typo or grammatical fixes, adding a FAQ, or increasing coverage of
+functionality, it would be very helpful if you wanted to help out.
+
+The easiest way to help out is to fork the repository:
+
+http://hg.yt-project.org/yt-doc/fork
+
+and then make your changes in your own fork. When you are done, issue a pull
+request through the website for your new fork, and we can comment back and
+forth and eventually accept your changes.
+
+One of the more interesting ways we are attempting to do lately is to add
+screencasts to the documentation -- these are recordings of people executing
+sessions in a terminal or in a web browser, showing off functionality and
+describing how to do various things. These provide a more dynamic and
+engaging way of demonstrating functionality and teaching methods.
+
+One easy place to record screencasts is with `Screencast-O-Matic
+<http://www.screencast-o-matic.com/>`_ but there are many to choose from. Once
+you have recorded it, let us know and be sure to add it to the
+`yt Vimeo group <http://vimeo.com/groups/ytgallery>`_. We'll then link to it
+from the documentation!
+
+Gallery Images and Videos
+-------------------------
+
+If you have an image or video you'd like to display in the image or video
+galleries, getting it included it easy! For the image, you can either fork the
+`yt homepage repository <http://bitbucket.org/MatthewTurk/yt-homepage>`_ and
+add it there, or email it to us and we'll add it to the `Image Gallery
+<http://hg.yt-project.org/yt/wiki/ImageGallery>`_. If you have a video, just
+add it to the `yt Vimeo group <http://vimeo.com/groups/ytgallery>`_.
+
+We're eager to show off the images you make with yt, so please feel free to
+drop `us <http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org>`_ a
+line and let us know if you've got something great!
+
+Technical Contributions
+-----------------------
+
+Contributing code is another excellent way to participate -- whether it's
+bug fixes, new features, analysis modules, or a new code frontend.
+
+The process is pretty simple: fork on BitBucket, make changes, issue a pull
+request. We can then go back and forth with comments in the pull request, but
+usually we end up accepting.
+
+For more information, see :ref:`contributing-code`, where we spell out how to
+get up and running with a development environment, how to commit, and how to
+use BitBucket.
+
+Online Presence
+---------------
+
+Some of these fall under the other items, but if you'd like to help out with
+the website or any of the other ways yt is presented online, please feel free!
+Almost everything is kept in hg repositories on BitBucket, and it is very easy
+to fork and contribute back changes.
+
+Please feel free to dig in and contribute changes.
+
+Word of Mouth
+-------------
+
+If you're using yt and it has increased your productivity, please feel
+encouraged to share that information. Cite our `paper
+<http://adsabs.harvard.edu/abs/2011ApJS..192....9T>`_, tell your colleagues,
+and just spread word of mouth. By telling people about your successes, you'll
+help bring more eyes and hands to the table -- in this manner, by increasing
+participation, collaboration, and simply spreading the limits of what the code
+is asked to do, we hope to help scale the utility and capability of yt with the
+community size.
+
+Feel free to `blog <http://blog.yt-project.org/>`_ about, `tweet
+<http://twitter.com/yt_astro>`_ about and talk about what you are up to!
+
+Long-Term Projects
+------------------
+
+There are some wild-eyed, out-there ideas that have been bandied about for the
+future directions of yt -- some of them even written into the mission
+statement. The ultimate goal is to move past simple analysis and visualization
+of data and begin to approach it from the other side, of generating data,
+running solvers. We also hope to increase its ability to act as an in situ
+analysis code, by presenting a unified protocol. Other projects include
+interfacing with ParaView and VisIt, creating a web GUI for running
+simulations, creating a run-tracker that follows simulations in progress, a
+federated database for simulation outputs, and so on and so forth.
+
+yt is an ambitious project. Let's be ambitious together.
diff -r d397ac066416129158633f8b768809d0dd173114 -r b061e73269d9cceff33f2112c3f81ea9ee0420bc source/index.rst
--- a/source/index.rst
+++ b/source/index.rst
@@ -31,17 +31,17 @@
:maxdepth: 1
:hidden:
- welcome_to_yt
- orientation
- interacting_with_yt
+ welcome/index
+ orientation/index
+ interacting/index
analyzing/index
visualizing/index
analysis_modules/index
- cookbook/recipes
- getting_involved
- askingforhelp
+ cookbook/index
+ getting_involved/index
+ help/index
advanced/index
- faq
+ faq/index
reference/index
@@ -52,7 +52,7 @@
<tr valign="top"><td width="50%"><p class="biglink">
- <a class="biglink" href="welcome_to_yt.html">
+ <a class="biglink" href="welcome/index.html">
Welcome to yt!</a><br><span class="linkdescr">
What's yt all about?
@@ -60,7 +60,7 @@
</td><td width="50%"><p class="biglink">
- <a class="biglink" href="orientation.html">
+ <a class="biglink" href="orientation/index.html">
yt Orientation</a><br><span class="linkdescr">
Quickly get up and running with yt: zero to sixty.
@@ -70,7 +70,7 @@
<tr valign="top"><td width="50%"><p class="biglink">
- <a class="biglink" href="askingforhelp.html">
+ <a class="biglink" href="help/index.html">
How to Ask for Help</a><br><span class="linkdescr">
Some guidelines on how and where to ask for help with yt
@@ -103,7 +103,7 @@
<tr valign="top"><td width="50%"><p class="biglink">
- <a class="biglink" href="interacting_with_yt.html">
+ <a class="biglink" href="interacting/index.html">
Interacting with yt</a><br><span class="linkdescr">
Different ways -- scripting, GUIs, prompts, explorers -- to explore
@@ -134,7 +134,7 @@
</td><td width="50%"><p class="biglink">
- <a class="biglink" href="getting_involved.html">
+ <a class="biglink" href="getting_involved/index.html">
Getting Involved</a><br><span class="linkdescr">
How to participate in the community, contribute code and share
@@ -149,7 +149,7 @@
<tr valign="top"><td width="50%"><p class="biglink">
- <a class="biglink" href="cookbook/recipes.html">
+ <a class="biglink" href="cookbook/index.html">
The Cookbook</a><br><span class="linkdescr">
A bunch of illustrated examples of how to do things
@@ -165,7 +165,7 @@
<tr valign="top"><td width="50%"><p class="biglink">
- <a class="biglink" href="faq.html">
+ <a class="biglink" href="faq/index.html">
FAQ</a><br><span class="linkdescr">
Frequently Asked Questions: answered for you!
https://bitbucket.org/yt_analysis/yt-doc/changeset/772a79521ddb/
changeset: 772a79521ddb
user: chummels
date: 2011-10-19 18:52:36
summary: Ordering the table of contents to match the order of the main page documents.
affected #: 1 file
diff -r b061e73269d9cceff33f2112c3f81ea9ee0420bc -r 772a79521ddb2c1d90eca99ebbfce3efd459486b source/index.rst
--- a/source/index.rst
+++ b/source/index.rst
@@ -33,16 +33,16 @@
welcome/index
orientation/index
- interacting/index
+ help/index
analyzing/index
visualizing/index
+ interacting/index
analysis_modules/index
+ advanced/index
+ getting_involved/index
cookbook/index
- getting_involved/index
- help/index
- advanced/index
+ reference/index
faq/index
- reference/index
.. raw:: html
https://bitbucket.org/yt_analysis/yt-doc/changeset/0015c83ecddf/
changeset: 0015c83ecddf
user: chummels
date: 2011-10-20 15:38:45
summary: Modifying introductory paragraph and organization structure in beginner's pages.
affected #: 5 files
diff -r 772a79521ddb2c1d90eca99ebbfce3efd459486b -r 0015c83ecddf7fdff321e57a4c16a4f02fad6091 source/faq/index.rst
--- a/source/faq/index.rst
+++ b/source/faq/index.rst
@@ -120,3 +120,50 @@
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.
+How do I cite yt?
+-----------------
+
+If you use some of the advanced features of yt and would like to cite it in a
+publication, 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 772a79521ddb2c1d90eca99ebbfce3efd459486b -r 0015c83ecddf7fdff321e57a4c16a4f02fad6091 source/orientation/index.rst
--- a/source/orientation/index.rst
+++ b/source/orientation/index.rst
@@ -1,12 +1,12 @@
.. _orientation:
-yt Orientation Session
-======================
+Quickstart Guide
+================
-This is an unofficial quickstart guide to using yt, starting from installing
-yt, describing how to make simple plots, then an introduction to Python,
-through to familiarizing yourself with how yt functions, and ending with how to
-ask questions of your data.
+This quickstart guide to using yt begins by showing you how to install yt and
+its dependencies, shows you how to make some simple plots, and then moves to
+a brief explanation of how to use python and how yt's framework fits into that.
+Finally, it addresses how to ask questions of your data using yt.
But, before getting too far in, here are a few resources that may come in
handy along the way. (These go from most-specific to least-specific!)
@@ -19,16 +19,8 @@
* `Byte of Python <http://www.swaroopch.com/notes/Python>`_
* `Dive Into Python <http://diveintopython.org>`_
-If you ever get stuck, please email the ``yt-users`` mailing list. This is not
-just so that you can get an answer to your question, but also to let the
-developers know when something is not working or could be more clear in the
-documentation. Because yt is the product of the combined efforts of several
-individuals, as well as the organic development of several person-years of
-effort, you may bring with you a new way of looking at things that could
-ultimately improve the overall user experience. There may also be easier or
-faster ways of doing things that are not immediately obvious to new users.
-
-.. rubric:: Table of Contents
+If you encounter any problems here, or anywhere in yt, please visit the
+:ref:`_asking-for-help` page to figure out a solution.
.. toctree::
:maxdepth: 2
diff -r 772a79521ddb2c1d90eca99ebbfce3efd459486b -r 0015c83ecddf7fdff321e57a4c16a4f02fad6091 source/welcome/citing.rst
--- a/source/welcome/citing.rst
+++ /dev/null
@@ -1,46 +0,0 @@
-How do I cite yt?
------------------
-
-If you use some of the advanced features of yt and would like to cite it in a
-publication, 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 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 772a79521ddb2c1d90eca99ebbfce3efd459486b -r 0015c83ecddf7fdff321e57a4c16a4f02fad6091 source/welcome/index.rst
--- a/source/welcome/index.rst
+++ b/source/welcome/index.rst
@@ -1,14 +1,13 @@
Welcome to yt
=============
-Welcome.
+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
- citing
goals_and_design
objects
derived_fields
diff -r 772a79521ddb2c1d90eca99ebbfce3efd459486b -r 0015c83ecddf7fdff321e57a4c16a4f02fad6091 source/welcome/welcome_to_yt.rst
--- a/source/welcome/welcome_to_yt.rst
+++ /dev/null
@@ -1,331 +0,0 @@
-Welcome to yt!
-==============
-
-yt is an toolkit for handling Astrophysical simulation data that provides
-analysis as well as visualization capabilities.
-
-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**.
-
-How do I cite yt?
------------------
-
-If you use some of the advanced features of yt and would like to cite it in a
-publication, 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 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}
- }
-
-.. _how-does-yt-work:
-
-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.
-
-.. _philo-objects:
-
-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.
-
-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).
-
-.. _philo-derived-fields:
-
-Derived Fields and Derived Quantities
--------------------------------------
-
-While the heart of ``yt`` is the large set of basic code, physical,
-reduced, and plot objects already developed, in a metaphorical sense,
-its 'soul' 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 AMR code stores. These may or may
-not be the so-called primitive variables of fluid dynamics (density,
-velocity, energy): they are whatever your AMR 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.
https://bitbucket.org/yt_analysis/yt-doc/changeset/c99de77cae0b/
changeset: c99de77cae0b
user: jsoishi
date: 2011-10-20 21:12:04
summary: added manual plotting to index
affected #: 1 file
diff -r 772a79521ddb2c1d90eca99ebbfce3efd459486b -r c99de77cae0bd0bc2205d78f0b3cea90d6df25b7 source/visualizing/index.rst
--- a/source/visualizing/index.rst
+++ b/source/visualizing/index.rst
@@ -6,6 +6,7 @@
plots
callbacks
+ manual_plotting
volume_rendering
image_panner
streamlines
https://bitbucket.org/yt_analysis/yt-doc/changeset/fc2b929c5573/
changeset: fc2b929c5573
user: jsoishi
date: 2011-10-20 21:13:20
summary: merged
affected #: 5 files
diff -r c99de77cae0bd0bc2205d78f0b3cea90d6df25b7 -r fc2b929c55734c3747a9ce11087a50af4f972f38 source/faq/index.rst
--- a/source/faq/index.rst
+++ b/source/faq/index.rst
@@ -120,3 +120,50 @@
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.
+How do I cite yt?
+-----------------
+
+If you use some of the advanced features of yt and would like to cite it in a
+publication, 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 c99de77cae0bd0bc2205d78f0b3cea90d6df25b7 -r fc2b929c55734c3747a9ce11087a50af4f972f38 source/orientation/index.rst
--- a/source/orientation/index.rst
+++ b/source/orientation/index.rst
@@ -1,12 +1,12 @@
.. _orientation:
-yt Orientation Session
-======================
+Quickstart Guide
+================
-This is an unofficial quickstart guide to using yt, starting from installing
-yt, describing how to make simple plots, then an introduction to Python,
-through to familiarizing yourself with how yt functions, and ending with how to
-ask questions of your data.
+This quickstart guide to using yt begins by showing you how to install yt and
+its dependencies, shows you how to make some simple plots, and then moves to
+a brief explanation of how to use python and how yt's framework fits into that.
+Finally, it addresses how to ask questions of your data using yt.
But, before getting too far in, here are a few resources that may come in
handy along the way. (These go from most-specific to least-specific!)
@@ -19,16 +19,8 @@
* `Byte of Python <http://www.swaroopch.com/notes/Python>`_
* `Dive Into Python <http://diveintopython.org>`_
-If you ever get stuck, please email the ``yt-users`` mailing list. This is not
-just so that you can get an answer to your question, but also to let the
-developers know when something is not working or could be more clear in the
-documentation. Because yt is the product of the combined efforts of several
-individuals, as well as the organic development of several person-years of
-effort, you may bring with you a new way of looking at things that could
-ultimately improve the overall user experience. There may also be easier or
-faster ways of doing things that are not immediately obvious to new users.
-
-.. rubric:: Table of Contents
+If you encounter any problems here, or anywhere in yt, please visit the
+:ref:`_asking-for-help` page to figure out a solution.
.. toctree::
:maxdepth: 2
diff -r c99de77cae0bd0bc2205d78f0b3cea90d6df25b7 -r fc2b929c55734c3747a9ce11087a50af4f972f38 source/welcome/citing.rst
--- a/source/welcome/citing.rst
+++ /dev/null
@@ -1,46 +0,0 @@
-How do I cite yt?
------------------
-
-If you use some of the advanced features of yt and would like to cite it in a
-publication, 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 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 c99de77cae0bd0bc2205d78f0b3cea90d6df25b7 -r fc2b929c55734c3747a9ce11087a50af4f972f38 source/welcome/index.rst
--- a/source/welcome/index.rst
+++ b/source/welcome/index.rst
@@ -1,14 +1,13 @@
Welcome to yt
=============
-Welcome.
+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
- citing
goals_and_design
objects
derived_fields
diff -r c99de77cae0bd0bc2205d78f0b3cea90d6df25b7 -r fc2b929c55734c3747a9ce11087a50af4f972f38 source/welcome/welcome_to_yt.rst
--- a/source/welcome/welcome_to_yt.rst
+++ /dev/null
@@ -1,331 +0,0 @@
-Welcome to yt!
-==============
-
-yt is an toolkit for handling Astrophysical simulation data that provides
-analysis as well as visualization capabilities.
-
-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**.
-
-How do I cite yt?
------------------
-
-If you use some of the advanced features of yt and would like to cite it in a
-publication, 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 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}
- }
-
-.. _how-does-yt-work:
-
-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.
-
-.. _philo-objects:
-
-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.
-
-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).
-
-.. _philo-derived-fields:
-
-Derived Fields and Derived Quantities
--------------------------------------
-
-While the heart of ``yt`` is the large set of basic code, physical,
-reduced, and plot objects already developed, in a metaphorical sense,
-its 'soul' 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 AMR code stores. These may or may
-not be the so-called primitive variables of fluid dynamics (density,
-velocity, energy): they are whatever your AMR 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.
https://bitbucket.org/yt_analysis/yt-doc/changeset/ae431055ab4b/
changeset: ae431055ab4b
user: MatthewTurk
date: 2011-11-22 21:58:19
summary: Merging changes from JSO's branch
affected #: 7 files
diff -r fc2b929c55734c3747a9ce11087a50af4f972f38 -r ae431055ab4b6795e3d7b607ee4f83ae9dec4921 source/advanced/creating_derived_quantities.rst
--- a/source/advanced/creating_derived_quantities.rst
+++ b/source/advanced/creating_derived_quantities.rst
@@ -1,3 +1,5 @@
+.. _creating_derived_quantities:
+
Creating Derived Quantities
---------------------------
diff -r fc2b929c55734c3747a9ce11087a50af4f972f38 -r ae431055ab4b6795e3d7b607ee4f83ae9dec4921 source/advanced/parallel_computation.rst
--- a/source/advanced/parallel_computation.rst
+++ b/source/advanced/parallel_computation.rst
@@ -16,27 +16,33 @@
Currently, YT is able to
perform the following actions in parallel:
- * Projections
- * Slices
- * Cutting planes (oblique slices)
- * Derived Quantities (total mass, angular momentum, etc)
- * 1-, 2- and 3-D profiles
- * Halo finding
- * Merger tree
- * Two point functions
+ * Projections (:ref:`how-to-make-projections`)
+ * Slices (:ref:`how-to-make-slices`)
+ * Cutting planes (oblique slices) (:ref:`how-to-make-oblique-slices`)
+ * Derived Quantities (total mass, angular momentum, etc) (:ref:`creating_derived_quantities`,
+ :ref:`derived-quantities`)
+ * 1-, 2-, and 3-D profiles (:ref:`generating-profiles-and-histograms`)
+ * Halo finding (:ref:`halo_finding`)
+ * Merger tree (:ref:`merger_tree`)
+ * Two point functions (:ref:`two_point_functions`)
+ * Volume rendering (:ref:`volume_rendering`)
+ * Radial column density
+ * Isocontours & flux calculations
This list covers just about every action YT can take! Additionally, almost all
scripts will benefit from parallelization without any modification. The goal
of Parallel-YT has been to retain API compatibility and abstract all
-parallelism.
+parallelism.
Setting Up Parallel YT
----------------------
-To run scripts in parallel, you must first install `mpi4py <http://code.google.com/p/mpi4py>`_.
-Instructions for doing so are provided on the MPI4Py website. Once that has
+To run scripts in parallel, you must first install
+`mpi4py <http://code.google.com/p/mpi4py>`_.
+Instructions for doing so are provided on the mpipy website. Once that has
been accomplished, you're all done! You just need to launch your scripts with
-``mpirun`` and signal to YT that you want to run them in parallel.
+``mpirun`` (or equivalent) and signal to YT
+that you want to run them in parallel.
For instance, the following script, which we'll save as ``my_script.py``:
@@ -62,7 +68,7 @@
.. warning:: If you manually interact with the filesystem, not through YT, you
will have to ensure that you only execute your functions on the root
- processor. You can do this with the function :func:only_on_root.
+ processor. You can do this with the function :func:`only_on_root`.
It's important to note that all of the processes listed in `capabilities` work
-- and no additional work is necessary to parallelize those processes.
@@ -89,9 +95,294 @@
of parallelism is overall less efficient than grid-based parallelism, but it
has been shown to obtain good results overall.
+The following operations use spatial decomposition:
+
+ * Projections
+ * Slices
+ * Cutting planes
+ * Halo finding
+ * Merger tree
+ * Two point functions
+ * Volume rendering
+ * Radial column density
+
Grid Decomposition
++++++++++++++++++
The alternative to spatial decomposition is a simple round-robin of the grids.
This process alows YT to pool data access to a given Enzo data file, which
ultimately results in faster read times and better parallelism.
+
+The following operations use grid decomposition:
+
+ * Derived Quantities
+ * 1-, 2-, and 3-D profiles
+ * Isocontours & flux calculations
+
+Object-Based
+++++++++++++
+
+In a fashion similar to grid decomposition, computation can be parallelized
+over objects. This is especially useful for
+`embarrasingly parallel <http://en.wikipedia.org/wiki/Embarrassingly_parallel>`_
+tasks where the items to be worked on can be split into seperate chunks and
+saved to a list. The list is then split up and each MPI task performs parts of
+it independently.
+
+Parallelizing Your Analysis
+---------------------------
+
+It is easy within YT to parallelize a list of tasks, as long as those tasks
+are independent of one another.
+Using object-based parallelism, the function :func:`parallel_objects` will
+automatically split up a list of tasks over the specified number of processors
+(or cores).
+Please see this heavily-commented example:
+
+.. code-block:: python
+
+ # This is necessary to prevent a race-condition where each copy of
+ # yt attempts to save information about datasets to the same file on disk,
+ # simultaneously. This will be fixed, eventually...
+ from yt.config import ytcfg; ytcfg["yt","serialize"] = "False"
+ # As always...
+ from yt.mods import *
+ import glob
+
+ # The number 4, below, is the number of processes to parallelize over, which
+ # is generally equal to the number of MPI tasks the job is launched with.
+ num_procs = 4
+
+ # fns is a list of all Enzo hierarchy files in directories one level down.
+ fns = glob.glob("*/*.hierarchy")
+ fns.sort()
+ # This dict will store information collected in the loop, below.
+ # Inside the loop each task will have a local copy of the dict, but
+ # the dict will be combined once the loop finishes.
+ my_storage = {}
+ # In this example, because the storage option is used in the
+ # parallel_objects function, the loop yields a tuple, which gets used
+ # as (sto, fn) inside the loop.
+ # In the loop, sto is essentially my_storage, but a local copy of it.
+ # If data does not need to be combined after the loop is done, the line
+ # would look like:
+ # for fn in parallel_objects(fns, num_procs):
+ for sto, fn in parallel_objects(fns, num_procs, storage = my_storage):
+ # Open a data file, remembering that fn is different on each task.
+ pf = load(fn)
+ dd = pf.h.all_data()
+ # This copies fn and the min/max of density to the local copy of
+ # my_storage
+ sto.result_id = fn
+ sto.result = dd.quantities["Extrema"]("Density")
+ # Makes and saves a plot of the gas density.
+ pc = PlotCollection(pf, [0.5, 0.5, 0.5])
+ pc.add_projection("Density", 0)
+ pc.save()
+ # At this point, as the loop exits, the local copies of my_storage are
+ # combined such that all tasks now have an identical and full version of
+ # my_storage. Until this point, each task is unaware of what the other
+ # tasks have produced.
+ # Below, the values in my_storage are printed by only one task. The other
+ # tasks do nothing.
+ if ytcfg.getint("yt", "__topcomm_parallel_rank") == 0:
+ for fn, vals in sorted(my_storage.items()):
+ print fn, vals
+
+This example above can be modified to loop over anything that can be saved to
+a Python list: halos, data files, arrays, and more.
+
+Parallel Performance, Resources, and Tuning
+-------------------------------------------
+
+Optimizing parallel jobs in YT is difficult; there are many parameters
+that affect how well and quickly the job runs.
+In many cases, the only way to find out what the minimum (or optimal)
+number of processors is, or amount of memory needed, is through trial and error.
+However, this section will attempt to provide some insight into what are good
+starting values for a given parallel task.
+
+Grid Decomposition
+++++++++++++++++++
+
+In general, these types of parallel calculations scale very well with number of
+processors.
+They are also fairly memory-conservative.
+The two limiting factors is therefore the number of grids in the dataset,
+and the speed of the disk the data is stored on.
+There is no point in running a parallel job of this kind with more processors
+than grids, because the extra processors will do absolutely nothing, and will
+in fact probably just serve to slow down the whole calculation due to the extra
+overhead.
+The speed of the disk is also a consideration - if it is not a high-end parallel
+file system, adding more tasks will not speed up the calculation if the disk
+is already swamped with activity.
+
+The best advice for these sort of calculations is to run
+with just a few processors and go from there, seeing if it the runtime
+improves noticeably.
+
+**Projections, Slices, and Cutting Planes**
+
+Projections, slices and cutting planes are the most common methods of creating
+two-dimensional representations of data. All three have been parallelized in a
+grid-based fashion.
+
+ * Projections: projections are parallelized utilizing a quad-tree approach.
+ Data is loaded for each processor, typically by a process that consolidates
+ open/close/read operations, and each grid is then iterated over and cells
+ are deposited into a data structure that stores values correpsonding to
+ positions in the two-dimensional plane. This provides excellent load
+ balancing, and in serial is quite fast. However, as of yt 2.3, the
+ operation by which quadtrees are joined across processors scales poorly;
+ while memory consumption scales well, the time to completion does not. As
+ such, projections can often be done very fast when operating only on a single
+ processor! The quadtree algorithm can be used inline (and, indeed, it is
+ for this reason that it is slow.) It is recommended that you attempt to
+ project in serial before projecting in parallel; even for the very largest
+ datasets (Enzo 1024^3 root grid with 7 levels of refinement) in the absence
+ of IO the quadtree algorithm takes only three minutes or so on a decent
+ processor.
+ * Slices: to generate a slice, grids that intersect a given slice are iterated
+ over and their finest-resolution cells are deposited. The grids are
+ decomposed via standard load balancing. While this operation is parallel,
+ **it is almost never necessary to slice a dataset in parallel**, as all data is
+ loaded on demand anyway. The slice operation has been parallelized so as to
+ enable slicing when running *in situ*.
+ * Cutting planes: cutting planes are parallelized exactly as slices are.
+ However, in contrast to slices, because the data-selection operation can be
+ much more time consuming, cutting planes often benefit from parallelism.
+
+Object-Based
+++++++++++++
+
+Like grid decomposition, it does not help to run with more processors than the
+number of objects to be iterated over.
+There is also the matter of the kind of work being done on each object, and
+whether it is disk-intensive, cpu-intensive, or memory-intensive.
+It is up to the user to figure out what limits the performance of their script,
+and use the correct amount of resources, accordingly.
+
+Disk-intensive jobs are limited by the speed of the file system, as above,
+and extra processors beyond its capability are likely counter-productive.
+It may require some testing or research (e.g. supercomputer documentation)
+to find out what the file system is capable of.
+
+If it is cpu-intensive, it's best to use as many processors as possible
+and practical.
+
+For a memory-intensive job, each processor needs to be able to allocate enough
+memory, which may mean using fewer than the maximum number of tasks per compute
+node, and increasing the number of nodes.
+The memory used per processor should be calculated, compared to the memory
+on each compute node, which dictates how many tasks per node.
+After that, the number of processors used overall is dictated by the
+disk system or CPU-intensity of the job.
+
+
+Domain Decomposition
+++++++++++++++++++++
+
+The various types of analysis that utilize domain decomposition use them in
+different enough ways that they are be discussed separately.
+
+**Halo-Finding**
+
+Halo finding, along with the merger tree that uses halo finding, operates
+on the particles in the volume, and is therefore mostly grid-agnostic.
+Generally, the biggest concern for halo finding is the amount of memory needed.
+There is subtle art in estimating the amount of memory needed for halo finding,
+but a rule of thumb is that Parallel HOP (:func:`parallelHF`) is the most
+memory-intensive, followed by plain HOP (:func:`HaloFinder`),
+with Friends of Friends (:func:`FOFHaloFinder`) being
+the most memory-conservative.
+It has been found that :func:`parallelHF` needs roughly
+1 MB of memory per 5,000
+particles, although recent work has improved this and the memory requirement
+is now smaller than this. But this is a good starting point for beginning to
+calculate the memory required for halo-finding.
+
+**Two point functions**
+
+Please see :ref:`tpf_strategies` for more details.
+
+**Volume Rendering**
+
+The simplest way to think about volume rendering, and the radial column density
+module that uses it, is that it load-balances over the grids in the dataset.
+Each processor is given roughly the same sized volume to operate on.
+In practice, there are just a few things to keep in mind when doing volume
+rendering.
+First, it only uses a power of two number of processors.
+If the job is run with 100 processors, only 64 of them will actually do anything.
+Second, the absolute maximum number of processors is the number of grids.
+But in order to keep work distributed evenly, typically the number of processors
+should be no greater than one-eighth or one-quarter the number of processors
+that were used to produce the dataset.
+
+Additional Tips
+---------------
+
+ * Don't be afraid to change how a parallel job is run. Change the
+ number of processors, or memory allocated, and see if things work better
+ or worse. After all, it's just a computer, it doesn't pass moral judgment!
+
+ * Similarly, human time is more valuable than computer time. Try increasing
+ the number of processors, and see if the runtime drops significantly.
+ There will be a sweet spot between speed of run and the waiting time in
+ the job scheduler queue; it may be worth trying to find it.
+
+ * It is impossible to tune a parallel operation without understanding what's
+ going on. Read the documentation, look at the underlying code, or talk to
+ other yt users. Get informed!
+
+ * Sometimes it is difficult to know if a job is cpu, memory, or disk
+ intensive, especially if the parallel job utilizes several of the kinds of
+ parallelism discussed above. In this case, it may be worthwhile to put
+ some simple timers in your script (as below) around different parts.
+
+ .. code-block:: python
+
+ from yt.mods import *
+ import time
+
+ pf = load("DD0152")
+ t0 = time.time()
+ bigstuff, hugestuff = StuffFinder(pf)
+ BigHugeStuffParallelFunction(pf, bigstuff, hugestuff)
+ t1 = time.time()
+ for i in range(1000000):
+ tinystuff, ministuff = GetTinyMiniStuffOffDisk("in%06d.txt" % i)
+ array = TinyTeensyParallelFunction(pf, tinystuff, ministuff)
+ SaveTinyMiniStuffToDisk("out%06d.txt" % i, array)
+ t2 = time.time()
+
+ if ytcfg.getint("yt", "__topcomm_parallel_rank") == 0:
+ print "BigStuff took %.5e sec, TinyStuff took %.5e sec" % (t1 - t0, t2 - t1)
+
+ * Remember that if the script handles disk IO explicitly, and does not use
+ a built-in yt function to write data to disk,
+ care must be taken to
+ avoid `race-conditions <http://en.wikipedia.org/wiki/Race_conditions>`_.
+ Be explicit about which MPI task writes to disk using a construction
+ something like this:
+
+ .. code-block:: python
+
+ if ytcfg.getint("yt", "__topcomm_parallel_rank") == 0:
+ file = open("out.txt", "w")
+ file.write(stuff)
+ file.close()
+
+ * Many supercomputers allow users to ssh into the nodes that their job is
+ running on.
+ Many job schedulers send the names of the nodes that are
+ used in the notification emails, or a command like ``qstat -f NNNN``, where
+ ``NNNN`` is the job ID, will also show this information.
+ By ssh-ing into nodes, the memory usage of each task can be viewed in
+ real-time as the job runs (using ``top``, for example),
+ and can give valuable feedback about the
+ resources the task requires.
+
+
+
\ No newline at end of file
diff -r fc2b929c55734c3747a9ce11087a50af4f972f38 -r ae431055ab4b6795e3d7b607ee4f83ae9dec4921 source/analysis_modules/merger_tree.rst
--- a/source/analysis_modules/merger_tree.rst
+++ b/source/analysis_modules/merger_tree.rst
@@ -739,8 +739,8 @@
files = []
start = 100
finish = 116
- for i in range(start+1 - finish):
- files.append('/path/to/snapshots/DD%04d/data%04d' % (i+finish, i+finish))
+ for i in range(start, finish + 1):
+ files.append('/path/to/snapshots/DD%04d/data%04d' % (i, i))
my_database = '/path/to/database/halos.db'
diff -r fc2b929c55734c3747a9ce11087a50af4f972f38 -r ae431055ab4b6795e3d7b607ee4f83ae9dec4921 source/analysis_modules/running_halofinder.rst
--- a/source/analysis_modules/running_halofinder.rst
+++ b/source/analysis_modules/running_halofinder.rst
@@ -391,6 +391,12 @@
with this option turned on. Not all haloes are changed between runs. This is
due to the way merging happens in HOP - pre-merging destroys the global
determinacy of halo merging. Default=True.
+ * ``tree``, string: There are two kD-trees that may be used as part of the
+ halo-finding process. The Fortran ("F") one is (presently) faster, but requires
+ more memory. One based on `scipy.spatial
+ <http://docs.scipy.org/doc/scipy/reference/spatial.html>`_ utilizes
+ Cython ("C") and is (presently) slower, but is more memory efficient.
+ Default = "F".
All the same halo data can be accessed from Parallel HOP haloes as with the other halo finders.
However, when running in parallel, there are some
diff -r fc2b929c55734c3747a9ce11087a50af4f972f38 -r ae431055ab4b6795e3d7b607ee4f83ae9dec4921 source/analysis_modules/two_point_functions.rst
--- a/source/analysis_modules/two_point_functions.rst
+++ b/source/analysis_modules/two_point_functions.rst
@@ -570,6 +570,8 @@
If there were other output fields, they would be named
``bin_edges_01_outfield1``, ``bin_edges_02_outfield2`` respectively.
+.. _tpf_strategies
+
Strategies for Computational Efficiency
---------------------------------------
diff -r fc2b929c55734c3747a9ce11087a50af4f972f38 -r ae431055ab4b6795e3d7b607ee4f83ae9dec4921 source/analyzing/objects.rst
--- a/source/analyzing/objects.rst
+++ b/source/analyzing/objects.rst
@@ -94,6 +94,38 @@
.. include:: _obj_docstrings.inc
+.. _boolean_data_objects
+
+Boolean Data Objects
+--------------------
+
+A special type of data object is the *boolean* data object.
+It works only on three-dimensional objects.
+It is built by relating already existing data objects with boolean operators.
+The boolean logic may be nested using parentheses, and
+it supports the standard "AND", "OR", and "NOT" operators:
+
+* **"AND"** When two data objects are related with an "AND", the combined
+ data object is the volume of the simulation covered by both objects, and
+ not by just a single object.
+* **"OR"** When two data objects are related with an "OR", the combined
+ data object is the volume(s) of the simulation covered by either of the
+ objects.
+ For example, this may be used to combine disjoint objects into one.
+* **"NOT"** When two data objects are related with a "NOT", the combined
+ data object is the volume of the first object that the second does not
+ cover.
+ For example, this may be used to cut out part(s) of the first data object
+ utilizing the second data object.
+* **"(" or ")"** Nested logic is surrounded by parentheses. The order of
+ operations is such that the boolean logic is evaluated inside the
+ inner-most parentheses, first, then goes upwards.
+ The logic is read left-to-right at all levels (crucial for the "NOT"
+ operator).
+
+Please see the :ref:`cookbook` for some examples of how to use the boolean
+data object.
+
.. _derived-quantities:
Derived Quantities
diff -r fc2b929c55734c3747a9ce11087a50af4f972f38 -r ae431055ab4b6795e3d7b607ee4f83ae9dec4921 source/reference/configuration.rst
--- a/source/reference/configuration.rst
+++ b/source/reference/configuration.rst
@@ -67,7 +67,7 @@
in ``$HOME/.yt/`` in which parameter files will be tracked.
* ``pluginfilename`` (default ``'my_plugins.py'``) The name of our plugin file.
* ``serialize`` (default: ``'True'``): Are we allowed to write to the ``.yt`` file?
-* ``storeparameterfiles`` (default: ``'True'``): Should we track parameter files
+* ``storeparameterfiles`` (default: ``'False'``): Should we track parameter files
between sessions?
* ``suppressStreamLogging`` (default: ``'False'``): If true, execution mode will be
quiet.
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