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.

Asynchronous Machine time dependent startup, singularity error

Norbert Bartscher
Hello,

I am trying to simulate a ASM in the rotating machines physics, time dependent.
The Stator slots are coupled to the electrical circuit physics for a Voltage excitation
The rotor slots are also coupled there to define the short circuit resistants.
I am using the ODE Interface for a rotation velocity equation.

When simulating for 20ms, with a timestep of 1ms(or less), everything is fine (rotor slowly starts rotating).
But when I want to calculate for a longer time, the computation stops somewhen in the middle, saying something like:

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

I choose the mesh as extremely fine and tried a step size of 55us.
As "Maximum Step" and "Initial Step" I'm using the same value as for "Step Size".
But it does not help...

Does anybody have any advice?

Thanks in advance




8 Replies Last Post Apr 9, 2013, 3:39 PM EDT
COMSOL Moderator

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.


Posted: 6 years ago Feb 18, 2012, 4:56 AM EST
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)
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)

Evgeni Sergeev
Posted: 6 years ago Apr 17, 2012, 3:54 AM EDT
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)?
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)?


Evgeni Sergeev
Posted: 6 years ago Apr 18, 2012, 2:39 AM EDT
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.
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.

Posted: 6 years ago Apr 20, 2012, 4:47 AM EDT
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.

Posted: 5 years ago Apr 7, 2013, 11:52 PM EDT

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
[QUOTE] 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. [/QUOTE] 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

Posted: 5 years ago Apr 8, 2013, 12:53 AM EDT
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 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

Posted: 5 years ago Apr 8, 2013, 1:53 AM EDT
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 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


Posted: 5 years ago Apr 9, 2013, 3:39 PM EDT
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
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

Note that while COMSOL employees may participate in the discussion forum, COMSOL® software users who are on-subscription should submit their questions via the Support Center for a more comprehensive response from the Technical Support team.