search

dnarayanan / powderday

powderday dust radiative transfer
BSD 3-Clause "New" or "Revised" License
22 stars 17 forks source link

new yt hashes cause an error on field addition #127

Closed dnarayanan closed 3 years ago

dnarayanan commented 3 years ago

First known bad hash in yt4.0 (main branch)

commit f20e3e7281dc893110373e165d147526d6f781e9
Merge: 41b88cfcd 77d56c3e1
Author: Clément Robert <cr52@protonmail.com>
Date:   Mon May 10 21:46:56 2021 +0200

    Merge pull request #3255 from yt-project/pre-commit-ci-update-config

    [pre-commit.ci] pre-commit autoupdate

last known good hash:

commit 7431b4d5a72e75c6e6782f19a234869895deb650
Merge: 5d73efa28 d0d05bc6d
Author: John ZuHone <jzuhone@gmail.com>
Date:   Tue Apr 20 22:38:14 2021 -0400

    Merge pull request #2400 from AshKelly/yt-4.0-new-octree

    [yt-4.0] new depth-first octree
The error is in gadget2pd if you run the gizmo_mw_zoom:
/home/desika.narayanan/yt/yt/fields/field_info_container.py:381: VisibleDeprecationWarning: 'particle_type' keyword argument is deprecated in favour of the positional argument 'sampling_type'.
Deprecated since v4.0.0. This feature will be removed in v4.1.0
  sampling_type, particle_type=kwargs.get("particle_type")
Traceback (most recent call last):
  File "/home/desika.narayanan/miniconda3/envs/pd4env/lib/python3.6/site-packages/powderday-0.1.0-py3.6.egg/powderday/front_ends/gadget2pd.py", line 322, in gadget_field_add
  File "/home/desika.narayanan/yt/yt/data_objects/static_output.py", line 1537, in add_field
    self.field_info.add_field(name, function, sampling_type, **kwargs)
  File "/home/desika.narayanan/yt/yt/fields/field_info_container.py", line 394, in add_field
    self.alias(name, tuple_name)
  File "/home/desika.narayanan/yt/yt/fields/field_info_container.py", line 489, in alias
    units=units,
  File "/home/desika.narayanan/yt/yt/fields/field_info_container.py", line 396, in add_field
    self[name] = DerivedField(name, sampling_type, function, **kwargs)
  File "/home/desika.narayanan/yt/yt/fields/field_info_container.py", line 428, in __setitem__
    ftype, fname = key
ValueError: too many values to unpack (expected 2)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/desika.narayanan/miniconda3/envs/pd4env/bin/pd_front_end.py", line 4, in <module>
    __import__('pkg_resources').run_script('powderday==0.1.0', 'pd_front_end.py')
  File "/home/desika.narayanan/miniconda3/envs/pd4env/lib/python3.6/site-packages/pkg_resources/__init__.py", line 665, in run_script
    self.require(requires)[0].run_script(script_name, ns)
  File "/home/desika.narayanan/miniconda3/envs/pd4env/lib/python3.6/site-packages/pkg_resources/__init__.py", line 1470, in run_script
    exec(script_code, namespace, namespace)
  File "/home/desika.narayanan/miniconda3/envs/pd4env/lib/python3.6/site-packages/powderday-0.1.0-py3.6.egg/EGG-INFO/scripts/pd_front_end.py", line 74, in <module>
  File "/home/desika.narayanan/miniconda3/envs/pd4env/lib/python3.6/site-packages/powderday-0.1.0-py3.6.egg/powderday/sph_tributary.py", line 35, in sph_m_gen
  File "/home/desika.narayanan/miniconda3/envs/pd4env/lib/python3.6/site-packages/powderday-0.1.0-py3.6.egg/powderday/grid_construction.py", line 49, in yt_octree_generate
  File "/home/desika.narayanan/miniconda3/envs/pd4env/lib/python3.6/site-packages/powderday-0.1.0-py3.6.egg/powderday/front_ends/gadget2pd.py", line 334, in gadget_field_add
  File "/home/desika.narayanan/yt/yt/data_objects/static_output.py", line 1537, in add_field
    self.field_info.add_field(name, function, sampling_type, **kwargs)
  File "/home/desika.narayanan/yt/yt/fields/field_info_container.py", line 396, in add_field
    self[name] = DerivedField(name, sampling_type, function, **kwargs)
  File "/home/desika.narayanan/yt/yt/fields/field_info_container.py", line 428, in __setitem__
    ftype, fname = key
ValueError: too many values to unpack (expected 2
)

the code is choking on the very first field addition:

ds.add_field(('starmetals'), function=_starmetals_00, sampling_type='particle',units="code_metallicity", particle_type=True)

so I'm guessing that something in the nomenclature for adding fields has changed. a git bisect would get us there.

dnarayanan commented 3 years ago

after a yt slack conversation with Britton Smith, he mentioned that "i think field access by string (i.e., not tuple) has been outlawed" . In other words, instead of:

ds.add_field(('starmetals'), function=_starmetals, ....

we would want:

ds.add_field(('PartType4','starmetals'),function=....

so we unfortunately need to go through all the front ends, and not only clean up this nomenclature, but all nomenclature downstream that called single string name (e.g. starmetals) fields. to keep it general, I suggest something like:

ds.add_field(('stars','starmetals')...
dnarayanan commented 3 years ago

fixed by f1998053de53424ea6880984797db65b8a0dbd7d