You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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?
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.
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.
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?
The text was updated successfully, but these errors were encountered: