Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Machine Mapping Autogeneration Is Not Consistent #303

Open
torrinba opened this issue Mar 28, 2024 · 5 comments
Open

Machine Mapping Autogeneration Is Not Consistent #303

torrinba opened this issue Mar 28, 2024 · 5 comments
Assignees
Labels

Comments

@torrinba
Copy link
Collaborator

@AreWeDreaming reports that the machine mapping for DIII-D profiles which OMAS autogenerates pulls from 2 different places so the MDS+ location changes every time it's regenerated.

What's the best way to sort this out @orso82?

@AreWeDreaming
Copy link
Collaborator

AreWeDreaming commented Mar 28, 2024

I think I might have done something to address this inside the machine mapping function here:

def core_profiles_profile_1d(ods, pulse, PROFILES_tree="OMFIT_PROFS"):

Essentially having one function for all core_profile fields, but I think there is still conflict here and we might need to pull that part in there too
"core_profiles": {
"PYTHON": "core_profiles_profile_1d(ods, {pulse}, {PROFILES_tree!r})"

"core_profiles.global_quantities.v_loop": {
"COCOSIO": 11,
"PYTHON": "core_profiles_global_quantities_data(ods, {pulse})"

@torrinba
Copy link
Collaborator Author

torrinba commented Mar 28, 2024

If you have a test we can use to see this issue that would be helpful (maybe something we should add to the OMFIT regression tests since those currently seem to be insensitive to this problem, somewhat surprisingly)

@AreWeDreaming
Copy link
Collaborator

A specific test would be to load first something that core_profiles_profile_1d provides and then try to access core_profiles.global_quantities.v_loop

@torrinba
Copy link
Collaborator Author

torrinba commented Apr 2, 2024

Do you have an example of where the core_profiles machine mapping works?

with ods.open('d3d', 1795780001):
    psi = ods[f'core_profiles.profiles_1d.:.grid.psi']

I've tried several shots but always see errors like this:

DEBUG (dynamic): Dynamic open  {'machine': 'd3d', 'pulse': 1795780001, 'options': {}, 'branch': '', 'user_machine_mappings': None}
DEBUG (dynamic): Dynamic read  {'machine': 'd3d', 'pulse': 1795780001, 'options': {}, 'branch': '', 'user_machine_mappings': None}: core_profiles.profiles_1d.:
size(\ZIPFIT01::TOP.PROFILES.EDENSFIT,1)
core_profiles.profiles_1d.: issue:TreeFOPENR('%TREE-E-FOPENR, Error opening file read-only.\n - server: atlas.gat.com:8000\n - treename: ZIPFIT01\n - pulse: 1795780001\n - TDI: size(\\ZIPFIT01::TOP.PROFILES.EDENSFIT,1)')
DEBUG (dynamic): Dynamic close {'machine': 'd3d', 'pulse': 1795780001, 'options': {}, 'branch': '', 'user_machine_mappings': None}
Traceback (most recent call last):
  File "test.py", line 11, in <module>
    psi = ods[f'core_profiles.profiles_1d.:.grid.psi']
  File "/fusion/projects/codes/atom/omfit_omega_v3.x/atom_git/OMFIT-source_unstable/omas/omas/omas_core.py", line 1324, in __getitem__
    return value.__getitem__(key[1:], cocos_and_coords)
  File "/fusion/projects/codes/atom/omfit_omega_v3.x/atom_git/OMFIT-source_unstable/omas/omas/omas_core.py", line 1324, in __getitem__
    return value.__getitem__(key[1:], cocos_and_coords)
  File "/fusion/projects/codes/atom/omfit_omega_v3.x/atom_git/OMFIT-source_unstable/omas/omas/omas_core.py", line 1239, in __getitem__
    raise ValueError('`%s` has no data' % self.location)
ValueError: `core_profiles.profiles_1d` has no data

Copy link

github-actions bot commented Jun 2, 2024

Stale issue message

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants