Fix survival curve initialisation lifetime check

[idelder]

Previously the lifetimetech/lifetimeprocess parameter for a process with a survival curve was allowed to extend beyond the end of that survival curve. This leads to bugs where, in the initialisation of the annual_retirement constraint, a division of zero occurs as a survival curve of zero is called in the divisor. Forcing the lifetime to exactly equal the end of the survival curve (which it absolutely should, anyway) fixes this. This issue now reports a clear error with a recommended fix.

Summary by CodeRabbit

• Bug Fixes
  • Refined technology lifetime validation logic to ensure more accurate end-of-life alignment calculations. Updated error messages to provide clearer instructions for configuration adjustments.

[coderabbitai]

Walkthrough

Modified the end-of-life alignment validation logic for lifetime_process in the create_survival_curve function. Changed from checking if the value is less than the target end-of-life point to enforcing exact equality after rounding, and updated corresponding error messaging.

Changes

Cohort / File(s)	Summary
End-of-Life Alignment Validation temoa/components/technology.py	Replaced lifetime_process end-of-life alignment check from value(...) < p - v to round(value(...)) != p - v, enforcing exact equality after rounding. Updated error message to reference rounded lifetime and provide corrective action instructions. Removed previous warning branch for direct inequality.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Suggested labels

bugfix

🚥 Pre-merge checks | ✅ 3 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'Fix survival curve initialisation lifetime check' directly and concisely describes the main change: fixing a validation check for survival curve initialization regarding lifetime parameters. It is clear, specific, and appropriately summarizes the primary purpose of the changeset.
Merge Conflict Detection	✅ Passed	✅ No merge conflicts detected when merging into unstable

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

No actionable comments were generated in the recent review. 🎉

Tip

Issue Planner is now in beta. Read the docs and try it out! Share your feedback on Discord.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[Copilot]

Pull request overview

This PR fixes a critical bug in the survival curve validation logic that could lead to division by zero errors during model initialization. The fix tightens the validation to require that the lifetime_process parameter exactly matches the end of the survival curve, rather than allowing it to extend beyond.

Changes:

• Replaced the two-tier validation (error for < p - v, warning for != p - v) with a single strict validation using round(lifetime_process) == p - v
• Improved error message to display the actual lifetime_process value and provide clearer guidance
• Removed the warning case that allowed lifetime_process to extend beyond the survival curve end

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The use of round() without specifying the number of decimal places defaults to rounding to the nearest integer. While this appears appropriate given that p - v is always an integer (difference between two period years), it would be more explicit and maintainable to use round(value(model.lifetime_process[r, t, v]), 0) or to add a comment explaining that lifetime_process values are expected to be integer years when using survival curves. This would help future maintainers understand the intent.