Floating point overflow when calculating Jn

[Hay]

Hello,author:
I now have a problem that may be complicated to describe from the beginning. I’ll pick the highlights:

I’ve changed the silicon parameters to silicon carbide and removed those two models to calculate the current density directly

The three parameters NC300 NV300 EG300 caused the problem, which is as follows:

Of course I changed “mu_n” and “mu_p”,but this is not the main reason, because I can run the programme normally without changing the three parameters NC300 NV300 EG300, as shown below:

That said, I could run silicon carbide with silicon parameters, but that’s certainly not right.

I can guarantee that these three parameters are accurate for the silicon carbide I am using, and I would like to ask what I should do to solve this problem, whether I should replace Jn’s equation or what I should do

[Juan]

For such a wide bandgap, I don’t expect standard floating precision to be able handle the large order of magnitudes between electrons and holes.

At the very top of your script try using:

devsim.set_parameter(name = "extended_solver", value=True)
devsim.set_parameter(name = "extended_model", value=True)
devsim.set_parameter(name = "extended_equation", value=True)

[Hay]

Hello,author:
After I added these three sentences, the calculation of Jn seems to be done, and now the question arises:

I changed:

[Juan]

For each sweep, the simulations may not run through all of the biases before failing. If those biases are of critical importance, you may need to experiment with your mesh, or bias ramp settings to see if you can get the simulations to proceed further. Reducing the minimum step may get the simulation to proceed further.

[Hay]

Hello,author:

I tried ten biases of Vb from 0.1-1.0V and found the same problem with all of them.

At the same time I made both init_step_size and min_step as small as possible, and the program still won’t go on.

The mesh is using your mesh, do you see any other way to make the program work, like you did before by adding or subtracting a few words?

[Hay]

zhenyujiang1/bjt: python (github.com)

[Juan]

Thanks for sharing your test case. I should have some time this weekend to look at it.

[Juan]

Doing some quick research online, I see this interesting presentation:
Improving TCAD simulation of 4H-SiC particle detectors.pdf

from here.

A large part of the talk discusses the convergence issues you may encounter using Sentaurus or Global TCAD.

[Juan]

Here is a paper using DEVSIM for SiC. Perhaps you can reach out to the others for some advice, as I do not know them:
Xiyuan Zhang_41st_rd50_workshop

from here.

[Juan]

Also related:
https://doi.org/10.1007/s41605-023-00431-y

https://doi.org/10.48550/arXiv.2306.09576

[Hay]

Thanks for sharing, I’m one of them, that’s why I can guarantee that the parameters I’m using are accurate.I’m really sorry I read your share but I didn’t find where the key points are.

I tried to increase the mesh density and found that it still didn’t improve, the accuracy issue should have been solved by your three sentences as well

So now I don’t know what the problem is, which leads to an increasing error as the number of iterations increases.

I have tried a number of methods including adding models etc and found that nothing works, the error always starts at 18e so I suspect the problem is not in the lack of models.

I would really appreciate it if you could take a look at the programme for me in your spare time.

[Juan]

Hi @Hay

Unfortunately I was unable to run your script as there are files missing. Can you please add the following files?

bjt_params.py
bjt_dd_0.msh

[Hay]

Please wait a moment , I have some new progress ,I will share with you now (in github)

[Juan]

please let me know when it is ready

[Hay]

it should be done now

[Juan]

Hi,

I am getting this error after fixing the relative imports:

devsim_py3.error: Could not open file /afs/ihep.ac.cn/users/j/jiangzhenyu/raser/bjt_dd_0.msh

can you provide the bjt_dd_0.msh

It looks like there are no “CURVE” output because the bias sweep did not finish.

[Hay]

ok,I will do it right now

[Hay]

Please feel free to let me know if you have any questions, that’s where I’m at so far, bjt_dd_0.msh can be generated by running bjt_dd22 (if that’s not right).

the code I’ve changed and changed again

[Juan]

Are you sure you are not hitting a cpu limit on your computer system? There are no error messages in your:

vb2_40.out
vb2_41.out

Can you try the ulimit command on your system and report the result:

# ulimit -a
real-time non-blocking time  (microseconds, -R) unlimited
core file size              (blocks, -c) 0
data seg size               (kbytes, -d) unlimited
scheduling priority                 (-e) 0
file size                   (blocks, -f) unlimited
pending signals                     (-i) 127374
max locked memory           (kbytes, -l) 4087076
max memory size             (kbytes, -m) unlimited
open files                          (-n) 1024
pipe size                (512 bytes, -p) 8
POSIX message queues         (bytes, -q) 819200
real-time priority                  (-r) 0
stack size                  (kbytes, -s) 8192
cpu time                   (seconds, -t) unlimited
max user processes                  (-u) 127374
virtual memory              (kbytes, -v) unlimited
file locks                          (-x) unlimited

note that the cpu-time is the most important.

right now I am above VB of 5 Volts using this ramp statement:

rampvoltage("bjt", "Vb", 2.5, Vb, 0.01, 0.0001, max_iter=30, rel_error=1e-14, abs_error=1e20, callback=bjt_common22.make_bias("base"))

Please note that I tightened rel_error and loosened abs_error. Not that the rel_error=1e-14 is the smallest it can go since the circuit is calculated in double precision. I will work on making a smaller rel_error possible

[Hay]

The vb didn’t increase to 40v, is it because the CPU has already reached its limit