Suggestion on Overflow exception handling

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

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.

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

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.