Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Report on convergence bottlenecks always #1593

Closed
DanielTollenaar opened this issue Jun 28, 2024 · 0 comments · Fixed by #1636
Closed

Report on convergence bottlenecks always #1593

DanielTollenaar opened this issue Jun 28, 2024 · 0 comments · Fixed by #1636
Assignees
Labels
core Issues related to the computational core in Julia External request Feature requests or improvements from external users needs-refinement Issues that are too large and need refinement

Comments

@DanielTollenaar
Copy link
Contributor

DanielTollenaar commented Jun 28, 2024

What
As a modelbuilder I want to find convergence bottlenecks always. Even if my model converges during simulation I want to be able to check where there might be room for improvements in simulation efficiency and/or accuracy. The current report on convergence bottlenecks is very helpful, the key-info we navigate on in getting models running.

A database with two example-tomls can be found here: https://we.tl/t-aPHw399bTf. We suggest two improvements:

  • running hws_sturing_maxiters_metbasins.toml results in a great report. Would be better if we would find a similar report even without setting maxiters=30000 in the toml:
    image
  • setting maxiters=30005 (see hws_sturing_maxiters_metbasins.toml) does produce a crash, but doesn't provide basin-numbers:
    hws_sturing-maxiters_zonderbasins We can get a basin-list for this run, but then we we have to play with abstol and reltol to force the model in a crash wíth a report on convergence bottlenecks.

Why
The feature would make debugging models much more straight forward and less time-consuming without having knowledge/experience in how to make solvers crash :-)

How
Printing in the console and/or log would be a super-handy. It may be even more user-friendly if you can inspect in QGIS to spatially find the causes of performance bottlenecks in the database, usually faulty profiles and or flow-nodes as described in #1591.

Follow-up of #1440.

@github-project-automation github-project-automation bot moved this to To do in Ribasim Jun 28, 2024
@SnippenE SnippenE added core Issues related to the computational core in Julia improvement External request Feature requests or improvements from external users labels Jul 1, 2024
@gijsber gijsber added v1.0 needs-refinement Issues that are too large and need refinement labels Jul 4, 2024
@Jingru923 Jingru923 moved this from To do to What's next in Ribasim Jul 16, 2024
@visr visr moved this from What's next to 🏗 In progress in Ribasim Jul 18, 2024
@visr visr self-assigned this Jul 18, 2024
@github-project-automation github-project-automation bot moved this from 🏗 In progress to ✅ Done in Ribasim Jul 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core Issues related to the computational core in Julia External request Feature requests or improvements from external users needs-refinement Issues that are too large and need refinement
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

4 participants