Discussion Forum

Hello Norbert Bartscher

Your Discussion has gone 30 days without a reply. If you still need help with COMSOL and have an on-subscription license, please visit our Support Center for help.

If you do not hold an on-subscription license, you may find an answer in another Discussion or in the Knowledge Base.

I actually have the same problem. I tried running a time-dependent study for an oscillating cantilever using sinusoidal force load at 60Hz. The simulation seems to run fine during the first 20+ cycles, but when I continue beyond that I get the same error:

Repeated error test failures. May have reached a singularity.
Time : 0.421315750212288
Last time step is not converged.

I'm stepping at 100 steps per cycle and am using a Strict BDF time stepping method. For some reason the solver freaked out on the 21st cycle. This seems like a common error/failure when running simulations for long time ranges. Is there maybe a way to perform this as a "multi-step" problem? (i.e. Solve for 0-20 cycles + 20-40 cycles)

Hello all,

I decided to post here instead of making a new thread, because there seems to be a trend with this type of error, and no answers on the forums yet.

I have the same general symptoms as above: Time-Dependent solution proceeds fine for some time. Then, all of a sudden, the "Reciprocal of step size" on the convergence plot goes to 10^14 and stays there. (See attached convergence plot.)

Some supporting information:

• Sometimes, after thousands of time steps all around 10^14 it says "The following feature has encountered a problem: Repeated error test failures. May have reached a singularity. Time: .... Last time step is not converged. - Feature: Time-Dependent Solver 1 (sol1/t1)"

• Changing the BDF time-stepping to Strict and decreasing the maximum step size arbitrarily, still leads to this error.

• The behaviour of trying to terminate the process (as it's obviously not making much progress towards terminating, if it goes in time steps of length 10^-14) is (whether I press the round red button with a white cross on the status bar, OR use the Stop buttons on the Progress tab) that the convergence plot accelerates (!) and so does the activity in the Progress tab, while CPU activity goes to zero on all but one CPUs. I'm interpreting this as a bug where it's trying to process results coming in from the server after I cancelled the simulation i.e. I don't need the results.

• See the convergence plot attached.


Note that, as with the others, the simulation runs acceptably for about 100 ms. I am simulating neurons, and the neuron spikes a couple of times, and everything is fine. Suddenly we see this problem. It's not related to any features of the dependent variables or their gradients — it happens away from sharp transitions in any of them, as I can see if I plot "Results While Solving".


My question is: how can I find out which of the dependent variables (I have 4) fails the error test (which is what must be driving the time step to very small)?

Update: I've noticed that, however I set the maximum step size for Strict BDF, the problem always occurs at solver step 300. This could be at 10 ms into the simulation, 50 ms, 100 ms — this depends on the maximum step size setting. So it definitely does not matter what the values of the dependent variables are at the time that it happens — these are different at the different times into the simulation. The simulation runs its normal course. The error always occurs at iteration 300.

• This happens in stand-alone Comsol, as well as running in client+server mode.
• Not a memory issue: Comsol is using under 400 MB, and there are 2+ GB of system memory available if it wanted.

This affects only the BDF solver. Switching to Generalised Alpha avoids the problem behaviour.

I came to the same conclusion as Evgeni. I ended up using Manual Generalized Alpha time stepping and defined my specific time steps. This solved my problem without convergence errors. Hope this helps others.

I came to the same conclusion as Evgeni. I ended up using Manual Generalized Alpha time stepping and defined my specific time steps. This solved my problem without convergence errors. Hope this helps others.

Many thanks to all the people who have contributed here. I had a pulsing BC and I couldn't extend my simulation beyond the first pulse. But using the tips mentioned above I could get upto 100 pulses. This is a very useful thread for topics such as "pulsing"

Best,
Sanket

Hi

I believe the main issue must has been the free / automatic stepping, using intermediate and enough steps per pulse should solve such issues

--
Good luck
Ivar

Hi ivar,
There are extensive discussions about pulsing in the KB and discussion forum. I think the general tips for modeling pulsing behavior can be summed as follows-

(1) Change from "free" to "intermediate" time stepping
(2) Using a smaller time step so that the transition regions are sufficiently resolved
(3) Use a finer mesh.

I have tried to implement all these but I couldnt' get beyond 1 pulse. I guess my model maybe a little different. I found using generalized alpha time stepping scheme I have been able to implement a greater number of pulses. But I assume this is at the expense of accuracy. As a matter of fact, I do see some negative concns in my domain. But dealing with those is a different topic altogether. Do you have any idea why how I can get as many pulses as possible without compromising on accuracy ?

I have attached a brief model description.
Many thanks,
Sanket

Hi

I agree with 1) and 2), but 3) not necessarily, the mesh density is there first of all to resolve the dependent variables and their fluctuations (gradients, if not 2nd derivatives) the time solver might or not require a given mesh density related to the time steps, this is true particularly for the diffusion type equations (HT, chemistry, CFD ...)

but you might have a mixed case ;)

--
Good luck
Ivar