feat: named case-result load combinations with full GUI support
Snapshots the current development tree, headlined by proper load combinations (user request): a reusable LoadCombination entity of weighted completed static-case results (e.g. 1.2xDead + 1.6xLive). - core: LoadCombination/LoadCombinationItem entities, Project integration (lookup, unique ids, reference validation) - services: combinations.py (linear superposition + envelope), exported via services __init__ - commands: undoable Add/Delete/Update for combinations - GUI: Load Combinations manager dialog, Run-dialog evaluation, envelope display in Results panel, Combinations tab in Table dock - tests: unit coverage (validation, math, error paths) + integration superposition check vs a single factored run
This commit is contained in:
commit
f361fee969
560 changed files with 178701 additions and 0 deletions
37
specifications/README.md
Normal file
37
specifications/README.md
Normal file
|
|
@ -0,0 +1,37 @@
|
|||
# OTKO — specifications (this repo)
|
||||
|
||||
This folder holds **OTKO's own planning documents**. It is deliberately
|
||||
separate from the greenfield rebuild spec set at
|
||||
`~/Sync/otko-development/specifications` (docs `00`–`14`), which stays the
|
||||
reference for *what a conformant rebuild looks like*. Requirement IDs of
|
||||
the form `[AREA-NNN]` cited in this folder refer to that rebuild set.
|
||||
|
||||
## Why this folder exists
|
||||
|
||||
`~/Sync/otko` (this repo) is the **working, feature-rich app** and is the
|
||||
primary deliverable. `~/Sync/otko-development` is a **greenfield rebuild**
|
||||
that conforms closely to the rebuild specs but is less capable in several
|
||||
areas (transient/pushover/response-spectrum, richer element/material
|
||||
coverage, `.osmodel` corpus, HDF5). The goal of the plan below is to
|
||||
**harvest the rebuild's good, spec-conformant capabilities into this app
|
||||
without breaking what already works** — not to rewrite this app to the
|
||||
rebuild's architecture.
|
||||
|
||||
## Documents
|
||||
|
||||
| # | Document | Purpose |
|
||||
|---|---|---|
|
||||
| 15 | [15-rebuild-adoption-plan.md](15-rebuild-adoption-plan.md) | Dependency-ordered plan for porting rebuild capabilities into this repo, with adoption matrix, phases, gates, risks and explicit skips. |
|
||||
|
||||
## Ground rules (summary — see doc 15 §3)
|
||||
|
||||
- **Additive, never replacement.** This repo is a superset of the rebuild
|
||||
in the solver/runner/export surface; protect that.
|
||||
- **Keep the working app working:** `.osmodel` format, AGPL-3.0 license,
|
||||
Python 3.10–3.12 support, existing tests green.
|
||||
- **Adapt, don't copy:** re-type ported code to this repo's APIs
|
||||
(`StaticResults`/`ModalResults`, mutable `Project`, 4-value `UnitSystem`).
|
||||
- **One phase = one branch = independently shippable**, each with its own
|
||||
tests and gate.
|
||||
- **License hygiene:** the rebuild is MIT, this repo is AGPL-3.0; MIT→AGPL
|
||||
is compatible, but ported files need attribution (see doc 15 §7).
|
||||
Loading…
Reference in a new issue