- Posts: 7
Battery degradation and lifetime
- Peter
- Topic Author
Less
More
17 Nov 2025 05:58 #14374
by Peter
Battery degradation and lifetime was created by Peter
Hello everyone,I am working on a research project where I need to model multiple full calendar-life cycles of a lithium-ion battery within a single SAM simulation.
Conceptually, the goal is simple:
Then I used “Replace at specified schedule” (year 10) expecting the lifetime state to reset to 100 %.
However, after the first 100→80 % decline, the overall lifetime degradation simply continues downward across the entire project horizon (20–25 years).
It does not restart at 100 % after replacement.(2) Multi-cycle calendar table (“reset points”)I also tested a more explicit multi-cycle calendar table:
In the calendar-only result series, these resets appear correctly.
But in the final output
“Battery relative capacity to nameplate”,
after the first drop to ~80 %, the value becomes “stuck” around the minimum.
At each replacement event I see only a small bump (e.g. 80 → ~83 %), followed by an immediate fall back to ~80 %.
No true second or third cycle appears.Limitation with “Replace at capacity”I also attempted using “Replace at capacity”, which might more strictly reset the lifetime state, but this option makes the simulation extremely slow at 15-minute resolution (once SoH reaches ~50 %, the model becomes nearly unusable).
For practical purposes, this option is not feasible.My questionIs SAM intended to support multiple physical life cycles (100→80 %, replace, 100→80 %, replace) within a single simulation run?Or is it the intended behavior that
“Battery relative capacity to nameplate”
remains essentially monotonic and reflects only one cumulative degradation curve, even if replacements occur?What I am looking forIs there a simple recommended workflow to achieve the following:
Conceptually, the goal is simple:
- the battery should degrade from 100 % → 80 % over its lifetime,
- then be replaced,
- and the new battery should again start at 100 % and degrade to 80 %,
- and so on.
Code:
0 days → 100 % 3650 days → 80 %
However, after the first 100→80 % decline, the overall lifetime degradation simply continues downward across the entire project horizon (20–25 years).
It does not restart at 100 % after replacement.(2) Multi-cycle calendar table (“reset points”)I also tested a more explicit multi-cycle calendar table:
Code:
0 → 100 % 3650 → 80 % 3651 → 100 % 7300 → 80 % ...
But in the final output
“Battery relative capacity to nameplate”,
after the first drop to ~80 %, the value becomes “stuck” around the minimum.
At each replacement event I see only a small bump (e.g. 80 → ~83 %), followed by an immediate fall back to ~80 %.
No true second or third cycle appears.Limitation with “Replace at capacity”I also attempted using “Replace at capacity”, which might more strictly reset the lifetime state, but this option makes the simulation extremely slow at 15-minute resolution (once SoH reaches ~50 %, the model becomes nearly unusable).
For practical purposes, this option is not feasible.My questionIs SAM intended to support multiple physical life cycles (100→80 %, replace, 100→80 %, replace) within a single simulation run?Or is it the intended behavior that
“Battery relative capacity to nameplate”
remains essentially monotonic and reflects only one cumulative degradation curve, even if replacements occur?What I am looking forIs there a simple recommended workflow to achieve the following:
- define replacement years (e.g. year 10 and 20),
- have SAM treat each new battery as starting again at 100 %,
- show a new independent 100→80 % degradation cycle,
- and have this behavior visible in the final SoH output?
Please Log in or Create an account to join the conversation.
- Paul Gilman
Less
More
- Posts: 5677
17 Nov 2025 16:20 #14379
by Paul Gilman
Replied by Paul Gilman on topic Battery degradation and lifetime
Hi Peter,
The attached battery-replacements.sam file contains two PV-Battery / Residential cases that compare the "replace at specified capacity" and "replace at specified schedule" options on the Battery Life page.
The "replace at 80%" case replaces the battery when its capacity degrades to 80%.
This results in the battery being replaced three times in the 25-year analysis period:
The "replace every 10 years" case replaces the battery every 10 years, regardless of the battery capacity.
This option results in two replacements over the 25 years, with the battery degrading to less than 80%:
Best regards,
Paul.
The attached battery-replacements.sam file contains two PV-Battery / Residential cases that compare the "replace at specified capacity" and "replace at specified schedule" options on the Battery Life page.
The "replace at 80%" case replaces the battery when its capacity degrades to 80%.
This results in the battery being replaced three times in the 25-year analysis period:
The "replace every 10 years" case replaces the battery every 10 years, regardless of the battery capacity.
This option results in two replacements over the 25 years, with the battery degrading to less than 80%:
Best regards,
Paul.
Attachments:
Please Log in or Create an account to join the conversation.
- Peter
- Topic Author
Less
More
- Posts: 7
18 Nov 2025 01:24 #14380
by Peter
Replied by Peter on topic Battery degradation and lifetime
Hi Paul,thanks a lot for your quick reply and for preparing the example file.In my project I am modelling two different batteries in residential PV systems: a repurposed second-life battery and a new residential battery. Because detailed degradation data for second-life batteries is very limited, I am trying to represent the lifetime in SAM in a deliberately simple and transparent way based on literature values.The idea is that each battery “life” moves from 100 % to 80 % over a defined number of years (for example 5 years for the second-life battery and 10 years for the new battery), after which the battery is replaced and restarted at 100 %. To keep the model as generic as possible, I would prefer to avoid using detailed cycle or calendar degradation curves.My question is: is there a straightforward way in SAM to implement such a simplified, piecewise lifetime representation (100 % → 80 %, replace, 100 % → 80 %, replace …) without relying on the built-in cycle and calendar degradation models? Or would you recommend using the replacement options mainly to place the replacement years correctly, while keeping degradation modelling as simple as possible?Any guidance on the cleanest way to approximate this kind of simplified multi-life behaviour in SAM would be very helpful.Best regards,
Peter
Peter
Attachments:
Please Log in or Create an account to join the conversation.
- Peter
- Topic Author
Less
More
- Posts: 7
19 Nov 2025 00:51 #14384
by Peter
Replied by Peter on topic Battery degradation and lifetime
Dear Mr. Gilman,thank you very much for your fast and replyI am currently working on a research project in which I compare Second-Life lithium-ion batteries with new batteries in a techno-economic analysis. For this purpose, I use SAM to model residential PV-battery systems. The challenge I am facing is that I do not have reliable cell-level degradation parameters that describe capacity fade as a function of cycle depth. Because of this, the cycle-based degradation model in SAM is not applicable for my case.Instead, I would like to use a simplified lifetime-based approach:
A fixed replacement interval (e.g., every 8 or 10 years), during which the battery linearly degrades from 100 % usable capacity to 80 %, following typical values reported in the literature for Second-Life stationary applications. This would reflect a deterministic lifetime assumption rather than cycle-dependent aging.In principle, SAM allows replacement triggers based on State of Health, but the current SoH-based replacement option becomes computationally very slow as soon as the battery approaches lower SoH levels. In my case, simulation speed becomes impractically low once the SoH drops below approximately 50 %, making this option infeasible.My question is therefore:Is there a recommended or technically correct way in SAM to implement a simple, time-based degradation and replacement scheme (e.g., fixed annual percent fade and full replacement after a given number of years), without using the cycle degradation model and without relying on the slow SoH-based replacement trigger?Any guidance on how to best approximate this degradation behaviour in SAM would be highly appreciated.Kind regards,
Peter
A fixed replacement interval (e.g., every 8 or 10 years), during which the battery linearly degrades from 100 % usable capacity to 80 %, following typical values reported in the literature for Second-Life stationary applications. This would reflect a deterministic lifetime assumption rather than cycle-dependent aging.In principle, SAM allows replacement triggers based on State of Health, but the current SoH-based replacement option becomes computationally very slow as soon as the battery approaches lower SoH levels. In my case, simulation speed becomes impractically low once the SoH drops below approximately 50 %, making this option infeasible.My question is therefore:Is there a recommended or technically correct way in SAM to implement a simple, time-based degradation and replacement scheme (e.g., fixed annual percent fade and full replacement after a given number of years), without using the cycle degradation model and without relying on the slow SoH-based replacement trigger?Any guidance on how to best approximate this degradation behaviour in SAM would be highly appreciated.Kind regards,
Peter
Attachments:
Please Log in or Create an account to join the conversation.
- Peter
- Topic Author
Less
More
- Posts: 7
19 Nov 2025 11:46 #14385
by Peter
Replied by Peter on topic Battery degradation and lifetime
My replys dot show up for some reason...
Is the forum bugged rn?
Is the forum bugged rn?
Please Log in or Create an account to join the conversation.
- Paul Gilman
Less
More
- Posts: 5677
19 Nov 2025 17:48 #14386
by Paul Gilman
Replied by Paul Gilman on topic Battery degradation and lifetime
Hi Peter,
We moderate the SAM forum to ensure that only legitimate posts are published. You will not see your post on the forum until after we approve it. Thank you for your patience.
The approach you describe to override SAM's battery life models should work.
I think the long simulation run time is being caused by the grid outage calculations, not by the battery life calculations.
I'll need to investigate this further: I'm not sure how to trick the battery model into triggering a replacement based only on calendar degradation. I will follow up when I have more information.
Best regards,
Paul.
We moderate the SAM forum to ensure that only legitimate posts are published. You will not see your post on the forum until after we approve it. Thank you for your patience.
The approach you describe to override SAM's battery life models should work.
I think the long simulation run time is being caused by the grid outage calculations, not by the battery life calculations.
I'll need to investigate this further: I'm not sure how to trick the battery model into triggering a replacement based only on calendar degradation. I will follow up when I have more information.
Best regards,
Paul.
Please Log in or Create an account to join the conversation.
Moderators: Paul Gilman




