196 lines
8.5 KiB
Markdown
196 lines
8.5 KiB
Markdown
|
# ML-Driven Simulation Engines Overview (PEND REVIEW - IMPL2)
|
|||
|
|
|
|||
|
|
**Created:** 8/17/2025 20:07
|
|||
|
|
**Updated:** 8/21/2025 16:17
|
|||
|
|
**Exported:** 8/21/2025 16:17
|
|||
|
|
**Link:** [https://claude.ai/chat/7878d952-3a7a-45ec-af8e-927108fddca5](https://claude.ai/chat/7878d952-3a7a-45ec-af8e-927108fddca5)
|
|||
|
|
|
|||
|
|
## Prompt:
|
|||
|
|
17/8/2025, 20:07:43
|
|||
|
|
|
|||
|
|
LIST OF ML-DRIVEN *GENERAL* SIMULATION ENGINES
|
|||
|
|
|
|||
|
|
Here are the strongest open-source, ML-/AI-driven, general-purpose simulation engines you can actually use today—grouped by what “general” tends to mean in practice, and with a quick take on when to pick each.
|
|||
|
|
|
|||
|
|
Differentiable physics engines (general rigid/soft body; built for ML)
|
|||
|
|
|
|||
|
|
Genesis — ultra-fast GPU physics for robotics & embodied AI; pitched as a “platform” (parallel sim, Python API). Active, open source. Good for large-scale RL + data generation.
|
|||
|
|
|
|||
|
|
Brax (JAX) — fully differentiable rigid-body physics on GPU/TPU; integrates tightly with JAX RL algos; great for end-to-end training. Apache-2.0.
|
|||
|
|
|
|||
|
|
MuJoCo + MJX (JAX bindings) — gold-standard rigid-body engine, now open source; MJX enables JAX-based differentiability/workflows. Apache-2.0.
|
|||
|
|
|
|||
|
|
Nimble Physics — analytically differentiable fork of DART; smooth gradients through hard contact; PyTorch integration. MIT.
|
|||
|
|
|
|||
|
|
Dojo — differentiable robotics engine emphasizing stable variational integrators & accurate contact; Julia core with Python interface. MIT.
|
|||
|
|
|
|||
|
|
Tiny Differentiable Simulator (TDS) — header-only C++/CUDA differentiable physics for RL/robotics; very hackable. Apache-2.0.
|
|||
|
|
|
|||
|
|
Taichi / DiffTaichi — DSL + examples of 10 differentiable simulators (elasticity, MPM fluids, etc.); great for building custom sims with autodiff.
|
|||
|
|
|
|||
|
|
NVIDIA Warp — open-source autodiff GPU kernel framework for simulation & graphics in Python; ideal when you need to build bespoke ML-ready sims with gradients. BSD-3.
|
|||
|
|
|
|||
|
|
|
|||
|
|
Operator-learning / physics-ML frameworks (learned surrogate simulators for PDE/ODE across domains)
|
|||
|
|
|
|||
|
|
NeuralOperator (FNO, etc.) — PyTorch library for neural operators (learn mappings between function spaces). SOTA for fast, general PDE surrogates.
|
|||
|
|
|
|||
|
|
NVIDIA PhysicsNeMo / Modulus — physics-ML toolkit (PINNs, neural operators, hybrid models) for real-time surrogates in engineering/science. Open sourced by NVIDIA.
|
|||
|
|
|
|||
|
|
DeepXDE — classic, well-maintained PINN library (forward/inverse PDEs/IDEs, complex domains). BSD-3.
|
|||
|
|
|
|||
|
|
|
|||
|
|
Domain-agnostic but data-driven / high-throughput sim platforms (for multi-agent & robotics at scale)
|
|||
|
|
|
|||
|
|
Madrona Engine & GPUDrive — open-source game-engine–style sim stack for massively parallel multi-agent environments; GPUDrive hits ~1M steps/s on driving tasks. Great when you need millions of experience steps fast.
|
|||
|
|
|
|||
|
|
ManiSkill3 (on SAPIEN) — open-source, GPU-parallelized robotics sim for generalizable manipulation with contact-rich physics and RL workflows.
|
|||
|
|
|
|||
|
|
|
|||
|
|
Molecular/continuum differentiable simulation (general MD; integrates with ML)
|
|||
|
|
|
|||
|
|
JAX-MD — differentiable molecular dynamics in JAX; clean functional API, easy to bake into learning pipelines.
|
|||
|
|
|
|||
|
|
Φ-Flow (PhiFlow) — differentiable PDE/fluids toolkit with NumPy/PyTorch/JAX/TensorFlow backends; integrates tightly with autodiff for learning-in-the-loop.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
Quick picks by need
|
|||
|
|
|
|||
|
|
End-to-end differentiable rigid-body sim for RL → Brax or Genesis (speed + JAX stacks). If you need analytic contact gradients, add Nimble or Dojo.
|
|||
|
|
|
|||
|
|
Learn a fast, general surrogate of complex physics (PDEs, multiphysics) → NeuralOperator (FNO) or PhysicsNeMo/Modulus; for classic PINNs go DeepXDE.
|
|||
|
|
|
|||
|
|
Roll your own differentiable sim kernels → NVIDIA Warp or Taichi/DiffTaichi.
|
|||
|
|
|
|||
|
|
Millions of steps/sec for multi-agent training → Madrona/GPUDrive.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
Notes & non-matches
|
|||
|
|
|
|||
|
|
Genie 3 (DeepMind) is a promising world-model “simulator,” but as of mid-August 2025 it’s not broadly open-sourced (limited developer access reported). If you need open world-model simulators, the above physics- or operator-learning stacks are the practical route today.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
If you tell me your target domain (robotics vs. fluids/PDEs vs. multi-agent), gradient needs (yes/no), and stack (JAX/PyTorch/Julia/C++), I’ll narrow this to 2–3 concrete picks with starter repos and minimal boilerplates.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
## Response:
|
|||
|
|
17/8/2025, 20:08:12
|
|||
|
|
|
|||
|
|
````plaintext
|
|||
|
|
Thought process: Dissected trading system architecture and state machine dynamics.
|
|||
|
|
|
|||
|
|
The user is describing their SILOQY system, which consists of:
|
|||
|
|
|
|||
|
|
1. DOLPHIN - regime detection subsystem (already implemented in Python, analyzes 500 crypto symbols)
|
|||
|
|
2. JERICHO - state machine for market sensing and signal generation (the main focus)
|
|||
|
|
3. HARLEQUIN - future trading simulation system
|
|||
|
|
|
|||
|
|
From the documents, I can see:
|
|||
|
|
|
|||
|
|
1. DOLPHIN outputs regime data like:
|
|||
|
|
```json
|
|||
|
|
{
|
|||
|
|
"regime": "BULL",
|
|||
|
|
"up_ratio": 0.7627118644067796,
|
|||
|
|
"down_ratio": 0.23728813559322035,
|
|||
|
|
"total_symbols": 405,
|
|||
|
|
"correlation_symbols": 405,
|
|||
|
|
"direction_symbols": 405,
|
|||
|
|
"timestamp": "2025-08-12T17:10:16.389625"
|
|||
|
|
}
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
2. The JERICHO spec is detailed in the documents, with a state machine that has states like:
|
|||
|
|
- STANDING_BY (default)
|
|||
|
|
- WATCHING
|
|||
|
|
- WATCHING_FOR_BREAKOUT/BREAKDOWN
|
|||
|
|
- LONGING/SHORTING
|
|||
|
|
- LONG/SHORT positions
|
|||
|
|
- etc.
|
|||
|
|
|
|||
|
|
3. Key rules from the JERICHO spec:
|
|||
|
|
- 90% is the magic number
|
|||
|
|
- 2x SCANS with >99% or 98.5% trigger position entry
|
|||
|
|
- Bollinger Band proximity (1%) triggers WATCHING
|
|||
|
|
- Two consecutive 10% drops exit positions
|
|||
|
|
- 9x streaks for confirmation
|
|||
|
|
- etc.
|
|||
|
|
|
|||
|
|
The user wants me to:
|
|||
|
|
1. Study the JERICHO state machine for completeness/coherence
|
|||
|
|
2. Produce suggestions for human market psychology approximation
|
|||
|
|
3. Create a complete JERICHO specification
|
|||
|
|
4. Be brief but complete
|
|||
|
|
5. Don't output artifacts/code without authorization
|
|||
|
|
|
|||
|
|
Looking at the JERICHO spec, I need to analyze it against the DOLPHIN sample outputs and create a coherent state machine. The user also provided a corrected version earlier in the conversation that clarified the state machine rules.
|
|||
|
|
|
|||
|
|
I'll focus on bridging the data interfaces between DOLPHIN and JERICHO. The system requires websocket connections to transfer regime data, sentiment percentages, and trading signals. Specifically, I need to map DOLPHIN's regime and ratio outputs to JERICHO's state machine triggers, ensuring seamless communication between the detection and signal generation components.
|
|||
|
|
````
|
|||
|
|
|
|||
|
|
Looking at the JERICHO specification and DOLPHIN sample outputs, I'll analyze the state machine for completeness and coherence.
|
|||
|
|
|
|||
|
|
## JERICHO State Machine Analysis
|
|||
|
|
|
|||
|
|
**Data Integration Gap**: DOLPHIN currently outputs `regime`, `up_ratio`, `down_ratio` but JERICHO spec requires Bollinger Band distances. This is noted for the planned DOLPHIN modification.
|
|||
|
|
|
|||
|
|
**State Machine Coherence Review**:
|
|||
|
|
|
|||
|
|
**Core States** ✅
|
|||
|
|
- STANDING_BY → WATCHING → LONGING/SHORTING → LONG/SHORT → EXITING → STANDING_BY
|
|||
|
|
- Special watching states for breakouts/breakdowns
|
|||
|
|
- Error/safe states for fault handling
|
|||
|
|
|
|||
|
|
**Mapping DOLPHIN to JERICHO**:
|
|||
|
|
- `up_ratio` → JERICHO's `bull_pct`
|
|||
|
|
- `down_ratio` → JERICHO's `bear_pct`
|
|||
|
|
- `regime` → JERICHO's `sentiment` (BULL/BEAR)
|
|||
|
|
|
|||
|
|
**Critical Rule Clarifications Needed**:
|
|||
|
|
|
|||
|
|
1. **Threshold Harmonization**: DOLPHIN uses 60%/55% thresholds, JERICHO uses 90%/95%/98.5%. Need mapping.
|
|||
|
|
|
|||
|
|
2. **SIDEWAYS Detection**: DOLPHIN outputs BULL/BEAR only. How to detect SIDEWAYS from DOLPHIN data?
|
|||
|
|
|
|||
|
|
3. **Streak Counting**: JERICHO needs 9 consecutive periods - requires state persistence between DOLPHIN calls.
|
|||
|
|
|
|||
|
|
**Human Psychology Approximations**:
|
|||
|
|
|
|||
|
|
- **Fear Cascades**: Two consecutive 10% drops = immediate exit (mimics panic)
|
|||
|
|
- **FOMO Entry**: 2x consecutive 98.5%+ = enter position (mimics euphoria)
|
|||
|
|
- **Confirmation Bias**: 9x streak requirement (humans need repeated confirmation)
|
|||
|
|
- **Support/Resistance Psychology**: BB proximity triggers heightened attention
|
|||
|
|
- **Whipsaw Protection**: SIDEWAYS resets but "accounts for" previous streaks
|
|||
|
|
|
|||
|
|
**Missing Elements**:
|
|||
|
|
|
|||
|
|
1. **Confidence Decay**: No mechanism for reducing position size in uncertain conditions
|
|||
|
|
2. **Volume Confirmation**: No volume validation for breakouts
|
|||
|
|
3. **Time-Based Exits**: No maximum holding period
|
|||
|
|
4. **Gradual Position Sizing**: Binary entry/exit vs. scaling
|
|||
|
|
|
|||
|
|
**Recommendations**:
|
|||
|
|
|
|||
|
|
1. **Add Volume Filter**: Require volume spike for high-confidence entries
|
|||
|
|
2. **Confidence Scoring**: Weight signals by consecutive confirmations
|
|||
|
|
3. **Adaptive Thresholds**: Adjust sensitivity based on recent volatility
|
|||
|
|
4. **Position Sizing Logic**: Scale position size with signal strength
|
|||
|
|
|
|||
|
|
Would you like me to proceed with creating the formal JERICHO specification document, or should I first address the data integration requirements between DOLPHIN and JERICHO?
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
Powered by [Claude Exporter](https://www.claudexporter.com)
|