Discussion Forum

Interesting. This appears (to me) to be a solver-related step decision-making algorithm issue. I'm running v. 5.6, but yes, I can see similar behavior. For what it is worth, I also see that if I go to "Study Settings" under the Settings panel, and reduce the "Relative tolerance" from .0001 to 1e-6, the computation then becomes stable and runs successfully to the end, but the result appears less accurate than in the original run (errors are appearing). Reducing the Relative tolerance to 1e-7 works better, but takes much longer to run -- so that's a clue as to what is going on, I think! If, under "Time-Dependent Solver 1," you look at Time Stepping, the method there is Generalized alpha, and steps taken by solver = free. This is sometimes a recipe for disaster in time-domain computations, because the code has to figure out for itself what time step to take. You might want to consider changing those settings to something stricter. Anyway, try the above ideas and see if (or how well) it works for you. Meanwhile, perhaps another user who knows more about the details, or one of the Comsol staff, would like to comment? Good luck.

See also: https://www.comsol.com/support/knowledgebase/1062 and https://www.comsol.com/support/knowledgebase/1262 and https://www.comsol.com/support/knowledgebase/1254 among others.

Thank you for confirming the issue. Personally, I would consider it a bug because (IMHO) general amplitude scaling of a linear system shouldn't affect a solution convergence if the solver's floating point innards are done correctly. I can't help but wonder if they noticed this bug in the "validation example" and chose to, ummm... "fix" it, by leaving the amplitude at that crazy ten-trillion volts.

I did play a little with the relative tolerance and saw mixed results as you did.

Since this feels like a solver arithmetic bug, I'm not inclined to workaround it by tuning solver options -- unless somebody knows for sure that's a safe approach. I'll just run my coax pulse problems at ten-trillion volts and scale down to reasonable numbers in post processing.

I've had the occasional problem with transient solutions diverging (or, more accurately, diverging too soon). If I remember right specifying the scaling instead of using automatic scaling solved the problem.

I don't know if the allowable range of numerical values is specified but surely one cannot expect it to be infinite.

I don't know if the allowable range of numerical values is specified but surely one cannot expect it to be infinite.

On the other hand, if I'm simulating a 50 ps pulse in a coaxial cable -- something that's pretty routine -- I would NOT expect that the pulse amplitude in the simulation needs to be ten-trillion volts in order for the solver to converge properly. I would naturally assume that a 1 volt amplitude would keep me far from numeric trouble.

Perhaps COMSOL's "limitation" here is yet another disadvantage of FEM as compared to FDTD for these sorts of problems? I've never needed a ten-trillion volt amplitude when running these sorts of problems with CST. But honestly, it just seems like a solver bug.

For fun, I tried a simple step driving the coax, rather than a pulse, and even with a step I need to make the amplitude a trillion volts for the model to work right. If I use a 1 volt step the results are garbage in the sub-nanosecond timescale.

I think maybe the temw solver isn't able to work correctly for this timescale.

I can get a coax to simulate correctly with a 1 volt input if I control the time step manually, cranking it down manually to a picosecond. So it's definitely a time-step estimation bug. If I had to guess what the bug is, I'd guess that the time step estimator doesn't adequately consider the timescale being specified in the study setting and the "adaptive" aspect of the step size algorithm isn't quick enough to recover from such an initially bad guess (10 orders of magnitude off) unless "incentivized" by a ten-trillion volt amplitude.

If COMSOL doesn't want to fix this bug, at a minimum they should explicitly show the need to manually control the step size in this validation example, and run the coax at 1 volt. The hack of setting the input amplitude to ten trillion volts is kinda' sleazy, IMHO. Ten trillion is not a reasonable voltage for any coax I've ever encountered.

Hi Chris,

The model is using a pulse that gives a maximum Magnetic vector potential (A) of the order 1e2. This A field is the only dependent variable, and what matters for the numerical method. The E field and other postprocessing variables are not relevant for scaling or for termination of the solver methods.

The automatic scaling is not being able to pick up the correct A-scale since it is not considering any transient (boundary) data or behavior. It is based on initial values, zero here, which leads to a fall back to “1”, which works fine here for the port-pulse size in the model. When the pulse is scaled, naturally the “A” field is changed. But the automatic scaling does not pick this up, it is still “1”, and very off. By correcting this by using Manual scaling A ~ 1e2 * 1E-13 = 1E-11, things are just fine. The model can then be improved further by using a manual time-step of 5e-13 and the model solves in 9 s on a standard machine, with good accuracy. Attached is a screenshot from COMSOL version 5.6 with the “normalized” E field. Both open and matched BC are shown. Observe that with manual time-step the model is not as sensitive to the correct scaling since the time-step is not selected based on error estimates anymore (which requires correct scales). But in general also for this case proper scaling is needed, since else the algebraic problem (solved in each time-step) can be off.

Best,

Jeff

Thank you @Jeff for explaining that the A field is what matters for the numerics. This will allow me to proceed with some confidence that I know what the problem is, and how to avoid it.

I do still wonder what priorities for temw led to having 1 volt on a coax as "scaled", requiring manual considerations; and a billion volts to be where things work naturally. It is, after all, the "transient" emw physics. Are there real-world problems where the default makes sense? I'm sure you know that a billion volts on a coax is not phyically reasonable. At least, a discussion of this scaling issue should have been part of the documentation for this "validation" example.

In any case, thanks again for clarifying.

By the way, the standard coaxial_cable_transient example does openly discuss control of the mesh in order to correctly analyze a real world coax in terms of its typical physical dimensions, which have important transverse field structure in the "skinny" aspect ratio. No doubt, the coax dimensions could have been adjusted (made grossly unrealistic) to allow the problem to solve correctly with the standard mesh -- as the amplitude was made grossly unrealistic to make the problem solve correctly with the standard time step algorithm.