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... 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?