unwanted name attribute from asdf NDArrayType

[CagtayFabry]

There appears to happen some unlucky attribute propagation when reading from asdf ndarray -> pint.Quantity -> xarray.DataArray which makes the following fail:

ts = TimeSeries(data=Q_([40.0,20.0], "V"),time=Q_([0.0,10.0],"s"))
data = weldx.asdf.utils._write_read_buffer({"root":ts})
data["root"] == ts
>>> False

Both TimeSeries have identical values but == fails because xarray.DataArray.identical checks every attribute including DataArray.name

When reading from the ASDF file in this case the name attribute gets erroneously applied:

print(ts.data_array.name)
>>> None
print(data["root"].data_array.name)
>>> core/ndarray

The problem occurs because when creating a pint.Quantity directly from an ndarray it actually gets constructed from the asdf NDArrayType which apparently carries .name='core/ndarray'
This propagates over to the pint.Quantity and finally xarray.DataArray.

Here is a quick fix for the TimeSeries class 1dd1f23 but we should be aware of the issue and discuss how to handle this in general.

[marscher]

Ain't an issue any more.

[CagtayFabry]

I think we fixed this in the TimeSeries asdf implementation?
but the general problem should still persist?

One possible idea could be to adapt asdf implementation of our quantity to remove the attribute.

[CagtayFabry]

cref #364 (comment)

relevant code:

weldx/weldx/asdf/tags/weldx/core/geometry/spatial_data.py

Lines 15 to 18 in 905e5e1

	def from_tree_mod(tree):
	if "coordinates" in tree:
	tree["coordinates"] = np.asarray(tree["coordinates"])
	return tree

[vhirtham]

So reopen?

[CagtayFabry]

yes I think I'd like to run some more tests until finally closing this one

[marscher]

Sorry, if this caused extra work now. I just ran the attached snippet and it didn't showed the described behavior any more.

[CagtayFabry]

it's good to keep in mind, I'll have to think of a proper snipped for debugging

[marscher]

most likely fixed in #456

[marscher]

the linked pr fixed this issue.