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

Provide timestep size "quality metric" #80

Open
dschwen opened this issue Oct 22, 2020 · 2 comments
Open

Provide timestep size "quality metric" #80

dschwen opened this issue Oct 22, 2020 · 2 comments

Comments

@dschwen
Copy link
Contributor

dschwen commented Oct 22, 2020

It would be neat if NEML could provide some feedback to the embedding code about the suitability of the current timestep.

My problems reported in the other issue basically vanished when I manually cut the timestep at a critical point in the simulation. I was ramping up the temperature and let MOOSE increase the timestep as the solve converged very well, but at a certain temperature the simulation went from converging very well to failing during NEML stress updates. There is not indicator that MOOSE can use to prevent a runaway increase in timestep to avoid the NEML failures in the first place. I'm still trying to figure out why MOOSE doesn't even cut the timestep reliable when the NEML failure occurs, but that's an orthogonal problem.

Is there a way to query the number of internal NEML iterations maybe?

@reverendbedford
Copy link
Collaborator

reverendbedford commented Oct 22, 2020

  1. We can work on something like this. One option is the number of nonlinear iterations. Another is the increment in the equivalent inelastic strain which most (though not all) NEML models store as an internal variable. Other solvers (e.g. ALE3D) use that number to control the global timestep. Any preference on which one of these things to provide or the API for sending info back?

  2. That said, we typically just let NEML signal to MOOSE that the time step needs to be cut. See here as an example. I've never noticed any trouble in convincing MOOSE to cut the global time step. It can be less efficient than (1) in cases where MOOSE is trying to increase the step and NEML is fighting it (you can get things like MOOSE repetitively trying to double the time increment, failing, halving it, succeeding, and so on, doubling the number of required global time steps). But those situations aren't too common.

@dschwen
Copy link
Contributor Author

dschwen commented Oct 22, 2020

The strain increment would be useful physical quantity to have, the non-linear iterations would be useful for a heuristic stepper that does not require in depth knowledge of a particular model.

Yeah, I had some issues with the exception based timestep cutting and besides efficiency there might be accuracy reasons for capping the strain increment.

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

No branches or pull requests

2 participants