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.

Possible comsol underflow bug revealed by coaxial_cable_transient Verification Example

Please login with a confirmed email address before reporting spam

I'm using the coaxial_cable_transient verification example from the RF module. I noticed that by default the calclulated fields have an immense amplitude of 1E13 V/m (I guess by default this gives the 50ps gaussian pulse a unit area). That seemed awkward, and I prefer to have field amplitude normalized to 1(V/m) so I multiplied the input pulse by a 1E-13 scalar to give it a unit amplitude. That's all I did. I put a 1E-13* in front of the V0(t) in the Voltage parameter for Lumped Port 1 to try to get things nearer to 1 V/m.

Much to my surprise, this seems to totally break the simulation. The wave pulse gets about halfway into the coax and then disintegrates. The solver terminates very quickly. No error or warning is given, but the simulation is clearly wrong. I tried other scale factors. Everything seems to work down to 1E-8, but starts to go to hell at around 1E-9.

Is there some underflow bug in Comsol? Or is this some well known scaling limitation? I'm running Comsol 5.1. Please don't lecture me about upgrading. Why would a simple scale factor on the fields break things in any version? I just want to know if this bug is really there, or if I'm dumb for thinking I can normalize the input pulse to 1 V/m in this verification example. Maybe I need to click on some arcane solver option to get past this? Thanks if you can help.


9 Replies Last Post Apr 6, 2021, 8:41 a.m. EDT
Robert Koslover Certified Consultant

Please login with a confirmed email address before reporting spam

Posted: 4 years ago Apr 1, 2021, 3:49 p.m. EDT
Updated: 4 years ago Apr 1, 2021, 3:55 p.m. EDT

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.

-------------------
Scientific Applications & Research Associates (SARA) Inc.
www.comsol.com/partners-consultants/certified-consultants/sara
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.

Please login with a confirmed email address before reporting spam

Posted: 4 years ago Apr 1, 2021, 4:24 p.m. EDT

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.

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.

Please login with a confirmed email address before reporting spam

Posted: 4 years ago Apr 1, 2021, 8:04 p.m. EDT

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'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.

Please login with a confirmed email address before reporting spam

Posted: 4 years ago Apr 2, 2021, 2:59 p.m. EDT

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.

>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.

Please login with a confirmed email address before reporting spam

Posted: 4 years ago Apr 2, 2021, 4:54 p.m. EDT

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.

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.

Please login with a confirmed email address before reporting spam

Posted: 4 years ago Apr 2, 2021, 5:34 p.m. EDT

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.

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.

Jeff Hiller COMSOL Employee

Please login with a confirmed email address before reporting spam

Posted: 4 years ago Apr 2, 2021, 5:36 p.m. EDT
Updated: 4 years ago Apr 2, 2021, 5:36 p.m. EDT

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

-------------------
Jeff Hiller
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


Please login with a confirmed email address before reporting spam

Posted: 4 years ago Apr 6, 2021, 8:16 a.m. EDT

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.

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.

Please login with a confirmed email address before reporting spam

Posted: 4 years ago Apr 6, 2021, 8:41 a.m. EDT

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.

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.

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.