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.
Not converged but correct?
Posted Dec 23, 2014, 1:45 p.m. EST RF & Microwave Engineering Version 5.0 2 Replies
Please login with a confirmed email address before reporting spam
I'm doing a 3D EM waveguide problem with boundarymodeanal + frequency domain. My solution looks accurate and passes numerous checks inculding matching almost exactly with theory and 2D and 3D variously simplified yet similar models that show no convergence issues at all.
The thing is, the 3D solver isn't "converging" for my full up model. Most recently I've been using GMRES and it flatlines when the error gets down to about 5. At this point I'll hit the STOP button on GMRES and accept the results. BiCSTAB also fails to converge (but seems more erratic than GMRES).
As I said, these results look evedently correct; I've studied them quite a bit, and they look good, yet no doubt there is a high error hiding in some nook or cranny someplace. Does anybody know a good trick for localizing where a convergence problem is "lurking" in a generally correct EM wave frequency domain solution? For example, if an error field could be plotted across the 3D mesh rather than just as a single "ERROR" number, it would help a lot.
The thing is, the 3D solver isn't "converging" for my full up model. Most recently I've been using GMRES and it flatlines when the error gets down to about 5. At this point I'll hit the STOP button on GMRES and accept the results. BiCSTAB also fails to converge (but seems more erratic than GMRES).
As I said, these results look evedently correct; I've studied them quite a bit, and they look good, yet no doubt there is a high error hiding in some nook or cranny someplace. Does anybody know a good trick for localizing where a convergence problem is "lurking" in a generally correct EM wave frequency domain solution? For example, if an error field could be plotted across the 3D mesh rather than just as a single "ERROR" number, it would help a lot.
2 Replies Last Post Dec 26, 2014, 11:13 a.m. EST
Please login with a confirmed email address before reporting spam
Posted:
10 years ago
I'm finding some joy by increasing the "Number of iterations before restart" in the GMRES solver. The "restart" seems to stagnate the solver for some reason. By increasing this number, convergence contiues on.
What I want as a gift for the holidays is for something to make this seem less like black magic :)
--
C
What I want as a gift for the holidays is for something to make this seem less like black magic :)
--
C
Please login with a confirmed email address before reporting spam
Posted:
10 years ago
Yes, I used to see this same problem fairly often, back in the days when we all had less powerful computers and earlier COMSOL versions. The direct solvers (e.g., PARDISO) are more robust, but take more memory. I think you may be able to persuade GMRES to converge better if you take steps to increase the mesh quality (adjust the geometry and adjust various mesh parameters), but I don't think there is any guarantee. I found that using the SSOR vector pre-conditioner was often best with GMRES, but it still wasn't that great. It is interesting that you found some success by increasing the "number of iterations before restart" value. Overall, I think what you should probably have asked for, for Christmas, was a better computer with a whole lot more RAM, so that you could run PARDISO instead of GMRES. Good luck and happy new year.