You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit a27793b
Browse filesBrowse the repository at this point in the historyBrowse files
motors: name anchors after the machine, not their position in the file
`Geometry2`/`Computation2` are named for being the second machine defined, not for
the machine they describe. Nothing in the name says 5-phase or 40-slot, and nothing
distinguishes it from the other 5-phase variants people run on branches.
One module per anchor, named `<class>_<phases>f_<slots>s`:
motors/motor1.py -> motors/synrm_3f_36s.py
motors/motor2.py -> motors/synrm_5f_40s.py
Each exports plain `Geometry` and `Computation`, so the module name carries the
identity and the class names stay uniform. The numbering existed only because both
machines shared a namespace; per-anchor modules remove the need for it.
from motors.synrm_5f_40s import Computation, Geometry
The name carries only what the anchor fixes for good -- class, phases, slots. Turns
are deliberately left out: `Nc` is routinely swept, so a name containing it goes
stale. Same reasoning for currents and bus voltage.
Also restores the anchor definition to CONTRIBUTING (it survives on the
`contributing` branch but was dropped in #23, leaving "anchor" used three times and
never defined, and the sentence "add an **motors**" mid-substitution), and fixes that
sentence.
No behaviour change: the two anchor modules were diffed against the `motor1.py` /
`motor2.py` they replace, with the class renames normalised away, and are identical
apart from a one-line docstring -- including the fixes from #28 and #29, which landed
in `motor2.py` while this branch was open and had to be carried across by hand.
Callers must update their import path; there is no compatibility shim, so a stale
import fails loudly rather than silently resolving to an aliased class.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+19-3Lines changed: 19 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -17,10 +17,26 @@ If you find yourself editing `machine_design/`on your own branch, stop — that'
17
17
|`machine_design/optimization/`| design agnostic optimizers and geometry generators |
18
18
|`machine_design/parallel_calculation/`| parallel runners for sweeping many solves at once |
19
19
|`experiments/<name>/`| your run configs, the profile/objective you're studying, analysis notebooks, result artifacts, write-ups |
20
-
|`motors/`|concrete machine definitions (`motor1.py`, `motor2.py`), each subclassing the base `Geometry`/`Computation` classes |
20
+
|`motors/`|one module per **anchor** (a named machine), each subclassing the base `Geometry`/`Computation` classes |
21
21
|`tests/`| the test suite |
22
22
23
-
Add a new machine by subclassing an existing `motors/motor*.py` file instead of editing an existing class in place, so old results stay reproducible.
23
+
### Anchors — machines are named, not numbered
24
+
25
+
An **anchor** is a named machine definition: everything needed to instantiate and solve one physical machine — class, slots, phases, winding (turns, `Rs`), end-winding `Lew`, **rotor radii**, geometry generator + parameter bounds, FEA template.
26
+
27
+
The name carries only what the anchor fixes for good — machine class, phases, slot count. Values that are routinely swept (turns, currents, bus voltage) stay out of it, so a name never goes stale.
28
+
29
+
One anchor per module in `motors/`, named `<class>_<phases>f_<slots>s`:
Each exports `Geometry` and `Computation`, so the module name carries the identity and the class names stay uniform — `from motors.synrm_5f_40s import Geometry, Computation` says which machine you are solving, where `Geometry2` did not.
37
+
38
+
-**Derive, don't fork.** To study a variant (add magnets, change turns), subclass an existing anchor and override only what differs — do **not** edit an anchor's class in place, so old results stay reproducible. A genuinely new machine is a new anchor module.
39
+
-**An anchor must declare all of the above**, rotor radii included. They are the radial window the barrier generators draw into; an anchor that does not set them cannot have a rotor built for it.
24
40
25
41
## Pull requests
26
42
@@ -60,7 +76,7 @@ All compute goes through the SLURM queue on `bayes` — see [`bayes-queue/README
60
76
61
77
**I want to optimize an existing machine with an existing method** → in `experiments/<name>/`, write a config that picks an anchor + a method + your objective/constraints, and an sbatch to run it. Touch nothing shared.
62
78
63
-
**I want to study a new machine** → add an **motors** (PR to `main`); if it's a variant, derive it from an existing anchor. Then use it from your experiment.
79
+
**I want to study a new machine** → add an **anchor** (PR to `main`); if it's a variant, derive it from an existing anchor. Then use it from your experiment.
64
80
65
81
**I want a new optimization method** → add it to `machine_design/optimization/` against the interface (PR to `main`). Now anyone can use it on any anchor.
0 commit comments