lamorton/mdsmonkey

The MDS monkey helps you explore a new MDSplus tree system using the Python interpreter, and automatically converts array-based data with coordinates and units into xarray DataArray-type objects.

mdsmonkey's Issues

Handling compound.Range dimensions

If a node has 1-D data and the node.dim_of(0) returns a compound.Range object, this object is dropped, and no coordinate is produced, even though it should be. The offending lines in getXarray are:

if ax_dims==1: if noisy: print " inside dims==1" try: name=get_mds_shortname(get_mds_node_reference(ax)) coordinates[name]=((name,),ax.data()) #only give it a coordinate if it might be interesting except: name=own_name+"_index" #don't assign a coordinate, because it is presumably just an index if it doesn't have a node reference
This ought to be an easy fix, but there's some tricky stuff regarding how to handle unnamed axes when some of the 'dimensions' are really 'coordinates' (ie, have more than one axis themselves) that might get broken by fixing this issue. Need to run some regression tests to be sure that everything is consistent.

Handling n-dimensional (n>2) 'dimensions' that do not have node references

In testing MDSmonkey on MST's server 'dave', I encountered an issue. To be specific, the Thomson scattering electron temperature node has two dimensions, neither of which are associated with a node. Therefore, there is no way for the traverser to find the name of either axis. This by itself would not cause getXarray to fail. The difficulty arises because the 1st dimension returned by node.dim_of(1) is itself an array of type MDSplus.mdsarray.Float64Array, and this array has two axes itself.

Looking at the data, it is apparent that this array corresponds to the vertical position along the TS line-of-sight. Although it should really only be a 1-D array, it has been 'stretched' into a 2-D array, with a second axis corresponding to time, even though all the entries in this array are the same across time. (This is phenomenon is fairly common in MDSplus in the wild; on NSTX the EFIT radius and vertical position both are stretched like this.)

The exception gets raised in the following way: getXarray sees that the 1st dimension of the node has two dimensions, and therefore recursively calls itself in order to find out what the names of the two axes should be. The trouble is that getXarray expects a node object, but the Float64Array object doesn't have one. When get_mds_node_reference fails to find a node, it spits out a None. This gets passed as the argument to the recursive call to getXarray, which then fails with an uninformative error message, because it isn't obvious that the error occurs inside the recursion.

The behavior of get_mds_node_reference in this situation is suboptimal: it should produce an error instead of returning None. Then, the call to get_mds_node_reference should be moved to a try statement, to allow recovery. It's not clear what should ultimately happen, though: in xarray parlance, the vertical position array is called a coordinate, and as such one needs to know the names of the dimensions / axes in order to match them by name against the axes of the data (in this case, the 2-D temperature array).

There's no way to do this programmatically in a case like this, short of matching the length of the dimensions; this is poor form, however, because there may be ambiguity. Realistically, though, this is exactly what the user is forced to do; furthermore, the user is also forced to consult an expert to find the names of the two dimensions, or infer them from the type of units provided, or something. (By the way, xarray itself started out allowing such inference, but moved to deprecate it.)

My opinion is that getXarray ought to raise an exception by default in cases like this, with perhaps an optional keyword to allow inference by matching array shapes. Another alternative is to fall back on the tree-style construction that I've used in the cases when it's not possible to form a proper xarray type object. This would allow the user to easily see what had gone wrong. However, one needs to supply some default dimension names, which might mask the issue in this case.