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...
Take as an example the following snippet:
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?