Note: This discussion is about an older version of the COMSOL Multiphysics® software. The information provided may be out of date.
Discussion Closed This discussion was created more than 6 months ago and has been closed. To start a new discussion with a link back to this one, click here.
Error: Failed to find time step so that given tolerances are satisfied
Posted May 4, 2012, 4:03 a.m. EDT Studies & Solvers Version 4.2, Version 4.2a 3 Replies
Please login with a confirmed email address before reporting spam
Error: Failed to find time step so that given tolerances are satisfied
This is the error that Generalized-alpha gives. I think the BDF solver in similar cases gives the error
"Cannot meet error tolerances. Increase absolute or relative tolerance."
This happens in odd situations. For example, I have a parameter that, if I set it to 0.1, the error doesn't happen, 0.15, it DOES happen, for 0.2, 0.3, 1.0, it doesn't happen. If I adjust the absolute tolerance, then for 1.0 it DOES happen, but for 1000 it doesn't happen. There seems to be no clear way to characterise when it occurs. All I know, is that it happens around the same time in the simulation as a boundary condition changes according a (smoothed) step function (in time). There is a generous amount of smoothing.
My question is: Why does it happen at all?
In my general understanding of solvers, there should always be a reasonable time step at which the error will be small enough. If there is too much error, then we reduce the time step. And this is what the solvers seem to be doing. But all of a sudden, there is a time in the simulation, when reducing the time step by 5 or 6 orders of magnitude, compared to what's normally needed, does not reduce the error enough.
I'm trying to build an understanding of this behaviour.
I've tried adjusting many of the solver parameters. So far, most of them don't have an effect on the issue, except Amplification for high frequency. (This is for Generalized alpha.) What is this, and why does it make a difference? I've checked the User and Reference documentation, and there is very little information, except to say that it's "damping of higher frequencies".
This issue is really causing a lot of trouble. Even at fairly modest amplitudes of the step in BCs.
This is the error that Generalized-alpha gives. I think the BDF solver in similar cases gives the error
"Cannot meet error tolerances. Increase absolute or relative tolerance."
This happens in odd situations. For example, I have a parameter that, if I set it to 0.1, the error doesn't happen, 0.15, it DOES happen, for 0.2, 0.3, 1.0, it doesn't happen. If I adjust the absolute tolerance, then for 1.0 it DOES happen, but for 1000 it doesn't happen. There seems to be no clear way to characterise when it occurs. All I know, is that it happens around the same time in the simulation as a boundary condition changes according a (smoothed) step function (in time). There is a generous amount of smoothing.
My question is: Why does it happen at all?
In my general understanding of solvers, there should always be a reasonable time step at which the error will be small enough. If there is too much error, then we reduce the time step. And this is what the solvers seem to be doing. But all of a sudden, there is a time in the simulation, when reducing the time step by 5 or 6 orders of magnitude, compared to what's normally needed, does not reduce the error enough.
I'm trying to build an understanding of this behaviour.
I've tried adjusting many of the solver parameters. So far, most of them don't have an effect on the issue, except Amplification for high frequency. (This is for Generalized alpha.) What is this, and why does it make a difference? I've checked the User and Reference documentation, and there is very little information, except to say that it's "damping of higher frequencies".
This issue is really causing a lot of trouble. Even at fairly modest amplitudes of the step in BCs.
3 Replies Last Post Apr 10, 2014, 4:55 a.m. EDT
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
I have found a way around the problem. First of all, as I mentioned above, Amplification for high frequency helps, and I still don't know why, and what exactly is it doing.
The second way, which I am now using, and that makes sense, is to manually specify fine time steps around the transitions in the time-dependent BCs (where any sharp transitions should be smoothed). To do that, the time steps should be specified in the "Times" field. I use syntax like
range(0, 1[us], 8[us]) range(9[us], 0.1[us], 10.9[us]) range(11[us], 1[us], 100[us])
(Watch out that the end of one range is not exactly equal to the start of the next range. Under some conditions this leads to weird errors and aborted simulations.)
In the above, I might have a transition around 10 µs, which lasts for 2 µs, so I let Comsol take 10 smaller steps during that transition.
To have the solver actually take steps there, Strict or Intermediate should be used.
The reason that problems appeared when not doing something like this, was that the solver could take a large step, for example a 3 µs step which ends within a transition of duration 2 µs. When it then tries to find the appropriate next step, it tries a diminishing sequence of step sizes, down to extremely small, like 1e-7 µs, that is 0.1 ps, or thereabouts, and doesn't manage to satisfy the error conditions for any of those, so gives up with an error.
See also Ivar's post about this: www.comsol.com/community/forums/general/thread/9826/#p25591
The second way, which I am now using, and that makes sense, is to manually specify fine time steps around the transitions in the time-dependent BCs (where any sharp transitions should be smoothed). To do that, the time steps should be specified in the "Times" field. I use syntax like
range(0, 1[us], 8[us]) range(9[us], 0.1[us], 10.9[us]) range(11[us], 1[us], 100[us])
(Watch out that the end of one range is not exactly equal to the start of the next range. Under some conditions this leads to weird errors and aborted simulations.)
In the above, I might have a transition around 10 µs, which lasts for 2 µs, so I let Comsol take 10 smaller steps during that transition.
To have the solver actually take steps there, Strict or Intermediate should be used.
The reason that problems appeared when not doing something like this, was that the solver could take a large step, for example a 3 µs step which ends within a transition of duration 2 µs. When it then tries to find the appropriate next step, it tries a diminishing sequence of step sizes, down to extremely small, like 1e-7 µs, that is 0.1 ps, or thereabouts, and doesn't manage to satisfy the error conditions for any of those, so gives up with an error.
See also Ivar's post about this: www.comsol.com/community/forums/general/thread/9826/#p25591
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
Hi
you are right the default solver assumes a diffusion type equation (exponential decay or increase), for which interpolation works well,
But for time varying or harmonic signals this hypothesis is violated. Therefore ALWAYS use strict or intermediate time stepping (manual setting of node) for periodic signals
--
Good luck
Ivar
you are right the default solver assumes a diffusion type equation (exponential decay or increase), for which interpolation works well,
But for time varying or harmonic signals this hypothesis is violated. Therefore ALWAYS use strict or intermediate time stepping (manual setting of node) for periodic signals
--
Good luck
Ivar
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
Evgeni Sergeev, my friend, you are a life/time saver :)