Re: [Qucs/gnucsator] Assertion failed (#9)

[Felix Salfelder]

On Sat, Sep 18, 2021 at 02:29:53PM -0700, Dow Drake wrote:
> From the discussion on the gnucap-devel list, I think I've
> misunderstood the intended use of gnucsator.

Perhaps not. Any use is intended -- I do appreciate the test drive.

> > I have implemented some support for this, but I normally do it the
> > other way round.

> By this, do you mean that you normally use the Gnucsator library
> components instead of the built-in Qucs components when building a
> circuit in Qucs for simulation in Gnucsator?

Gnucsator is a frontend for Gnucap. Gnucap ships and supports a host of
components and algorithms that are unrelated to Qucs. The original
purpose of Gnucsator is to be able to run Gnucap under Qucs, and maybe
to translate netlists. From time to time, I adopt, port and implement
more Qucsator features for Gnucap. Qucsator has a relatively easy
interface, is widely used, and a follow-up is due.

> If so, can you let me know the simplest procedure to import those
> components into a user library in Qucs so they can be easily accessed
> when designing a schematic?

I don't think this is very well documented. The component models and
wrappers in Gnucsator (i.e. mainly include/*.v) are supposed to mirror
Qucsator. Symbols for these components are hardwired in Qucs.

Adding more components to Qucs seems a bit clumsy. Qucs has "library
components" that allow subcircuit models with macro definitions. A
subcircuit macro is pasted (verbatim) into netlist.txt, and so may use
whichever component you like. The configuration file gnucsator.rc is a
good place to load device models (manually), and there is no apparent
way to automate this in Qucs 0.0.20.

Such component macros wont work with Qucsator, leave alone the other
simulators supported by Qucs. Even if they could in principle (verilog-a
and the like). "Modular Qucs" is a work in progress that addresses most
of it, but it will take time.