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 interface between qucs and qucsator is limited, but it is the only half way stable interface to a simulator.

gnucsator is a drop-in replacement for qucsator, that means it

• provides some of the components implemented in qucsator,
• parses the netlist.txt files meant for qucsator (until this is no longer necessary),
• interprets and wraps simulation commands (embedded into the netlist) much like qucsator, then
• produces output equivalent to qucsator output (“dat” file format). partly implemented as shell script currently.

# 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.

gnucsator currently wraps gnucap DC and TRANSIENT analysis, and also imitates qucsator SPARAM analysis. qucs does not define an execution order. there is more work in progress on the qucs side.

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 implements many of 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.

gnucsator is based on gnucap with a view towards standard compliance.

• gnucap provides additional functionality, such as interactive analysis, measurements, scripting and data conversion, which is not covered here. e.g. a netlist.txt can be directly fed into an interactive session.
• the component library aims at implementing all qucs components in a standard language (verilog and variants). there will be no need to do it all over to support other (standard compliant) simulators.