[yt-svn] commit/yt-doc: MatthewTurk: Added notes about what types of fields there are, and a discussion of the new

[Bitbucket]

1 new commit in yt-doc:


https://bitbucket.org/yt_analysis/yt-doc/changeset/a5e377a0e366/
changeset:   a5e377a0e366
user:        MatthewTurk
date:        2011-12-09 19:20:15
summary:     Added notes about what types of fields there are, and a discussion of the new
changes for deliberate_fields.  Kept it brief.
affected #:  1 file

diff -r 313cdf7061478eea76cc8fc225a385cc540242cb -r a5e377a0e36615922571c168a58c3713090c38d7 source/analyzing/objects.rst
--- a/source/analyzing/objects.rst
+++ b/source/analyzing/objects.rst
@@ -7,6 +7,61 @@
 However, for detailed data inspection as well as hand-crafted derived data,
 objects can be exceptionally useful and even necessary.
 
+.. _types_of_fields:
+
+What Types of Fields are There?
+-------------------------------
+
+``yt`` makes a distinction between two types of fields.
+
+ * Fields it might expect to find on disk
+ * Fields it has to generate in memory
+
+With the 2.3 release of ``yt``, the distinction between these has become more
+clear.  This enables much better specification of which fields are expected to
+exist, and to provide fallbacks for calculating them.  For instance you can now
+say, "Temperature" might exist, but if it doesn't, here's how you calculate it.
+This also provides easier means of translating fields between different
+frontends.  For instance, FLASH may refer to the temperature field as "temp"
+while Enzo calls it "Temperature".  Translator functions ensure that any
+derived field relying on "temp" or "Temperature" works with both output types.
+
+When a field is requested, the parameter file first looks to see if that field
+exists on disk.  If it does not, it then queries the list of code-specific
+derived fields.  If it finds nothing there, it then defaults to examining the
+global set of derived fields.
+
+To add a field to the list of fields that you know should exist in a particular
+frontend, call the function ``add_frontend_field`` where you replace
+``frontend`` with the name of the frontend.  Below is an example for adding
+``Cooling_Time`` to Enzo:
+
+.. code-block:: python
+
+   add_enzo_field("Cooling_Time", units=r"\rm{s}",
+                  function=NullFunc,
+                  validators=ValidateDataField("Cooling_Time"),
+                  projection_conversion="1")
+
+Note that we used the ``NullFunc`` function here.  To add a derived field,
+which is not expected to necessarily exist on disk, use the standard
+construction:
+
+.. code-block:: python
+
+   add_field("ThermalEnergy", function=_ThermalEnergy,
+             units=r"\rm{ergs}/\rm{g}")
+
+To add a translation from one field to another, use the ``TranslationFunc`` as
+the function for reading the field.  For instance, this code appears in the Nyx
+frontend:
+
+.. code-block:: python
+
+   add_field("Density", function=TranslationFunc("density"), take_log=True,
+             units=r"\rm{g}} / \rm{cm}^3",
+             projected_units =r"\rm{g}} / \rm{cm}^2")
+
 .. _accessing-fields:
 
 Accessing Fields in Objects

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.