Suggestion on Overflow exception handling

models
1

Hi Juan, currently the simulator will be terminated immediately after encountering overflow floating point exception when evaluating the node/edge/element value.

I think it would be better if the devsim.solve function can return the overflow information and continue to the next statement instead of quitting.

This feature will benefit the sweeping. Because sometimes the overflow is induced by too large step size. And once got the overflow exception, the program can go back and try a smaller step. Just like the following process:

while v_prev < target:
    result=devsim.solve(type="dc", absolute_error=1e10, relative_error=1e-3, maximum_iterations=30,info=True)

    if result['is_overflow'] :
        v_step  *= decr_factor
        if v_step<v_step_min :
            [...]
            break

        v = v_prev + v_step

        continue
    else:
        [...]
        step_size *= incr_factor
        v_prev = v
        v = v_prev + step_size
1 Like
2

It would take a little bit of work to get the simulator to restore the previous solution, if there was a math exception. What I have typically done is make sure the math functions do not overflow. For example, with density gradient:
devsim_density_gradient/dg_common.py at main · devsim/devsim_density_gradient · GitHub

    expression="0.25*%s*1e8*(1e-4*d_l_%s)^2" % (parameter_name, carrier_name)

where in this case the model by 1e-4 before it is squared and then multiplied by 1e8 outside of the function. I found that this was sufficient to prevent overflow.

Similarly, for circuit simulation, SPICE developers have a limexp function to prevent overflows when evaluating the exp function in their models. What function is overflowing for you?

By preventing overflows in such a manner, this would allow the simulation to stop for non convergence.

3

Thanks for your reply. I frequently meet overflow error when evaluating exp function. I’ll try your tricks.

4

Please see the testing/testfunc.py example. It shows how you can use register_function to create new functions for evaluation. It also demonstrates how the symdiff command can be used to declare the symbolic derivatives for the new function. If needed to run faster, I am also willing to implement them in C++, as I have done in recent releases for the erf and erfc inverse functions, and the Gauss-Fermi integrals.

5

Hello @akirt, I am considering adding a maximum abserror option to the solve command, so the simulation will stop before going to an overflow. For example, setting a maximum error of 1e21 will stop the simulation if the number of electrons or holes goes to an unphysical number, and will not likely converge. The script can then reduce the bias step so that another attempt can be made to complete the simulation. Does this seem like it would be useful to your situation?

6

Hi Juan. Great Job! The feature you introduced is exactly what I’m looking for.
Looking forward to the next release version and thanks a lot for your effort.

7

Hello @akirt,

Please see the new release:
Release Version 2.0.0

There are some additional options for the solve command, maximum_error and maximum_divergence. These options should make it possible to keep the simulation from diverging too far.