Since version 43 an strange branch value appears if alli is activated for save: q.x1.qnpn13g2#branch.
I can't classify this value. Older versions didn't show this value.
Test case and result file attached.
The ngspice-43 values seem to be wrong (ic = 3e-13 ??). The q.x1.qnpn13g2#branch in question is nearly equal to -1*vc#branch. I will check what the origin for q.x1.qnpn13g2#branch might be, but there seems to be a more severe bug in the VBIC model (caused by the updates?).
Last edit: Holger Vogt 2024-07-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When I reset the pre-master-44 branch to commit 16513beb4 ("Don't enable functions 'time' or 'getrusage' when OpenMP is selected", 2024-07-11)
(before the second VBIC update on nqs starts) everything is o.k. (like in ngspice-42). When setting the branch to b84ac9ecd ("Options are now included", 2024-07-12)
(right after the nqs commits), the bugs are there.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You are right - the introduced nqs effect destroying the op variables report, the results for network solution (vx#branch) seems OK. Switching off this effect by setting td=0 or commenting out the parameter show correct results too.
Other what worries me is that @q.x1.qnpn13g2[ib] is reported 3 times. This was also the case in former versions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Concerning triple @q.x1.qnpn13g2[ib]: You have three base nodes, base, baseBI, baseBP. According to outitf.c, line 323 all nodes containing 'base' in their names will get the same vector name.
If you call the new nodes in vbicsetup.c for example basBI and basBP, everything seems to be o.k. Same probably with HICUM2.
Unfortunately we then have 5 extra nodes printed, which are probably not of interest to the user:
When I run your example with vc=1 and Vb=0.7, I get the following (command print all):
ngspice-43
ngspice-42
The ngspice-43 values seem to be wrong (ic = 3e-13 ??). The
q.x1.qnpn13g2#branchin question is nearly equal to-1*vc#branch. I will check what the origin forq.x1.qnpn13g2#branchmight be, but there seems to be a more severe bug in the VBIC model (caused by the updates?).Last edit: Holger Vogt 2024-07-22
When I reset the pre-master-44 branch to commit
16513beb4 ("Don't enable functions 'time' or 'getrusage' when OpenMP is selected", 2024-07-11)(before the second VBIC update on nqs starts) everything is o.k. (like in ngspice-42). When setting the branch to
b84ac9ecd ("Options are now included", 2024-07-12)(right after the nqs commits), the bugs are there.
You are right - the introduced nqs effect destroying the op variables report, the results for network solution (vx#branch) seems OK. Switching off this effect by setting td=0 or commenting out the parameter show correct results too.
Other what worries me is that @q.x1.qnpn13g2[ib] is reported 3 times. This was also the case in former versions.
Latest commit correct the op reporting discrepancy for activated excess phase in vbic model.
The original problem and the 3x [ib] output still exist.
With your recent update (without
save alli allv, but with collector and base voltages) I getThere are three new entries
corresponding to your code changes in vbicsetup.c, lines 510 ff.
With
save alli allvI still getwhich does not correspond to
Thank you, Holger!
Can you make an new attempt.
are equal now.
Concerning triple
@q.x1.qnpn13g2[ib]: You have three base nodes, base, baseBI, baseBP. According to outitf.c, line 323 all nodes containing 'base' in their names will get the same vector name.If you call the new nodes in vbicsetup.c for example basBI and basBP, everything seems to be o.k. Same probably with HICUM2.
Unfortunately we then have 5 extra nodes printed, which are probably not of interest to the user:
save alli allv nosubmay help then.
Last edit: Holger Vogt 2024-07-23