6a6c04d34b
- Update all submodule URLs from gitea.centraal.wbd-rd.nl to gitea.wbd-rd.nl - Add settler as proper submodule in .gitmodules - Add agent skills, function anchors, decisions, and improvements - Add Docker configuration and scripts - Add manuals and third_party docs - Update .gitignore with secrets and build artifacts - Remove stale .tgz build artifact Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
59 lines
2.4 KiB
Markdown
59 lines
2.4 KiB
Markdown
---
|
|
name: evolv-mechanical-rotating-equipment
|
|
description: Provide rotating equipment engineering guidance for EVOLV machine and pumping logic. Use when implementing or reviewing `rotatingMachine`, `machineGroupControl`, pump/motor behavior, operating envelopes, efficiency/power curves, surge/choke limits, and physically plausible constraints in node domain logic.
|
|
---
|
|
|
|
# EVOLV Mechanical Rotating Equipment
|
|
|
|
## Mission
|
|
Keep rotating equipment behavior physically plausible, safe, and diagnosable in EVOLV JavaScript domain classes.
|
|
|
|
## Harness Execution Contract
|
|
- Start from equipment assumptions and current curve/sensor sources in repo.
|
|
- Define invariants before edits:
|
|
- physical plausibility constraints remain enforced
|
|
- degraded/fail-safe behavior remains explicit
|
|
- outputs remain diagnosable for operations teams
|
|
- Validate with boundary-condition evidence and deterministic test outcomes.
|
|
|
|
## Scope
|
|
- `nodes/rotatingMachine/`
|
|
- `nodes/machineGroupControl/`
|
|
- `nodes/pumpingStation/`
|
|
- Related shared curve/model datasets in `nodes/generalFunctions/datasets/assetData/`
|
|
|
|
## Engineering Checklist
|
|
1. Validate units and conversions before algorithm changes.
|
|
2. Enforce operating envelope constraints:
|
|
- min/max speed
|
|
- flow/head boundaries
|
|
- power/torque limits
|
|
- efficiency range sanity
|
|
3. Prevent impossible states (negative flow where not allowed, non-physical efficiencies, unstable mode transitions).
|
|
4. Define clear degraded behavior for out-of-range inputs.
|
|
5. Preserve interpretability: outputs should map to recognizable mechanical concepts.
|
|
|
|
## Implementation Pattern
|
|
- Keep mechanics in `src/specificClass.js`.
|
|
- Keep Node-RED concerns in `src/nodeClass.js`.
|
|
- Use shared helpers from `generalFunctions` for logging/config assertions.
|
|
|
|
## Test Expectations
|
|
Add/adjust tests under node-specific `test/` for:
|
|
- boundary conditions
|
|
- invalid sensor/input combinations
|
|
- regression of known machine edge cases
|
|
- deterministic output under repeated ticks
|
|
|
|
## Deliverables
|
|
Return:
|
|
- assumptions about equipment type and curve source
|
|
- implemented constraints and rationale
|
|
- test coverage for boundary cases
|
|
- remaining mechanical uncertainties requiring field data
|
|
|
|
Decision interview triggers:
|
|
- safety envelope changes (speed, power, flow/head boundaries)
|
|
- curve-source replacement with uncertain field alignment
|
|
- degraded-mode changes that affect availability vs protection tradeoffs
|