Closed in3otd closed 9 years ago
Seems straightforward, can you create a hotfix to this?
ok, just done a pull request.
Anyway, I find a bit worrisome that this error in the netlist generation code went unnoticed for several months; could qucs-test
be used to check the netlist generation also (@guitorri ?)
Moreover, this uncovered another issue in qucsator
- the (slightly) wrong netlist generated should not have caused a wrong result. Will investigate a bit more and open another issue, in case.
Merged PR, issue close. I open another issue to discuss about netlist testing.
@in3otd, in qucs-test
there is some code to test --qucs
(besides --qucsator
).
It calls qucs
in the command line to convert schematic to netlist, see https://github.com/Qucs/qucs/wiki/Qucs-Command-Line-Tools
I haven't tested it much. I also noticed that when an old schematic is loaded on the GUI and saved again, during the save the schematic is updated to the latest list of properties. Hence the number of properties might be updated. So, depending on how you convert to netlist (manually or command line) it might be different.
...after wasting some time trying to understand the bizarre results I was getting from an amplifier I was simulating, I realized that currently the "deactivate" function does not generate a correct netlist when a component is "deactivated" to be a short circuit. For an example see this schematic : when the inductor is shorted
S[2,1]
should be 1 but the simulation gives a result of 0.5 instead... The problem was introduced in this commit ; in particular this line and this one are wrong, since the iteration should start from the second element and not from the first. At a first glance the otherforeach()
introduced with this commit seems fine. Changing the above two lines to something likeworks, not sure if there is some better way to do it...