[yt-dev] yt Particle Plots & openPMD Frontend

John ZuHone jzuhone at gmail.com
Thu May 26 11:33:51 PDT 2016


Hi Fabian,

OK—we now know exactly what is going on. 

First, some background on some changes to the way units in general (and electromagnetic units in particular) are handled in yt:

Even though superficially 1 G ~ 1.0e-4 T, it is not strictly true because

1 G = 1 sqrt(g)/(sqrt(cm)*s) —> dimensions of sqrt(mass)/(sqrt(length)*time)

1 T = 1 kg/(A*s**2) —> dimensions mass/(current*time**2)

since SI has a fundamental unit of current and CGS does not, it means that you cannot strictly convert between the two since yt unit conversions are based on converting between objects with the same dimensions. 

We ignored this discrepancy in previous versions of yt, and simply allowed conversions between G and T, but in order to make things more self-consistent and better support MKS units we have now implemented the notion of separate unit systems, which means that you cannot convert directly between G and T anymore since they are not the same dimensions. 

However, you can associate a specific set of units (such as MKS/SI) with a particular frontend, by adding this keyword in the call to __init__ like this:

class openPMDDataset(Dataset):
    def __init__(self, filename, …, unit_system=“mks”)

However, as Nathan has pointed out to me, though this is supposed to work it won’t because we need to make sure the dataset’s unit registry itself has a unit system. This will require a patch, which we are happy to do and provide for you to test to make sure we can get this to work for you. 

I should note that regardless of what units your magnetic field is in you can make conversions between MKS/SI and CGS EM units using the to_equivalent() method for YTArrays and YTQuantities:

B = YTQuantity(1.0,"T") # magnetic field in Tesla
print (B, B.to_equivalent("gauss","CGS")) # convert to Gauss

There is more information about this here:

http://yt-project.org/docs/dev/analyzing/units/unit_equivalencies.html#Electromagnetic-Equivalencies <http://yt-project.org/docs/dev/analyzing/units/unit_equivalencies.html#Electromagnetic-Equivalencies>

You can see the rationale for the new unit system setup here:

http://ytep.readthedocs.io/en/latest/YTEPs/YTEP-0028.html <http://ytep.readthedocs.io/en/latest/YTEPs/YTEP-0028.html>

and, most relevant for you, the specific language on magnetic fields here:

http://ytep.readthedocs.io/en/latest/YTEPs/YTEP-0028.html#special-handling-for-magnetic-fields <http://ytep.readthedocs.io/en/latest/YTEPs/YTEP-0028.html#special-handling-for-magnetic-fields>

Let me know if you have any other questions about any of this, or if any of it is unclear—I think Nathan wants to work on this. 

Best,

John

> On May 26, 2016, at 1:59 PM, Fabian Koller <f.koller at hzdr.de> wrote:
> 
> Hi there,
> 
> I am currently trying to extend the WIP frontend for openPMD.
> 
> Let me be more specific about the magnetic unit problem:
> The already existing frontend was created on top of yt 3.2.1 and
> appeared to work fine.
> Recently, the code was migrated onto the yt_analysis/yt branch, which I
> understand to be your dev version.
> What appears to be the problem is this line of code in our
> openPMDDataset class:
> self.magnetic_unit = self.quan(1.0, "T")
> 
> This worked with out noticeable problems with the old codebase.
> After the migration, loading a oPMD file throws YTUnitsNotReducible:
> 
> In [1]: import yt
> In [2]: f =
> yt.load('/data/home/koller47/openpmd/example-2d/hdf5/data00000100.h5')
> Warning: Attribute author (recommended) does NOT exist in `/`!
> Found 1 iteration(s)
> Iteration 100 : found 4 meshes
> Iteration 100 : found 2 particle species
> Warning: Key particlePatches (recommended) does NOT exist in
> `/data/100/particles/Hydrogen1+`!
> Warning: Key particlePatches (recommended) does NOT exist in
> `/data/100/particles/electrons`!
> yt : [INFO     ] 2016-05-26 19:22:56,315 openPMD: found 5 iterations in
> directory
> yt : [WARNING  ] 2016-05-26 19:22:56,316 openPMD: only choose to load
> the first iteration (100)
> ---------------------------------------------------------------------------
> YTUnitsNotReducible                       Traceback (most recent call last)
> <ipython-input-7-b3e410e545a5> in <module>()
> ----> 1 f =
> yt.load('/data/home/koller47/openpmd/example-2d/hdf5/data00000100.h5')
> 
> /data/home/koller47/openpmd/yt/convenience.pyc in load(*args, **kwargs)
>     84     candidates = find_lowest_subclasses(candidates)
>     85     if len(candidates) == 1:
> ---> 86         return candidates[0](*args, **kwargs)
>     87     if len(candidates) == 0:
>     88         if ytcfg.get("yt", "enzo_db") != '' \
> 
> /data/home/koller47/openpmd/yt/frontends/openPMD/data_structures.pyc in
> __init__(self, filename, dataset_type, storage_filename, units_override)
>    294         self._setBasePath(self._handle, self._filepath)
>    295         Dataset.__init__(self, filename, dataset_type,
> --> 296                          units_override=units_override)
>    297         self.storage_filename = storage_filename
>    298         self.fluid_types += ('openPMD',)
> 
> /data/home/koller47/openpmd/yt/data_objects/static_output.pyc in
> __init__(self, filename, dataset_type, file_style, units_override,
> unit_system)
>    235         self._create_unit_registry()
>    236         self._parse_parameter_file()
> --> 237         self.set_units()
>    238         self._setup_coordinate_handler()
>    239
> 
> /data/home/koller47/openpmd/yt/data_objects/static_output.pyc in
> set_units(self)
>    806             self.unit_registry.modify('a',
> 1/(1+self.current_redshift))
>    807
> --> 808         self.set_code_units()
>    809
>    810         if getattr(self, "cosmological_simulation", False):
> 
> /data/home/koller47/openpmd/yt/data_objects/static_output.pyc in
> set_code_units(self)
>    843             # If we do not have this set, but some fields come in in
>    844             # "code_magnetic", this will allow them to remain in
> that unit.
> --> 845             self.unit_registry.modify("code_magnetic",
> self.magnetic_unit)
>    846         vel_unit = getattr(
>    847             self, "velocity_unit", self.length_unit /
> self.time_unit)
> 
> /data/home/koller47/openpmd/yt/units/unit_registry.pyc in modify(self,
> symbol, base_value)
>    107
>    108         if hasattr(base_value, "in_base"):
> --> 109             base_value = base_value.in_base().value
>    110
>    111         self.lut[symbol] = (float(base_value), ) +
> self.lut[symbol][1:]
> 
> /data/home/koller47/openpmd/yt/units/yt_array.pyc in in_base(self,
> unit_system)
>    559         >>> E_new = E.in_base(unit_system="galactic")
>    560         """
> --> 561         return
> self.in_units(self.units.get_base_equivalent(unit_system))
>    562
>    563     def in_cgs(self):
> 
> /data/home/koller47/openpmd/yt/units/unit_object.pyc in
> get_base_equivalent(self, unit_system)
>    421         if unit_system == "cgs":
>    422             if current_mks in self.dimensions.free_symbols:
> --> 423                 raise YTUnitsNotReducible(self, "cgs")
>    424             return yt_base_unit
>    425         else:
> 
> YTUnitsNotReducible: The unit 'T' cannot be reduced to a single
> expression within the cgs base system of units.
> 
> With
> self.magnetic_unit = self.quan(1.0, "gauss")
> loading the file works fine and as expected.
> 
> As for openPMD test data, you can get 2D and 3D ones from here:
> https://github.com/openPMD/openPMD-example-datasets
> 
> On 24/05/16 18:54, John Zuhone wrote:
>> The latest development version of yt now has “unit systems”:
>> 
>> http://yt-project.org/docs/dev/analyzing/units/unit_systems.html
>> 
>> But Nathan is correct—this doesn’t affect the Tesla unit per se—it
>> should be fine. If we could get a script and a more specific error
>> that you are seeing, that would help. 
>> 
>>> On May 24, 2016, at 12:30 PM, 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.)
>>> 
>>> 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?
>>> 
>>> 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
>>> <read_openPMD.py>_______________________________________________
>>> yt-dev mailing list
>>> yt-dev at lists.spacepope.org <mailto:yt-dev at lists.spacepope.org>
>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20160526/f9736b10/attachment.html>


More information about the yt-dev mailing list