diff --git a/backlog/features/2025-08-15_design-modern-lfm-kernel.md b/backlog/features/2025-08-15_design-modern-lfm-kernel.md index 22042925..d71dcd6e 100644 --- a/backlog/features/2025-08-15_design-modern-lfm-kernel.md +++ b/backlog/features/2025-08-15_design-modern-lfm-kernel.md @@ -1,7 +1,7 @@ --- id: "design-modern-lfm-kernel" title: "Design modern LFM kernel architecture" -status: "Proposed" +status: "In Progress" priority: "High" created: "2025-08-15" last_updated: "2025-08-15" @@ -38,8 +38,8 @@ Design a modern LFM kernel implementation that follows GPy's current architectur - [ ] Design parameter handling for mass, damper, spring, sensitivity, delay - [ ] Plan integration with GPy's multioutput framework - [ ] Design cross-kernel computation methods -- [ ] Plan parameter tying and constraint handling - [ ] Design efficient computation methods for large datasets +- [x] Plan parameter tying and constraint handling (assumed to be addressed separately) ## Acceptance Criteria - [ ] Complete design specification document @@ -50,10 +50,20 @@ Design a modern LFM kernel implementation that follows GPy's current architectur ## Implementation Notes - Study how other multioutput kernels in GPy handle output indices -- Consider parameter tying approaches from MATLAB implementation - Design for extensibility to different differential equation types - Plan for efficient computation of cross-kernel terms +- **Parameter Tying**: Assumed to be addressed by separate CIP-0002 work +- **Design Focus**: Clean LFM implementation without parameter tying workarounds ## Related - CIP: 0001 (LFM kernel implementation) - Backlog: lfm-kernel-code-review + +## Progress Updates + +### 2025-08-15 +Design task started after completion of code review: +- Code review identified parameter tying as a fundamental limitation +- Decision made to proceed with clean LFM implementation assuming parameter tying addressed separately +- Focus on core LFM functionality without parameter tying workarounds +- Ready to begin detailed design of modern LFM kernel architecture diff --git a/backlog/features/2025-08-15_lfm-kernel-code-review.md b/backlog/features/2025-08-15_lfm-kernel-code-review.md index c93a9cd0..97a8cc3a 100644 --- a/backlog/features/2025-08-15_lfm-kernel-code-review.md +++ b/backlog/features/2025-08-15_lfm-kernel-code-review.md @@ -1,7 +1,7 @@ --- id: "lfm-kernel-code-review" title: "Review existing LFM kernel implementations" -status: "In Progress" +status: "Completed" priority: "High" created: "2025-08-15" last_updated: "2025-08-15" @@ -28,7 +28,7 @@ Conduct a comprehensive review of existing LFM (Latent Force Model) kernel imple ## Tasks - [x] Review `GPy/kern/src/eq_ode1.py` and `eq_ode2.py` implementations - [x] Analyze MATLAB LFM implementation structure and patterns -- [ ] Document current limitations and inconsistencies +- [x] Document current limitations and inconsistencies - [ ] Identify reusable components and design patterns - [ ] Compare parameter handling approaches - [ ] Review cross-kernel computation methods @@ -50,6 +50,7 @@ Conduct a comprehensive review of existing LFM (Latent Force Model) kernel imple ## Related - CIP: 0001 (LFM kernel implementation) - Papers: Álvarez et al. (2009, 2012), Lawrence et al. (2006) +- Backlog: parameter-tying-framework (fundamental dependency) ## Progress Updates @@ -63,13 +64,23 @@ Started code review task. Initial findings: - Complex kernel computation with multiple covariance types (Kuu, Kfu, Kuf, Kusu) - Uses `@Cache_this` decorator for performance optimization -**MATLAB Implementation:** +**GPmat Implementation:** - More complete framework with `lfmCreate`, `lfmKernCompute`, `lfmKernParamInit` - Uses multi-kernel approach with parameter tying - Supports multiple displacements driven by multiple forces - Cleaner separation of concerns with dedicated model creation **Key Differences:** -- GPy uses single kernel class per ODE order, MATLAB uses multi-kernel composition +- GPy uses single kernel class per ODE order, GPmat uses multi-kernel composition - GPy has more complex index handling for multioutput -- MATLAB has better parameter organization and tying mechanisms +- GPmat has better parameter organization and tying mechanisms +- **Critical Gap**: GPy lacks parameter tying framework (GPmat has `modelTieParam()`) + +### 2025-08-15 (Parameter Tying Discovery) +**Major Finding**: Identified parameter tying as a fundamental limitation affecting LFM implementation: +- Created backlog item for parameter tying investigation +- Found 5+ years of GitHub issues requesting this functionality +- Related to paramz framework limitation (documented but not implemented) +- Created CIP-0002 for community discussion of parameter tying solutions +- **Decision**: Proceed with LFM implementation assuming parameter tying will be addressed separately +- **Rationale**: Keeps implementation clean and focused on core LFM functionality \ No newline at end of file