[yt-dev] Issue #887: Asking for naked ARTIO particle field type corrupts field detection (yt_analysis/yt)

Douglas Rudd issues-reply at bitbucket.org
Wed Aug 27 17:27:48 PDT 2014


New issue 887: Asking for naked ARTIO particle field type corrupts field detection
https://bitbucket.org/yt_analysis/yt/issue/887/asking-for-naked-artio-particle-field-type

Douglas Rudd:

Field detection shows strange behavior when asking for a field without a particle type when that field doesn't exist for all types.

 - Example script: http://paste.yt-project.org/show/5071/
 - Example output: http://paste.yt-project.org/show/5072/

Explanation: I load a dataset with STAR type particles which has the unique field "BIRTH_TIME"

 - ("STAR","BIRTH_TIME") in ds.field_list == True
 - ("all","BIRTH_TIME") in ds.field_list == False

If I request ["all","BIRTH_TIME"], I correctly receive the exception
```
#!python

Could not find field '('all', 'BIRTH_TIME')' in AGORA_LOW_1.art.

```

If I request ["BIRTH_TIME"], it promotes this to ("all","BIRTH_TIME"), but then proceeds to chunk and attempt to load this non-existent field, leading to the exception (after I/O!):
```
#!python

Something has gone terribly wrong, _function is NullFunc for ('STAR', 'BIRTH_TIME')

```

Subsequent requests for ("all","BIRTH_TIME") then produce this latest exception, showing that field detection is caching some bad information somewhere.

I've tracked through the entire line of execution (I originally included it but it's so crazy and convoluted I think it's only useful for me).  I've found several things that look like bugs, and I'll submit a PR with some "fixes."  Since I don't know this part of the code it will need some review.





More information about the yt-dev mailing list