Updates to DIII-D mappings

[orso82]

We're starting to use OMAS machine mappings to bring DIII-D experimental data into FUSE.

Using theomfit_classes.omfit_eqdsk.from_mds_plus() function for pulling equilibrium data was very inefficient and failed in many situations. All I really need are the following entries:

with ods.open('d3d', pulse, options={'EFIT_tree': EFIT_tree}):
    ods["equilibrium.time"]
    for k in range(len(ods["equilibrium.time"])):
        ods["equilibrium.time_slice"][k]["time"]
        ods["equilibrium.time_slice"][k]["global_quantities.ip"]
        ods["equilibrium.time_slice"][k]["profiles_1d.psi"]
        ods["equilibrium.time_slice"][k]["profiles_1d.f"]
        ods["equilibrium.time_slice"][k]["profiles_1d.pressure"]
        ods["equilibrium.time_slice"][k]["profiles_2d[0].psi"]
        ods["equilibrium.time_slice"][k]["profiles_2d[0].grid.dim1"]
        ods["equilibrium.time_slice"][k]["profiles_2d[0].grid.dim2"]
        ods["equilibrium.time_slice"][k]["profiles_2d[0].grid_type.index"]
        ods["equilibrium.vacuum_toroidal_field.r0"]
        ods["equilibrium.vacuum_toroidal_field.b0"]

Also, the way things were coded, the equilibrium_special() function required kEQDSK files to be saved in MDS+. While I understand that's ok for CAKE runs, this requirement made things fail for between shot EFITs (EFIT01, EFIT02, ...) that are run from snap file.

[torrinba]

Thanks for cleaning up and fixing some of the mappings! It will certainly benefit from more people looking at and using it.

I can see why equilibrium_special would cause problems for the standard EFIT trees, but missed that this became default. Since the machine mappings aren't part of the OMAS regressions (IIRC), that kind of issue is easy to miss. I tried to run the OMFIT regression tests before any substantial OMAS merges, but that didn't seem to catch it either. Which could be because there is no option to run all OMFIT tests as a SU (e.g. on Morti) or because the full equilibrium mapping isn't in any of the OMFIT tests. Can you help setup a more complete way to test the mappings (either within OMFIT or another way) so that issues like this are caught sooner?

I have a few more questions about the changes you've made as well:

1. You deleted most occurrences of equilibrum_special from d3d.json but not all of them. Is there a reason some need to be there, but the others don't?
2. It looks like you removed equilibrium.ids_properties.homogeneous_time from being set in equilibrium_special. Is this duplicated somewhere else or otherwise not important to keep?
3. How come you removed core_profiles_1d from the test_machine_mapping_functions call?

Besides that, the changes look good to me. I hope @AreWeDreaming can test this with everything he put together for omasviewer to make sure nothing is falling through the cracks.

[orso82]

@torrinba

1. I have left the equilibrum_special() for things under equilibrium.time_slice.:.constraints and equilibrium.code.parameters which are not mapped in the _efit.json

2. equilibrium.ids_properties.homogeneous_time is set by _efit.json and equilibrum_special() was shadowing it.

3. The test_machine_mapping_functions() call at the bottom of each mapping file is really meant for development purpose. I change what mapping that function calls depending on what mapping I am developing...

About the testing, all mapping functions of a machine can be executed by setting test_machine_mapping_functions() to run __all__ tests

if __name__ == '__main__':
    test_machine_mapping_functions('d3d', __all__, globals(), locals())

and then just calling python on that

    python omas/machine_mappings/d3d.py

This will run each mapping function with its own set of testing parameters, as defined by their @machine_mapping_function decorator.