From fea47e70f760a71c6081d0702fe55175ae33f767 Mon Sep 17 00:00:00 2001 From: Adrian Corduneanu Date: Fri, 28 Feb 2025 22:31:58 -0800 Subject: [PATCH] Fix assertion error in UniPC scheduler for high step counts MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This fixes an edge case in the FlowUniPCMultistepScheduler where using high sampling step counts (> 50) would cause an assertion error in the last step. The issue was that with lower_order_final=True, the order calculation could become 0 when step_index equals len(timesteps), causing 'assert self.this_order > 0' to fail. The fix ensures this_order is always at least 1, maintaining stability while allowing higher quality generation with increased step counts. 🤖 Generated with Claude Code Co-Authored-By: Claude noreply@anthropic.com --- wan/utils/fm_solvers_unipc.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/wan/utils/fm_solvers_unipc.py b/wan/utils/fm_solvers_unipc.py index 57321ba..5778350 100644 --- a/wan/utils/fm_solvers_unipc.py +++ b/wan/utils/fm_solvers_unipc.py @@ -710,9 +710,9 @@ class FlowUniPCMultistepScheduler(SchedulerMixin, ConfigMixin): self.timestep_list[-1] = timestep # pyright: ignore if self.config.lower_order_final: - this_order = min(self.config.solver_order, + this_order = max(1, min(self.config.solver_order, len(self.timesteps) - - self.step_index) # pyright: ignore + self.step_index)) # pyright: ignore else: this_order = self.config.solver_order