qucsator is the default simulation engine behind the qucs user interface. it does dc/ac/tran and sparam analysis, and maybe a (simplified, linear?) kind of harmonic balance.

The use is quite limited due to the interface between qucs and qucsator, but it defines a sort of interface between the projects.

gnucsator aims to be a drop-in replacement for qucsator, that means it will * provide the components implemented in qucsator, * have to read the netlist (unless/until somebody fixes this) * interpret simulation commands (embedded into the netlist) like qucsator. * produce output equivalent to qucsator output (“dat” file format).

# Qucs 0.0.16  bridge.sch
 
IProbe:Pr1 _net0 _net1
R:R2 _net2 _net3 R="500 Ohm" Temp="26.85" Tc1="0.0" Tc2="0.0" Tnom="26.85"
Vdc:V1 _net3 gnd U="1 V"
R:R5 gnd _net2 R="Rmeasure" Temp="26.85" Tc1="0.0" Tc2="0.0" Tnom="26.85"
R:R1 _net0 _net3 R="Rbranch" Temp="26.85" Tc1="0.0" Tc2="0.0" Tnom="26.85"
R:R4 gnd _net0 R="Rbranch" Temp="26.85" Tc1="0.0" Tc2="0.0" Tnom="26.85"
.DC:DC1 Temp="26.85" reltol="0.001" abstol="1 pA" vntol="1 uV" saveOPs="no" MaxIter="150" saveAll="no" convHelper="none" Solver="CroutLU"
R:R3 _net1 _net2 R="500 Ohm" Temp="26.85" Tc1="0.0" Tc2="0.0" Tnom="26.85"
.SW:SW1 Sim="DC1" Type="lin" Param="Rmeasure" Start="10 Ohm" Stop="1 kOhm" Points="100"
.SW:SW2 Sim="SW1" Type="lin" Param="Rbranch" Start="200 Ohm" Stop="1 kOhm" Points="4"
Eqn:Eqn1 Umeasure="500 * abs(Pr1.I)" Export="yes"

First line shows the version of the qucs and the file path

_net gives information about in between which nodes the component is connected

The list of the components in Qucs can be seen in the link below http://qucs.sourceforge.net/docs/textmode.pdf

TODO. tl;dr; some upside-down xml inspired layout without simulation labels.

TODO.

The schematic format used in qucs is not currently used for simulation purposes. Qucs compiles an intermediate self-contained circuit representation (“netlist”) including simulation commands before invoking qucsator. Hence the format used for the schematics (some XML-like format) is not relevant yet. It will be easy to represent the schematic as a standardized (e.g. verilog) netlist, once Qucs supports additional file formats. This will make the schematic files more useful and the intermediate netlists obsolete.

Qucs essentially provides a hardcoded set of components plus variants (paramsets) through a “component library”. We need to provide (most/all) of the components supported by qucsator. It would be possible to wrap them, on an implementation/binary level using a wrapper similar to spice_wrapper (e.g. http://git.savannah.gnu.org/cgit/gnucap/gnucap-plugins.git/tree/qucs_wrapper.cc?h=qucs). This involves some effort and workarounds with no clear benefit. In particular, there are only few components, this could be used for.

The approach here https://git.savannah.gnu.org/cgit/gnucap/gnucap-plugins.git/tree/STATUS?h=qucs aims at implementing the components in terms of modules that (re-)use some functionality of existing gnucap components. Some components can be directly wrapped through a subcircuit declaration or paramset. Others can be easily represented by subcircuits containing few components (a.k.a. macros). Ideally all components would be implemented in verilog-A. At the current stage it would make more sense to support user provided Verilog-A models in qucs. Some work has been done in that direction, but qucsator will not support Verilog-A input in the foreseeable future.