[yt-svn] commit/yt-doc: 5 new changesets
Bitbucket
commits-noreply at bitbucket.org
Tue Jul 24 11:15:58 PDT 2012
5 new commits in yt-doc:
https://bitbucket.org/yt_analysis/yt-doc/changeset/b3bba310f89c/
changeset: b3bba310f89c
user: MatthewTurk
date: 2012-07-24 05:07:09
summary: Adding two items to the TOC; the workshop one pollutes it a bit with a second
level, but the reason one is necessary.
affected #: 2 files
diff -r 3eaca37968de2b33efd75ed4867172260a29c843 -r b3bba310f89c29be394e4364c129a373b23c034c source/advanced/index.rst
--- a/source/advanced/index.rst
+++ b/source/advanced/index.rst
@@ -16,3 +16,4 @@
debugdrive
external_analysis
developing
+ reason_architecture
diff -r 3eaca37968de2b33efd75ed4867172260a29c843 -r b3bba310f89c29be394e4364c129a373b23c034c source/index.rst
--- a/source/index.rst
+++ b/source/index.rst
@@ -107,6 +107,7 @@
welcome/index
orientation/index
+ workshop
help/index
interacting/index
configuration
https://bitbucket.org/yt_analysis/yt-doc/changeset/5e05fd6fc8ab/
changeset: 5e05fd6fc8ab
user: MatthewTurk
date: 2012-07-24 05:57:33
summary: Splitting up the configuration options and adding info about configuring from
the command line.
affected #: 1 file
diff -r b3bba310f89c29be394e4364c129a373b23c034c -r 5e05fd6fc8ab232082be840d87ecb337a302202b source/configuration.rst
--- a/source/configuration.rst
+++ b/source/configuration.rst
@@ -3,6 +3,9 @@
Configuration File
==================
+Configuration File Format
+-------------------------
+
yt will look for and recognize the file ``$HOME/.yt/config`` as a configuration
file, containing several options that can be modified and adjusted to control
runtime behavior. For example, a sample ``$HOME/.yt/config`` file could look
@@ -18,6 +21,9 @@
much more voluminous output from yt. Additionally, it increases the number of
parameter files tracked between instantiations of yt.
+Configuration Options At Runtime
+--------------------------------
+
In addition to setting parameters in the configuration file itself, you can set
them at runtime.
@@ -43,6 +49,31 @@
This has the same effect as setting ``loglevel = 1`` in the configuration file.
+Setting Configuration On the Command Line
+-----------------------------------------
+
+Options can also be set directly on the command line by specifying a
+command-line option. For instance, if you are running the script
+``my_script.py`` you can specify a configuration option with the ``--config``
+argument. As an example, to lower the log level (thus making it more verbose)
+you can specify:
+
+.. code-block::
+
+ $ python2.7 my_script.py --config loglevel=1
+
+Any configuration option specific to yt can be specified in this manner. One
+common configuration option would be to disable serialization:
+
+.. code-block::
+
+ $ python2.7 my_script.py --config serialize=False
+
+This way projections are always re-created.
+
+Available Configuration Options
+-------------------------------
+
The following parameters are available.
* ``__parallel`` (default: ``'False'``): Internal parameter governing whether this
https://bitbucket.org/yt_analysis/yt-doc/changeset/42d93ab7d2c7/
changeset: 42d93ab7d2c7
user: MatthewTurk
date: 2012-07-24 07:20:06
summary: Adding a few things to the .hgignore and adding low-level data inspection docs.
affected #: 3 files
diff -r 5e05fd6fc8ab232082be840d87ecb337a302202b -r 42d93ab7d2c756a5cf477c4e870cb619fe35a1ed .hgignore
--- a/.hgignore
+++ b/.hgignore
@@ -2,6 +2,7 @@
*.pyc
.*.swp
build/*
-source/reference/api/generated/*
+source/api/generated/*
+_temp/*
**/.DS_Store
RD0005-mine/*
diff -r 5e05fd6fc8ab232082be840d87ecb337a302202b -r 42d93ab7d2c756a5cf477c4e870cb619fe35a1ed source/analyzing/index.rst
--- a/source/analyzing/index.rst
+++ b/source/analyzing/index.rst
@@ -10,3 +10,4 @@
creating_derived_fields
generating_processed_data
time_series_analysis
+ low_level_inspection
diff -r 5e05fd6fc8ab232082be840d87ecb337a302202b -r 42d93ab7d2c756a5cf477c4e870cb619fe35a1ed source/analyzing/low_level_inspection.rst
--- /dev/null
+++ b/source/analyzing/low_level_inspection.rst
@@ -0,0 +1,117 @@
+Low-Level Data Inspection
+=========================
+
+yt can not only provide high-level access to data, such as through slices,
+projections, object queries and the like, but it can also provide low-level
+access to data.
+
+.. note:: This section is tuned for patch- or block-based simulations. Future
+ versions of yt will enable more direct access to particle and oct
+ based simulations. For now, these are represented as patches, with
+ the attendant properties.
+
+For a more basic introduction, see :ref:`first_steps` and more specifically
+:ref:`grid_inspection`.
+
+Examining Grid Hierarchies
+--------------------------
+
+yt organizes grids in a hierarchical fashion; a coarser grid that contains (or
+overlaps with) a finer grid is referred to as its parent. yt organizes these
+only a single level of refinement at a time. To access grids, the ``grids``
+attribute on a :class:`~yt.data_objects.hierarchy.AMRHierarchy` object. (For
+fast operations, a number of additional arrays prefixed with ``grid`` are also
+available, such as ``grid_left_edges`` and so on.) This returns an instance of
+:class:`~yt.data_objects.grid_patch.AMRGridPatch`, which can be queried for
+either data or hierarchy information.
+
+The :class:`~yt.data_objects.grid_patch.AMRGridPatch` object itself provides
+the following attributes:
+
+ * ``Children``: a list of grids contained within this one, of one higher level
+ of refinement
+ * ``Parent``: a single object or a list of objects this grid is contained
+ within, one level of refinement coarser
+ * ``child_mask``: a mask of 0's and 1's, representing where no finer data is
+ available in refined grids (1) or where this grid is covered by finer regions
+ (0). Note that to get back the final data contained within a grid, one can
+ multiple a field by this attribute.
+ * ``child_indices``: a mask of booleans, where False indicates no finer data
+ is available. This is essentially the inverse of ``child_mask``.
+ * ``child_index_mask``: a mask of indices into the ``pf.h.grids`` array of the
+ child grids.
+ * ``LeftEdge``: the left edge, in native code coordinates, of this grid
+ * ``RightEdge``: the right edge, in native code coordinates, of this grid
+ * ``dds``: the width of a cell in this grid
+ * ``id``: the id (not necessarily the index) of this grid. Defined such that
+ subtracting the property ``_id_offset`` gives the index into ``pf.h.grids``.
+ * ``NumberOfParticles``: the number of particles in this grid
+ * ``OverlappingSiblings``: a list of sibling grids that this grid overlaps
+ with. Likely only defined for Octree-based codes.
+
+In addition, the method
+:meth:`~yt.data_objects.grid_patch.AMRGridPatch.get_global_startindex` can be
+used to get the integer coordinates of the upper left edge. These integer
+coordinates are defined with respect to the current level; this means that they
+are the offset of the left edge, with respect to the left edge of the domain,
+divided by the local ``dds``.
+
+To traverse a series of grids, this type of construction can be used:
+
+.. code-block:: python
+
+ g = pf.h.grids[1043]
+ g2 = g.Children[1].Children[0]
+ print g2.LeftEdge
+
+Examining Grid Data
+-------------------
+
+Once you have identified a grid you wish to inspect, there are two ways to
+examine data. You can either ask the grid to read the data and pass it to you
+as normal, or you can manually intercept the data from the IO handler and
+examine it before it has been unit converted. This allows for much more raw
+data inspection.
+
+To access data that has been read in the typical fashion and unit-converted as
+normal, you can access the grid as you would a normal object:
+
+.. code-block:: python
+
+ g = pf.h.grids[1043]
+ print g["Density"]
+ print g["Density"].min()
+
+To access the raw data, you have to call the IO handler from the hierarchy
+instead. This is somewhat more low-level.
+
+.. code-block::
+
+ g = pf.h.grids[1043]
+ rho = pf.h.io.pop(g, "Density")
+
+This field will be the raw data found in the file.
+
+Finding Data at Fixed Points
+----------------------------
+
+One of the most common questions asked of data is, what is the value *at this
+specific point*. While there are several ways to find out the answer to this
+question, a few helper routines are provided as well. To identify the
+finest-resolution (i.e., most canonical) data at a given point, use
+:meth:`~yt.data_objects.hierarchy.AMRHierarchy.find_field_value_at_point`.
+This accepts a position (in coordinates of the domain) and returns the field
+values for one or multiple fields.
+
+To identify all the grids that intersect a given point, the function
+:meth:`~yt.data_objects.hierarchy.AMRHierarchy.find_point` will return indices
+and objects that correspond to it. For instance:
+
+.. code-block::
+
+ gs, gi = pf.h.find_point((0.5, 0.6, 0.9))
+ for g in gs:
+ print g.Level, g.LeftEdge, g.RightEdge
+
+Note that this doesn't just return the canonical output, but also all of the
+parent grids that overlap with that point.
https://bitbucket.org/yt_analysis/yt-doc/changeset/d90bb3763f8a/
changeset: d90bb3763f8a
user: MatthewTurk
date: 2012-07-24 07:25:23
summary: Fixing a few build errors.
affected #: 2 files
diff -r 42d93ab7d2c756a5cf477c4e870cb619fe35a1ed -r d90bb3763f8a050f9134b8d62107976b0e1fa23e source/analyzing/low_level_inspection.rst
--- a/source/analyzing/low_level_inspection.rst
+++ b/source/analyzing/low_level_inspection.rst
@@ -85,7 +85,7 @@
To access the raw data, you have to call the IO handler from the hierarchy
instead. This is somewhat more low-level.
-.. code-block::
+.. code-block:: python
g = pf.h.grids[1043]
rho = pf.h.io.pop(g, "Density")
@@ -107,7 +107,7 @@
:meth:`~yt.data_objects.hierarchy.AMRHierarchy.find_point` will return indices
and objects that correspond to it. For instance:
-.. code-block::
+.. code-block:: python
gs, gi = pf.h.find_point((0.5, 0.6, 0.9))
for g in gs:
diff -r 42d93ab7d2c756a5cf477c4e870cb619fe35a1ed -r d90bb3763f8a050f9134b8d62107976b0e1fa23e source/orientation/first_steps.rst
--- a/source/orientation/first_steps.rst
+++ b/source/orientation/first_steps.rst
@@ -1,3 +1,5 @@
+.. _first_steps:
+
First Steps with yt
-------------------
@@ -85,6 +87,8 @@
>>> value, location = pf.h.find_max("Density")
+.. _grid_inspection:
+
Grid Inspection
+++++++++++++++
https://bitbucket.org/yt_analysis/yt-doc/changeset/99a4d8f41eb2/
changeset: 99a4d8f41eb2
user: ngoldbaum
date: 2012-07-24 20:15:57
summary: Merged in MatthewTurk/yt-doc (pull request #38)
affected #: 7 files
diff -r b0b01f8d54244542cc60b1e5928d6e93298b2c0d -r 99a4d8f41eb2678aaaca741e1366b783da100f7c .hgignore
--- a/.hgignore
+++ b/.hgignore
@@ -2,6 +2,7 @@
*.pyc
.*.swp
build/*
-source/reference/api/generated/*
+source/api/generated/*
+_temp/*
**/.DS_Store
RD0005-mine/*
diff -r b0b01f8d54244542cc60b1e5928d6e93298b2c0d -r 99a4d8f41eb2678aaaca741e1366b783da100f7c source/advanced/index.rst
--- a/source/advanced/index.rst
+++ b/source/advanced/index.rst
@@ -16,3 +16,4 @@
debugdrive
external_analysis
developing
+ reason_architecture
diff -r b0b01f8d54244542cc60b1e5928d6e93298b2c0d -r 99a4d8f41eb2678aaaca741e1366b783da100f7c source/analyzing/index.rst
--- a/source/analyzing/index.rst
+++ b/source/analyzing/index.rst
@@ -10,3 +10,4 @@
creating_derived_fields
generating_processed_data
time_series_analysis
+ low_level_inspection
diff -r b0b01f8d54244542cc60b1e5928d6e93298b2c0d -r 99a4d8f41eb2678aaaca741e1366b783da100f7c source/analyzing/low_level_inspection.rst
--- /dev/null
+++ b/source/analyzing/low_level_inspection.rst
@@ -0,0 +1,117 @@
+Low-Level Data Inspection
+=========================
+
+yt can not only provide high-level access to data, such as through slices,
+projections, object queries and the like, but it can also provide low-level
+access to data.
+
+.. note:: This section is tuned for patch- or block-based simulations. Future
+ versions of yt will enable more direct access to particle and oct
+ based simulations. For now, these are represented as patches, with
+ the attendant properties.
+
+For a more basic introduction, see :ref:`first_steps` and more specifically
+:ref:`grid_inspection`.
+
+Examining Grid Hierarchies
+--------------------------
+
+yt organizes grids in a hierarchical fashion; a coarser grid that contains (or
+overlaps with) a finer grid is referred to as its parent. yt organizes these
+only a single level of refinement at a time. To access grids, the ``grids``
+attribute on a :class:`~yt.data_objects.hierarchy.AMRHierarchy` object. (For
+fast operations, a number of additional arrays prefixed with ``grid`` are also
+available, such as ``grid_left_edges`` and so on.) This returns an instance of
+:class:`~yt.data_objects.grid_patch.AMRGridPatch`, which can be queried for
+either data or hierarchy information.
+
+The :class:`~yt.data_objects.grid_patch.AMRGridPatch` object itself provides
+the following attributes:
+
+ * ``Children``: a list of grids contained within this one, of one higher level
+ of refinement
+ * ``Parent``: a single object or a list of objects this grid is contained
+ within, one level of refinement coarser
+ * ``child_mask``: a mask of 0's and 1's, representing where no finer data is
+ available in refined grids (1) or where this grid is covered by finer regions
+ (0). Note that to get back the final data contained within a grid, one can
+ multiple a field by this attribute.
+ * ``child_indices``: a mask of booleans, where False indicates no finer data
+ is available. This is essentially the inverse of ``child_mask``.
+ * ``child_index_mask``: a mask of indices into the ``pf.h.grids`` array of the
+ child grids.
+ * ``LeftEdge``: the left edge, in native code coordinates, of this grid
+ * ``RightEdge``: the right edge, in native code coordinates, of this grid
+ * ``dds``: the width of a cell in this grid
+ * ``id``: the id (not necessarily the index) of this grid. Defined such that
+ subtracting the property ``_id_offset`` gives the index into ``pf.h.grids``.
+ * ``NumberOfParticles``: the number of particles in this grid
+ * ``OverlappingSiblings``: a list of sibling grids that this grid overlaps
+ with. Likely only defined for Octree-based codes.
+
+In addition, the method
+:meth:`~yt.data_objects.grid_patch.AMRGridPatch.get_global_startindex` can be
+used to get the integer coordinates of the upper left edge. These integer
+coordinates are defined with respect to the current level; this means that they
+are the offset of the left edge, with respect to the left edge of the domain,
+divided by the local ``dds``.
+
+To traverse a series of grids, this type of construction can be used:
+
+.. code-block:: python
+
+ g = pf.h.grids[1043]
+ g2 = g.Children[1].Children[0]
+ print g2.LeftEdge
+
+Examining Grid Data
+-------------------
+
+Once you have identified a grid you wish to inspect, there are two ways to
+examine data. You can either ask the grid to read the data and pass it to you
+as normal, or you can manually intercept the data from the IO handler and
+examine it before it has been unit converted. This allows for much more raw
+data inspection.
+
+To access data that has been read in the typical fashion and unit-converted as
+normal, you can access the grid as you would a normal object:
+
+.. code-block:: python
+
+ g = pf.h.grids[1043]
+ print g["Density"]
+ print g["Density"].min()
+
+To access the raw data, you have to call the IO handler from the hierarchy
+instead. This is somewhat more low-level.
+
+.. code-block:: python
+
+ g = pf.h.grids[1043]
+ rho = pf.h.io.pop(g, "Density")
+
+This field will be the raw data found in the file.
+
+Finding Data at Fixed Points
+----------------------------
+
+One of the most common questions asked of data is, what is the value *at this
+specific point*. While there are several ways to find out the answer to this
+question, a few helper routines are provided as well. To identify the
+finest-resolution (i.e., most canonical) data at a given point, use
+:meth:`~yt.data_objects.hierarchy.AMRHierarchy.find_field_value_at_point`.
+This accepts a position (in coordinates of the domain) and returns the field
+values for one or multiple fields.
+
+To identify all the grids that intersect a given point, the function
+:meth:`~yt.data_objects.hierarchy.AMRHierarchy.find_point` will return indices
+and objects that correspond to it. For instance:
+
+.. code-block:: python
+
+ gs, gi = pf.h.find_point((0.5, 0.6, 0.9))
+ for g in gs:
+ print g.Level, g.LeftEdge, g.RightEdge
+
+Note that this doesn't just return the canonical output, but also all of the
+parent grids that overlap with that point.
diff -r b0b01f8d54244542cc60b1e5928d6e93298b2c0d -r 99a4d8f41eb2678aaaca741e1366b783da100f7c source/configuration.rst
--- a/source/configuration.rst
+++ b/source/configuration.rst
@@ -3,6 +3,9 @@
Configuration File
==================
+Configuration File Format
+-------------------------
+
yt will look for and recognize the file ``$HOME/.yt/config`` as a configuration
file, containing several options that can be modified and adjusted to control
runtime behavior. For example, a sample ``$HOME/.yt/config`` file could look
@@ -18,6 +21,9 @@
much more voluminous output from yt. Additionally, it increases the number of
parameter files tracked between instantiations of yt.
+Configuration Options At Runtime
+--------------------------------
+
In addition to setting parameters in the configuration file itself, you can set
them at runtime.
@@ -43,6 +49,31 @@
This has the same effect as setting ``loglevel = 1`` in the configuration file.
+Setting Configuration On the Command Line
+-----------------------------------------
+
+Options can also be set directly on the command line by specifying a
+command-line option. For instance, if you are running the script
+``my_script.py`` you can specify a configuration option with the ``--config``
+argument. As an example, to lower the log level (thus making it more verbose)
+you can specify:
+
+.. code-block::
+
+ $ python2.7 my_script.py --config loglevel=1
+
+Any configuration option specific to yt can be specified in this manner. One
+common configuration option would be to disable serialization:
+
+.. code-block::
+
+ $ python2.7 my_script.py --config serialize=False
+
+This way projections are always re-created.
+
+Available Configuration Options
+-------------------------------
+
The following parameters are available.
* ``__parallel`` (default: ``'False'``): Internal parameter governing whether this
diff -r b0b01f8d54244542cc60b1e5928d6e93298b2c0d -r 99a4d8f41eb2678aaaca741e1366b783da100f7c source/index.rst
--- a/source/index.rst
+++ b/source/index.rst
@@ -107,6 +107,7 @@
welcome/index
orientation/index
+ workshop
help/index
interacting/index
configuration
diff -r b0b01f8d54244542cc60b1e5928d6e93298b2c0d -r 99a4d8f41eb2678aaaca741e1366b783da100f7c source/orientation/first_steps.rst
--- a/source/orientation/first_steps.rst
+++ b/source/orientation/first_steps.rst
@@ -1,3 +1,5 @@
+.. _first_steps:
+
First Steps with yt
-------------------
@@ -85,6 +87,8 @@
>>> value, location = pf.h.find_max("Density")
+.. _grid_inspection:
+
Grid Inspection
+++++++++++++++
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