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

Handling of unit systems #38

Open
ksunden opened this issue Feb 14, 2019 · 1 comment
Open

Handling of unit systems #38

ksunden opened this issue Feb 14, 2019 · 1 comment

Comments

@ksunden
Copy link
Member

ksunden commented Feb 14, 2019

The output of many of the tuning procedures is dependent on the units used for the axes involved: from spacing as in nm/wn conversion to the smoothness factor on splines being different for different absolute (e.g. fs vs ps).

Currently, we assume in a few places that the "setpoint" is energy units, and that we wish to do the computation in "wn"

What I propose is that we have the ability to pass "unit system" to these mehods, with a sane default. This will convert relevant parts of data objects (axes and channels with units [looking at workup.setpoint]) as well as the relevant curve parts (setpoints, subcurve_setpoints, dependents) into these units.

We could have a separate plot "unit system" if we want, but not sure how that would work, especially in cases where the plot generated is in differential space.

As for what these "unit system" objects look like:

We could do dictionary: {kind: unit} (e.g. `{"energy": "wn", "delay": "ps"})
pro: very explicit, cannot accidentally over specify
con: dicts are mutable, and would be harder to specify a default (could use None, but I would lean towards None being "don't convert", though not sure that makes sense)

We could use any iterable, e.g. sets/tuples/lists
pro: easy and clean, both tuples and frozenset satisfy immutability
con: can lead to ("ps", "fs") both being called for, and not being sure which to use.

This may also be a good use for namedtuple come to think of it

These unit systems could be defined here in attune, or in WT, if we wish to fully implement this idea.

I would have convert accept this units sytem object directly (in addition to current behavior where a single unit is passed)

@ksunden
Copy link
Member Author

ksunden commented Feb 14, 2019

What this also does is enable processes which are additive in wavelength space to use curve objects, and the tuning procedures herein without fuss, while still keeping default behavior of ensuring adding is normally done in energy space

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

No branches or pull requests

1 participant