[yt-svn] commit/yt-doc: 2 new changesets
commits-noreply at bitbucket.org
commits-noreply at bitbucket.org
Tue Oct 22 06:44:43 PDT 2013
2 new commits in yt-doc:
https://bitbucket.org/yt_analysis/yt-doc/commits/5d2ec38bf7d9/
Changeset: 5d2ec38bf7d9
User: chummels
Date: 2013-09-21 19:25:04
Summary: Updating derived fields to note a bit more information about unit conversion.
Affected #: 1 file
diff -r 14a04e122f42b7fafea40e393d0d008d9e7ec459 -r 5d2ec38bf7d911021af42c66886833e81f239f6d source/analyzing/creating_derived_fields.rst
--- a/source/analyzing/creating_derived_fields.rst
+++ b/source/analyzing/creating_derived_fields.rst
@@ -55,16 +55,48 @@
with the intended field name prefixed by a single underscore, as in
the ``_Pressure`` example above.
-Note one last thing about this definition; we do not do unit
+If you find yourself using the same custom-defined fields over and over, you
+should put them in your plugins file as described in :ref:`plugin-file`.
+
+Conversion Factors
+~~~~~~~~~~~~~~~~~~
+
+When creating a derived field, yt does not by default do unit
conversion. All of the fields fed into the field are pre-supposed to
be in CGS. If the field does not need any constants applied after
that, you are done. If it does, you should define a second function
that applies the proper multiple in order to return the desired units
and use the argument ``convert_function`` to ``add_field`` to point to
-it.
+it.
-If you find yourself using the same custom-defined fields over and over, you
-should put them in your plugins file as described in :ref:`plugin-file`.
+The argument that you pass to ``convert_function`` will be dependent on
+what fields are input into your derived field, and in what form they
+are passed from their native format. For enzo fields, nearly all the
+native on-disk fields are in CGS units already (except for ``dx``, ``dy``,
+and ``dz`` fields), so you typically only need to convert for
+off-standard fields taking into account where those fields are
+used in the final output derived field. For other codes, it can vary.
+
+You can check to see the units associated with any field in a dataset
+from any code by using the ``_units`` attribute. Here is an example
+with one of our sample FLASH datasets available publicly at
+http://yt-project.org/data :
+
+.. code-block:: python
+
+ >>> from yt.mods import *
+ >>> pf = load("GasSloshing/sloshing_nomag2_hdf5_plt_cnt_0100")
+ >>> pf.h.field_list
+ ['dens', 'temp', 'pres', 'gpot', 'divb', 'velx', 'vely', 'velz', 'magx', 'magy', 'magz', 'magp']
+ >>> pf.field_info['dens']._units
+ '\\rm{g}/\\rm{cm}^{3}'
+ >>> pf.field_info['temp']._units
+ '\\rm{K}'
+ >>> pf.field_info['velx']._units
+ '\\rm{cm}/\\rm{s}'
+
+Thus if you were using any of these fields as input to your derived field, you
+wouldn't have to worry about unit conversion because they're already in CGS.
Some More Complicated Examples
------------------------------
https://bitbucket.org/yt_analysis/yt-doc/commits/6bc4a9e1b8fc/
Changeset: 6bc4a9e1b8fc
User: MatthewTurk
Date: 2013-10-22 15:44:41
Summary: Merged in chummels/yt-doc (pull request #102)
Updating derived fields to note a bit more information about unit conversion.
Affected #: 1 file
diff -r a8e1fc299d3b053c8318ff25ffeb7cdc71fa485d -r 6bc4a9e1b8fc5c60e2a1d71ab8c429c8f210b20f source/analyzing/creating_derived_fields.rst
--- a/source/analyzing/creating_derived_fields.rst
+++ b/source/analyzing/creating_derived_fields.rst
@@ -55,16 +55,48 @@
with the intended field name prefixed by a single underscore, as in
the ``_Pressure`` example above.
-Note one last thing about this definition; we do not do unit
+If you find yourself using the same custom-defined fields over and over, you
+should put them in your plugins file as described in :ref:`plugin-file`.
+
+Conversion Factors
+~~~~~~~~~~~~~~~~~~
+
+When creating a derived field, yt does not by default do unit
conversion. All of the fields fed into the field are pre-supposed to
be in CGS. If the field does not need any constants applied after
that, you are done. If it does, you should define a second function
that applies the proper multiple in order to return the desired units
and use the argument ``convert_function`` to ``add_field`` to point to
-it.
+it.
-If you find yourself using the same custom-defined fields over and over, you
-should put them in your plugins file as described in :ref:`plugin-file`.
+The argument that you pass to ``convert_function`` will be dependent on
+what fields are input into your derived field, and in what form they
+are passed from their native format. For enzo fields, nearly all the
+native on-disk fields are in CGS units already (except for ``dx``, ``dy``,
+and ``dz`` fields), so you typically only need to convert for
+off-standard fields taking into account where those fields are
+used in the final output derived field. For other codes, it can vary.
+
+You can check to see the units associated with any field in a dataset
+from any code by using the ``_units`` attribute. Here is an example
+with one of our sample FLASH datasets available publicly at
+http://yt-project.org/data :
+
+.. code-block:: python
+
+ >>> from yt.mods import *
+ >>> pf = load("GasSloshing/sloshing_nomag2_hdf5_plt_cnt_0100")
+ >>> pf.h.field_list
+ ['dens', 'temp', 'pres', 'gpot', 'divb', 'velx', 'vely', 'velz', 'magx', 'magy', 'magz', 'magp']
+ >>> pf.field_info['dens']._units
+ '\\rm{g}/\\rm{cm}^{3}'
+ >>> pf.field_info['temp']._units
+ '\\rm{K}'
+ >>> pf.field_info['velx']._units
+ '\\rm{cm}/\\rm{s}'
+
+Thus if you were using any of these fields as input to your derived field, you
+wouldn't have to worry about unit conversion because they're already in CGS.
Some More Complicated Examples
------------------------------
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