[yt-dev] yt Particle Plots & openPMD Frontend

Axel Huebl a.huebl at hzdr.de
Sat Jun 11 01:39:31 PDT 2016


Thanks you nathan and fabian,

That sounds really great!

Yes our namings are not fixed nor the number of data sets since our simulations have a high agility on solvers and methods and the openPMD markup is actually not bound to a specific domain of science (e.g., one file could be a sim, an other a CCD image from an experiment, etc. ...). Regarding the link: 1.0.0 is the released standard, the upcoming 1.0.1 just adds some clarifications and examples.

Best,
Axel

On June 10, 2016 8:20:53 PM CEST, Fabian Koller <f.koller at hzdr.de> wrote:
>Wow!
>
>Thanks for the speedy and thorough solution. It seems to work
>flawlessly, based on a quick test.
>
>I can see that the decision to produce known fields on the fly seems a
>bit odd, but there's a simple reason behind it: The openPMD stadard (in
>theory) allows for infinitely many different fields to exist, all of
>them with different unit-dimensions. Very little is actually static:
>only the basic structure of our data, not its content, not its names,
>not its units and dimensions. Trying to cover as much of the standard
>as
>is feasible, we decided to dynamically generate known fields. (Also,
>having done it this way has helped me internalize the standard. A lot.)
>
>If you're interested our reasoning more than this brief explanation,
>I'd
>refer you to the current (well, upcoming) written standard:
>https://github.com/openPMD/openPMD-standard/blob/upcoming-1.0.1/STANDARD.md,
>in particular "unitDimension".
>
>
>--Fabian
>
>On 10/06/16 17:55, Nathan Goldbaum wrote:
>> Hey,
>>
>> The issue you're having is because you're constructing
>> known_other_fields dynamically. All the other frontends define it
>> statically, so it's filled out by the time it's needed in the
>> `setup_fluid_aliases` function defined in in
>> yt/fields/field_info_container.py. The fix is to change the order of
>> operations - setup known_other_fields and known_particle_fields
>before
>> calling the __init__ method on the superclass of OpenPMDFieldInfo.
>>
>> You're also incorrectly setting the units of the field to a Unit
>> object --- the unit entry in the known_other_fields tuple should be a
>> string.
>>
>> The following diff allows me to set the units properly for your
>frontend:
>>
>> http://paste.yt-project.org/show/6606/
>>
>> Out of curiosity - why build the known_other_fields and
>> known_particle_fields tuples dynamically? The reason they're static
>> for all the other frotends is to make it easy to reason about which
>> fields are associated with a given frontend and so that the fields
>> known by a given frontend are independent of any particular dataset
>> you might be looking at.
>>
>> By the way, it also looks like the 'all' particle union is working
>> correctly - are you still having issues with that?
>>
>> -Nathan
>> _______________________________________________
>> yt-dev mailing list
>> yt-dev at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
>_______________________________________________
>yt-dev mailing list
>yt-dev at lists.spacepope.org
>http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org



More information about the yt-dev mailing list