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

fix initdt calculation #2493

Merged
merged 3 commits into from
Oct 12, 2024
Merged

Conversation

oscardssmith
Copy link
Contributor

fixes #2492.
That said, @ChrisRackauckas our initdt selection does seem like we never considered the case where iszero(u0). When this happens, our d₀ is 0, so our dt₀ = smalldt, which puts a hard cap on our return value of 100*smalldt, which is often incredibly pessimistic. Would it be reasonable to have the 2nd stage of this algorithm loop when 100dt₀ < dt₁ (i.e. we will do an extra function call at t + dt₁ to see if our dt₁ guess was reasonable. This would cost an extra function eval, but in this case, our dt₁ is 300x bigger than our d₀, which will require taking multiple steps with basically no progress before our timestepping is reasonable.

@ChrisRackauckas
Copy link
Member

Would it be reasonable to have the 2nd stage of this algorithm loop when 100dt₀ < dt₁ (i.e. we will do an extra function call at t + dt₁ to see if our dt₁ guess was reasonable. This would cost an extra function eval, but in this case, our dt₁ is 300x bigger than our d₀, which will require taking multiple steps with basically no progress before our timestepping is reasonable

Just doing some starting acceleration might make more sense. But that doesn't sound so unreasonable.

Co-authored-by: Christopher Rackauckas <[email protected]>
@ChrisRackauckas ChrisRackauckas merged commit 873f440 into SciML:master Oct 12, 2024
46 of 60 checks passed
@oscardssmith oscardssmith deleted the os/fix-initdt branch October 12, 2024 22:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Floating point error using adjoint_sensitivities when tspan includes 16f0 in v6.89.0
2 participants