[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