Dietmar Warning

DEVpred() of charge node needs state vector update before

The answer is outstanding: Yes, we have to omit integration for the selfheating CTH current of the diode in case of dc sweep after tran. My test files are attached. The results for dc sweep will be erroneous differ.

Your observations are reasonable. Even selfheating at DC is more or less useless except for debugging purpose we should correct this for all selfheating models (diode, vdmos and vbic). I will make few check's and come back here.

Made checks with your latest commits and bjt, diode and vbic. Everything OK. Also checked Verilog-A cmc_diode. The openvaf compiler prevents integration in dc range. So we have not the problem.

It is an ngspice bug - nothing to do with IHP PDK. Separate simulations are correct, dc before tran too. The case tran before has wrong dc results. Not only bjt's are affected, diodes too.

But why the dc result is not disturbed if it come as first simulation? Is not that some variables have missing/wrong initialization for transient? Anyway integration for dc is waste and wrong. We are using this MODEDCTRANCURVE extension also in diode, vbic, vdmos and perhaps other models. The bsim's have with ChargeComputationNeeded = ((ckt->CKTmode & (MODEDCTRANCURVE | MODEAC | MODETRAN | MODEINITSMSIG)) || ((ckt->CKTmode & MODETRANOP) && (ckt->CKTmode & MODEUIC))) ? 1 : 0; a slightly better construct....

Sorry - I destroyed my own testcases from IHP github by omitting the circuit description and overlooked the set filetype=binary. So it seems we have a bjt model problem. But this is at least since version 27 from 2017 with much simpler model code! We have to check the places where intermediate variables in bjt temp and load routine can interfere the both simulations. In early days we introduced MODEDCTRANCURVE in bjtload if( (ckt->CKTmode & (MODEDCTRANCURVE | MODETRAN | MODEAC)) || ((ckt->CKTmode...

Sorry - I destroyed my own testcases from IHP github by omitting the circuit description and overlooked the set filetype=binary. So it seems we have a bjt model problem. But this is at least since version 27 from 2017 with much simpler model code! We have to check the places where intermediate variables in bjt temp and load routine can interfere the both simulations.