Change 2nd dimension name to avoid crash for gauss cases

[JamesMcClung]

Fixes #21

The name of the 2nd dimension doesn't matter, since it gets dropped. This fixes the case where multiple dataarrays exist in one dataset (e.g. rho and dive for gauss outputs), where previously, the name of the 2nd dimension shared by all dataarrays was set to contain the name of the first dataarray.

An alternative approach would have been to change gauss output on the PSC side to produce a single datarray with 2 components, dive and rho.

It might be nice to have this behavior enforced by tests, but there are no gauss outputs in the sample directory. That could merit a new issue.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Files with missing lines	Coverage Δ
src/pscpy/psc.py	98.24% <100.00%> (ø)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[JamesMcClung]

Thoughts on this? I know it's another step away from the concept of a jeh variable, but I would like to be able to load gauss datasets without having to manually edit my venv's copy of pscpy

[germasch]

So I think I did this kinda ugly naming to prevent problems with uniqueness. Specifically, if a dataset has fields and moments, one of them may have 9 components but the other 26 (or whatever). If the dimension is called "components" in both cases, xarray will complain, since a given dimension must have a unique length.

[germasch]

I don't think I understand exactly things went wrong for you, but I gather it's related if not somehow opposite. What I thought should have happened is that you get comp_rho and comp_dive dimension names, and while both them are equal to one, it shouldn't break. Are you saying they both get called comp_rho? That wouldn't be as intended, though I guess I also see why that'd break, since that dimension is length 1 no matter what it's called?

[JamesMcClung]

Ah, that makes sense. Maybe the easiest solution would be to index by dimension number instead of dimension name, although that's marginally harder to read.

[JamesMcClung]

re. your second comment (which didn't exist when I was writing my reply to the first): I tried to explain in #21 , but yes, that's the gist of the problem. The dive and rho variables both happen to have a length-1 "component" dimension, so somewhere between adios2 and xarray, those dimension names default to "dim_1_1" and are assumed to be the same by xarray.

The error I was running into was that the line you highlighted above only occurs for the first variable, but doing it for each variable wouldn't help unless the dimension can be de-combined.