qucsconv: wrong SPICE netlist conversion

[in3otd]

trying to run a simulation with the LM358 spice model using the example referenced in #186 ; the output of qucsconv is partly wrong and the netlist checker complains.
A quick bisect says that the culprit is bfc7200

Portion of netlist converted by the current qucsconv, with errors:

 C:C2 _net6 _net7 C="2e-11"
  _net54:DC _net5 _net53 IS="8e-16"
  _net90:DE _net54 _net5 IS="8e-16"
  _net92:DLP _net90 _net91 IS="8e-16"
  _net4:DLN _net92 _net90 IS="8e-16"
  _cnet0:DP _net4 _net3 IS="8e-16"

same portion, with previous version of qucsconv:

 C:C2 _net6 _net7 C="2e-11"
  Diode:DC _net53 _net5 Is="8e-16" N="1" M="0.5" Cj0="1e-14" Vj="0.7"
  Diode:DE _net5 _net54 Is="8e-16" N="1" M="0.5" Cj0="1e-14" Vj="0.7"
  Diode:DLP _net91 _net90 Is="8e-16" N="1" M="0.5" Cj0="1e-14" Vj="0.7"
  Diode:DLN _net90 _net92 Is="8e-16" N="1" M="0.5" Cj0="1e-14" Vj="0.7"
  Diode:DP _net3 _net4 Is="8e-16" N="1" M="0.5" Cj0="1e-14" Vj="0.7"

Note that in the current version the diodes are not converted correctly

[felix-salfelder]

*sigh*

first of all, could you add a unit test on this? it shouldn't be that complicated to trigger such a massive error...

[in3otd]

yep, the circuit with the LM358 used to be part of qucs-test but was recently removed since the spice model license was unclear...
Will be good to test "every" spice component supported by qucsconv... another line on the TODO list 😐 .

[felix-salfelder]

qucsconv should not "support" any component at all. it should be the other way around. then, every component (component library) should/could/might carry the relevant tests...

does it have to be LM358? from the output you provide i'd expect this to fail on any circuit..

[in3otd]

ehm, should I have used "accepted" instead of "supported"? What I meant to say is that, AFAIK, we do not check that every spice component that can be converted by qucsconv is converted correctly. Checking every component in a library could be useful, but, again, this does not guarantee we cover "every" possible conversion.

Agree, it doesn't have to be an LM358 (likely, but didn't check), was just to say that this may have been caught before and due to a chain of events, wasn't.

[felix-salfelder]

but, again, this does not guarantee we cover "every" possible conversion.

you write "we"... once components are in libraries, it will be the responsibility of the maintainer/author of that library to test properly... a task completely independent of qucs development or release cycles.
that's how (and why) other projects work.

or put it this way: if the components we had to remove were just a (self contained/optional) blob in contrib). this would not have happened.

but back to topic: do you have the slightest idea why this broke down? i cannot see the connection...

[in3otd]

AFAIK, the Qucs Components Libraries are already pre-digested (pre-converted from Spice to qucsator netlist format), so that checks just that at the time the component was added qucsconv worked, if it became broken afterwards a library component will not notice.

I have no idea why it broke, I did not really check anything, besides the bisect; time is lacking and I know there are others who know that part better than me 😁

[in3otd]

Fixed by commit 747a580 in Qucs:release-0.0.19