Working on Convergence Issues
Today I took out a few minutes to check on the convergence issues that I remembered were in shark, the simulator that I had originally written as part of the Ph.D. thesis while at Purdue. The big problem originally was that there wasn't a machine fast enough to give me real, solid, answers to the questions of the physics of the problem. At least not in 1988. Now, it's a little different story and yet I remembered that I was still troubled by some convergence issues, so I wanted to take a look and see if there was an easy solution to the convergence issues.
The code tries to 'step' the bias on the device from the initial equilibrium state to the requested bias point. This is a classic problem in modeling - if you can't get a reasonable initial guess to the solution, then back-off on the initial state and see if you can get that guy solved. If you can, then use that as the initial guess for the next 'step' in the bias ramp-up. Seems reasonable, and it works pretty well.
One clever trick is to look at the difference between the values at each node from one bias point to the next, and then scale that for a better initial guess at the next bias point. In theory, it should get you closer to the next bias point than the last state, and therefore get you to the solution even faster. Problem is that if you don't get the "jump" right you can make the situation worse for yourself. And that's what was happening in the code. I was overshooting the change, which is not really surprising as this is a massively non-linear system and I was trying to assume for the bias changes it was linear. Not good. When I took that out of the code, it got to the right values fast enough and a lot more controllable.
The right solution might be to look at the last two points and allow the change to be second-order. It's better than linear, but I have a feeling that even that isn't going to be good enough at predicting the solution to warrant the cost, and uncertainty, of using the "jumps" in the biasing of the device. But if I wanted to try something else, I'm guessing an a logarithmic scale is probably closer to 'right' than even a second-order approximation.
At this point, all the tests check out and it looks pretty good. The next thing to do is to put in the input deck for the drifting packet that was the problem that couldn't get solved in 1988. It'll be interesting to see how long it's going to take with modern desktop computer hardware. My guess is it'll work, and be on the order of days, but it'll generate answers.