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

Dynamic time step with scheduling causes dividing by zero #1152

Closed
Yuriyzabegaev opened this issue Apr 26, 2024 · 1 comment · Fixed by #1188
Closed

Dynamic time step with scheduling causes dividing by zero #1152

Yuriyzabegaev opened this issue Apr 26, 2024 · 1 comment · Fixed by #1188
Assignees
Labels
bug Something is not working as expected. user group Issue to be worked on in the internal user group.

Comments

@Yuriyzabegaev
Copy link
Contributor

Dynamic time stepping is partly implemented out of the box, but can trigger a hard-to-catch error related to the time scheduling. The time step is adjusted in TimeManager.compute_time_step, which is not called anywhere, so to make it work we must do something like:

from porepy.models.poromechanics import Poromechanics
import porepy as pp
import numpy as np

class MyModel(Poromechanics):

    def after_nonlinear_convergence(
        self, solution: np.ndarray, errors: float, iteration_counter: int
    ) -> None:
        super().after_nonlinear_convergence(solution, errors, iteration_counter)
        self.time_manager.compute_time_step(iteration_counter, recompute_solution=False)

    def after_nonlinear_failure(
        self, solution: np.ndarray, errors: float, iteration_counter: int
    ) -> None:
        self.time_manager.compute_time_step(recompute_solution=True)

Now, we can set some schedule we want to match exactly and the limits for the time step, e.g., time_manager = pp.TimeManager(dt_init=1, dt_min_max=(0.1, 1), schedule=[0, 5, 10], constant_dt=False). However, at the time step 5, the scheduler will notice that we're approaching the scheduled time=5, and decrease the time step to match it exactly, see this. In our case, it will set dt to 0, which will lead to hardly traceable errors when parsing the AD equations. The full example to reproduce this is:

from porepy.models.poromechanics import Poromechanics
import porepy as pp
import numpy as np


class MyModel(Poromechanics):

    def after_nonlinear_convergence(
        self, solution: np.ndarray, errors: float, iteration_counter: int
    ) -> None:
        super().after_nonlinear_convergence(solution, errors, iteration_counter)
        self.time_manager.compute_time_step(iteration_counter, recompute_solution=False)

    def after_nonlinear_failure(
        self, solution: np.ndarray, errors: float, iteration_counter: int
    ) -> None:
        self.time_manager.compute_time_step(recompute_solution=True)


time_manager = pp.TimeManager(
    dt_init=1, dt_min_max=(0.1, 1), schedule=[0, 5, 10], constant_dt=False
)
model = MyModel(
    {
        "time_manager": time_manager,
    }
)

pp.run_time_dependent_model(
    model,
    {
        "progressbars": True,
    },
)

I realize that using the dynamic time stepping is something not fully supported now, but if you're interested, I can implement a fix for it.

@Yuriyzabegaev Yuriyzabegaev added bug Something is not working as expected. user group Issue to be worked on in the internal user group. labels Apr 26, 2024
@IvarStefansson
Copy link
Contributor

Let's discuss this issue in person, @Yuriyzabegaev.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something is not working as expected. user group Issue to be worked on in the internal user group.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants