[yt-dev] Issue #808: derived_field decorator in 3.0 experimental is finicky (yt_analysis/yt)

Nathan Goldbaum issues-reply at bitbucket.org
Thu Mar 20 15:13:54 PDT 2014


New issue 808: derived_field decorator in 3.0 experimental is finicky
https://bitbucket.org/yt_analysis/yt/issue/808/derived_field-decorator-in-30-experimental

Nathan Goldbaum:

Take as an example the following snippet:


```
#!python

from yt.mods import *
from yt.utilities.physical_constants import mh
from IPython.display import display

@derived_field(name='number_density', units='cm**-3')
def number_density(field, data):
    return data['density']/(data.pf.parameters['mu']*mh)

fields = ['number_density', 'temperature', 'grid_level']

ds = load('IsolatedGalaxy/galaxy0030/galaxy0030')
slc = SlicePlot(ds, 2, fields, width=(20, 'kpc'))
slc.save()
```

This currently fails with the following traceback: http://paste.yt-project.org/show/4409/

This actually should fail, since the parameter I'm really looking for is `'Mu'`, not `'mu'`. However, I'd hope I'd get traceback in the dictionary access.  I guess that error is swallowed by the field detection machinery.  Could we allow exceptions to be raised by user-supplied fields?

Correcting the error (replacing `'mu'` with `'Mu'`) leads to the following traceback: http://paste.yt-project.org/show/4410/

So it looks like `number_density` is being mapped to the `index` field type rather than `gas`.  Replacing `name='number_density'` with `name = ('gas', 'number_density')` allows the script to run without issues.

Is there a way to _detect_ the correct field type purely from the field dependency chain or is that already happening but is broken somehow?





More information about the yt-dev mailing list