Timestep regridding for 1D solver#2074
Conversation
|
I don't know how to edit the PR header, but this isn't a WIP anymore. |
speth
changed the title
|
Based on the tests that are failing and timing out, it seems like this is affecting the solution of steady-state reactor networks, which also use the |
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #2074 +/- ##
========================================
Coverage 77.71% 77.71%
========================================
Files 452 452
Lines 53316 53421 +105
Branches 8894 8909 +15
========================================
+ Hits 41432 41516 +84
- Misses 8870 8888 +18
- Partials 3014 3017 +3 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
wandadars
force-pushed
the
timestep_regridding
branch
from
bbd68d4 to
0fe8f72
Compare
speth
left a comment
speth
left a comment
There was a problem hiding this comment.
Thanks for putting this together, @wandadars. I think there are some useful ideas here. What we need now is something to show that. If there are any very simple cases where this can be exercised, it would be great to add them to the test suite. Besides that, we should add a new example demonstrating these options and cases where they have a beneficial impact on solver convergence (and perhaps when they don't).
|
Thanks for the updates, @wandadars. I just wanted to check, is this ready for another review? |
|
Yes @speth I think so. Sorry for the delay. |
|
I combined the examples and refactored them significantly for style. After that, I spent some time playing with the different timestep growth strategies implemented. Here is what they do for a more complex diffusion flame than the one in the original example (now including regridding). For all the examples I've tried, it seems like most of the new strategies give more or less the same behavior as the current "fixed-growth" option, with the exception of the "newton-iterations" approach which is often significantly worse in terms of run time: 
Are there some other cases you saw more dramatic benefits from implementing these alternative time step growth strategies? |
|
IIRC, I think the only one that really seemed to have any improvement was the high pressure case. But I have since changed the approach that I was using to get the high pressure solutions from stepping up solutions and using the last one as the initial condition to using a similarity solution for the initial condition, which had much better performance. So that attempt to squeeze out any speed by using different heuristics was a bit of a moot point for the application that I was using to judge them. I'm all for axing them if they're not showing any improvements for the various cases that Cantera considers. |
|
I went back and ran some cases with larger mechanisms like the gri30 one, and it does seem like at least some subset of those heuristics seem to give a performance improvement. I may be missing some important context here that makes these results not as difference as they seem at face value here. I'll provide the script that generated them for context. If anything the fixed, steady norm, and the newton iterations variants seem to show promising results. The others, not so much. Details#!/usr/bin/env python3 This script is intentionally more expensive than the example-sized runner. It
from future import annotations import argparse import cantera as ct matplotlib.use("Agg") SCRIPT_DIR = Path(file).resolve().parent @DataClass(frozen=True) @DataClass(frozen=True) STRATEGIES = ( def cantera_datafile(name: str) -> str: H2O2 = cantera_datafile("h2o2.yaml") def make_h2o2_counterflow_premixed() -> ct.CounterflowPremixedFlame: def make_gri30_methane_burner() -> ct.BurnerFlame: def make_gri30_methane_burner_refined() -> ct.BurnerFlame: def make_gri30_twin_premixed() -> ct.CounterflowTwinPremixedFlame: def solve_auto(flame: ct.FlameBase, loglevel: int) -> None: SCENARIOS = ( def sum_stats(values: list[int] | list[float]) -> float: def finite(value: float | None) -> bool: def growth_tag(growth_factor: float) -> str: def run_one( def row_key(row: dict[str, object]) -> tuple[str, str, float]: def write_csv(path: Path, rows: list[dict[str, object]]) -> None: def format_value(value: object, digits: int = 4) -> str: def markdown_table(headers: list[str], rows: list[list[object]]) -> str: def write_summary_md(path: Path, rows: list[dict[str, object]]) -> None: def write_timestep_history(path: Path, dts: np.ndarray) -> None: def write_temperature_profile(path: Path, grid: np.ndarray, temperature: np.ndarray) -> None: def plot_growth_sweep( def plot_strategy_bars( def plot_timestep_histories( def normalized_rows(rows: list[dict[str, object]], scenario_name: str, growth_factor: float) -> list[list[object]]: def write_report( def parse_args() -> argparse.Namespace: def main() -> None: if name == "main": Some of the plots for the cases that the script runs through. This one is a methane case with a max growth factor of 20. This is the same case on a larger grid. 
And this is a premixed flame case. These are larger grids with larger mechanisms where some differences seem to be showing up. |
Thanks for sharing that set of results and the script. I think what I was missing is that the "growth strategies" matter most when you substantially increase the |
…ng controls, add tests for new options
…here a remove only grid
speth
force-pushed
the
timestep_regridding
branch
from
7879319 to
b797be0
Compare
|
@wandadars - Thanks again for the additional exploration of the effect the different options have on convergence rate. I updated the conditions in the example based on this to show a case where a couple different time step growth strategies do better than the default, using the |
3 participants
During a discussion on the users group, Ray mentioned that Cantera doesn't perform any regridding if timestepping fails during a solve. This pull request is an attempt to add a capability to the 1D solver that would allow for a regrid to happen if there is a failure in the timestepping. This feature allows for a set number of regridding steps to be taken during a failure of the timestepping. The test case that we were looking at was that of a pressure field being stepped up incrementally on a counterflow diffusion flame domain. The highest pressure possible was increased when the timestep regridding is allowed. This happens when cases have a bad initial condition or a coarse grid and fails right at the start during the timestepping phase.
This is Ray's script that I tweaked a bit and used to test the regridding.
Details
AI Statement (required)
-Extensive use of generative AI.
Significant portions of code or documentation were generated with AI, including
logic and implementation decisions. All generated code and documentation were
reviewed and understood by the contributor. Examples: Output from agentic coding
tools and/or substantial refactoring by LLMs (web-based or local).
Checklist
scons build&scons test) and unit tests address code coverage