visualdynamics.core.unit_choices¶
unit_choices
¶
Which units the interface offers, grouped by the quantity they measure.
Objects import unit-less when their source does not declare units. The
user says what the values are in the imported-units pane (see
MainWindow.show_units_panel); these lists are what it offers.
Grouping matters: a channel a file called an acceleration is offered four units rather than twenty-one, and the four are the only ones that could be right. The lists are shortlists, never limits — every unit cell takes anything visualdynamics can parse, typed or pasted.
In core rather than beside the widgets that offer these lists: which
units an acceleration could be in is a fact about accelerations, and
ChannelTable needs it to narrow a channel's unit column. It lived in
gui/ and core reached up into it, which is the one direction imports
must not go.
Functions:
| Name | Description |
|---|---|
shown_dimension |
The word for a dimension in the interface. |
stored_dimension |
The dimension behind a word the interface offered. |
base_dimension |
The quantity whose unit the user picks, given a record's dimension. |
units_for |
The units worth offering for a dimension, everything if it is unknown. |
squared_per_hz |
How a PSD's declared unit actually reads: 'g' -> 'g²/Hz'. |
engineering_unit |
The unit inside a PSD label; the inverse of |
Functions:¶
shown_dimension
¶
stored_dimension
¶
base_dimension
¶
The quantity whose unit the user picks, given a record's dimension.
An FRF's ordinate is named by its numerator and a PSD is declared by the engineering unit whose square it stores, so in every case the choice is named by the leading term.
Source code in src/visualdynamics/core/unit_choices.py
units_for
¶
The units worth offering for a dimension, everything if it is unknown.
A file often names a quantity without sizing it — a UNV with no dataset 164 says 'acceleration' and stops. Narrowing the list to that quantity turns 21 choices into four, and the four are the only ones that could be right.
Source code in src/visualdynamics/core/unit_choices.py
squared_per_hz
¶
How a PSD's declared unit actually reads: 'g' -> 'g²/Hz'.
A compound unit is bracketed, so '(m/s²)²/Hz' cannot be misread as m/s² squared only in the seconds.
Source code in src/visualdynamics/core/unit_choices.py
engineering_unit
¶
The unit inside a PSD label; the inverse of squared_per_hz.
Typing 'g' is accepted as readily as 'g²/Hz' — the suffix is what the interface adds for clarity, not something the user must reproduce.