[yt-dev] yt Particle Plots & openPMD Frontend

Huebl, Axel a.huebl at hzdr.de
Fri May 27 00:37:32 PDT 2016


Dear Nathan and John,

thank you for the quick answers.

Yes, the resources to reproduce the questions are:

Repo:
  https://bitbucket.org/C0nsultant/openpmd/src?at=yt

Example Files:
  PIConGPU > 2D3V > one of the .h5 files
  https://owncloud.hzdr.de/index.php/s/ouisGZe5M0wCVzj
  password: openPMD

Example script (attached, like last mail).


Axel

On 24.05.2016 18:37, Nathan Goldbaum wrote:
> 
> 
> On Tue, May 24, 2016 at 11:30 AM, Huebl, Axel <a.huebl at hzdr.de
> <mailto:a.huebl at hzdr.de>> wrote:
> 
>     Hi yt-devs,
> 
>     I am forwarding this conversation to the public list to keep it open for
>     others to join in and to build up a record that might help others.
> 
>     Our new student Fabian updated our frontend and implemented particle
>     readers. Unfortunately some details of the particle "fields" still cause
>     some bumps that we can not get our head around.
> 
>     We are now able to read fields and particles, even chunk-wise, and can
>     work with the data we read in python scripts via the all_data() method.
> 
>     Nevertheless, using the particle scatter plots such as yt.ParticlePlot
>     seems not to work. We have some problems with unions / the "all" group
>     and the fact that we have several particle species (e.g., "hot
>     electrons", "cold electrons", "helium ions", "nitrogen ions", etc.)
> 
> 
> The 'all' particle union should get set up automatically, but maybe
> something is going wrong with that machinery.
> 
> Can you create a test script that illustrates this issue using a
> publicly available OpenPMD dataset?
>  
> 
> 
>     Also since the last rebase: did someone recently change the unit system
>     in yt? T for "Tesla" seems not to be understood any more. Is there a
>     changelog somewhere available? Do we have to describe our data in
>     cgs / mks?
> 
> 
> I just double-checked, and Tesla should be working:
> 
> In [1]: from yt import YTQuantity
> 
> In [2]: YTQuantity(1, 'T')
> Out[2]: 1.0 T
> 
> In [3]: YTQuantity(1, 'T').to_equivalent('G', 'CGS')
> Out[3]: 10000.0 G
>  
> Can you explain a little bit more what issue you're having? A test
> script that illustrates the issue would also help.
> 
> 
>     Would someone be interested for a quick heads up via e.g., skype /
>     web-rtc so we can ask specific questions?
> 
>     Fabian is around on Tuesdays and Fridays, something like early CA time,
>     and late GER time usually works great (e.g., 9pm-PDT / 6pm-CEST).
> 
>     Our current branch HEAD can be found here (->yt->frontends->openPMD):
>       https://bitbucket.org/C0nsultant/openpmd/src?at=yt
> 
>     And an example script is attached.
> 
> 
>     Thanks a lot!
>     Axel
> 
> 

-- 

Axel Huebl
Phone +49 351 260 3582
https://www.hzdr.de/crp
Computational Radiation Physics
Laser Particle Acceleration Division
Helmholtz-Zentrum Dresden - Rossendorf e.V.

Bautzner Landstrasse 400, 01328 Dresden
POB 510119, D-01314 Dresden
Vorstand: Prof. Dr.Dr.h.c. R. Sauerbrey
          Prof. Dr.Dr.h.c. P. Joehnk
VR 1693 beim Amtsgericht Dresden
-------------- next part --------------
#!/usr/bin/env python
#
# 2016 Fabian Koller (HZDR), WTFPL

# Loading simulation files, reading in field lists (mesh, particle)
# and getting the raw data out of those fields works fine:

f = yt.load('/path/to/sim/h5_data_3500.h5')
ad = f.all_data()

f.field_list
# Out[8]:
#[('io', u'e_charge'),
# ('io', u'e_mass'),
# ('io', u'e_momentum_x'),
# ('io', u'e_momentum_y'),
# ('io', u'e_momentum_z'),
# ('io', u'e_positionOffset_x'),
# ('io', u'e_positionOffset_y'),
# ('io', u'e_positionOffset_z'),
# ('io', u'e_position_x'),
# ('io', u'e_position_y'),
# ('io', u'e_position_z'),
# ('io', u'e_weighting'),
# ('openPMD', 'B_x'),
# ('openPMD', 'B_y'),
# ('openPMD', 'B_z'),
# ('openPMD', 'E_x'),
# ('openPMD', 'E_y'),
# ('openPMD', 'E_z'),
# ('openPMD', 'e-chargeDensity')]

print(ad['io', 'e_mass'])
# Out[9]:
# YTArray([ 0.00014378,  0.00014378,  0.00014378, ...,  0.00014378,
#        0.00014378,  0.00014378]) (dimensionless)

p = yt.ParticlePlot(f, ('io', 'e_position_x'), ('io', 'e_position_y'))
# YTFieldNotFound: Could not find field '('all', 'particle_ones')' in h5_data_3500.h5.


# My problems mainly arise from they yt concept of fields.
# What I am specifically unsure about:
# - Given my data on disk for a single kind of particle, do I create a field
#     ('io', particle_property_as_name)
#   to get the raw data, e.g. through `_read_particle_fields()`?
#   Why does a ParticlePlot require `('all', 'particle_ones')`,
#   which is a ones array the size of the simulation domain?
# 
# - Where are derived fields of the form `('all', *)` generated in ENZO/chombo/...?
#   I understand that `setup_particle_fields()` in `fields.py` gets
#   called for every relevant `ptype`, be it `io` in case of a single
#   particle species or specific kinds for multiple ones, but for
#   'all' (automatically generated particle union?) as well.
#   Now, having tried to manually add any `('all', fname)` through `self.add_field()`
#   in `io.py` did not make it show up in the `derived_field_list`.
#   Did end up the same way with functions and without them.
# 
# - What would I need derived fields for? Is a projection plot without them possible?
#   We understand that we might want to pre-define derived fields and that
#   user-scripts want to create derived fields but do we *need* derived
#   particle fields already for simple particle plots of *already existing*
#   particle attributes (e.g., a phase space plot)?
#
# - What is the meaning of `known_particle_fields` in `io.py` if the fields
#   (read through _detect_output_fields or derived) you declare can have arbitrary names?
#
# - Is there a set of yt specific names I just have to alias to, rather than create derived fields?
#

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5119 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20160527/de1a0308/attachment-0002.bin>


More information about the yt-dev mailing list