[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qucs/gnucsator] Release binaries for this project (#2)

From: Felix Salfelder
Subject: Re: [Qucs/gnucsator] Release binaries for this project (#2)
Date: Sun, 15 Mar 2020 13:47:44 +0100
User-agent: NeoMutt/20170113 (1.7.2)

On Sat, Mar 14, 2020 at 09:35:16PM -0700, danyill wrote:
> I guess to not have a Python dependency the [Python
> script](
> for converting to the Qucs format needs to be rewritten in C++ and
> also support other analyses (at the moment no output is given other
> than transient analysis).

Taking this to gnucap-devel (cc).

Background: Dan has written a python script to convert transient output
to a format that Qucs can read. This is faster than my ancient shell
script in gnucap-qucs (and maybe less broken). With this, Qucs+Gnucap
becomes more practical. But it does not fully align with the plan.

The plan is to use (an) output plugin(s) for producing output in the
desired format. An output plugin could be implemented in C++ and hooks
into the simulation command [1]. Transient output is particularly
simple, and it seems to make sense to have a plugin based on the latest
output-$n branch. The best outcome will be, it just works with develop,
once this is merged (maybe with a minor fix). The worst outcome: we have
to wait. Patch in gnucap-qucs, to use the plugin as an
intermediate kludge. Still much closer to the plan.

Maybe Al can say something about the status of this.

> Given the deficiencies in the Qucs transient analysis perhaps
> gnucsator should be used for transient analysis instead?

Historically, the focus of qucsator was not transient simulation. We
need to focus on how to provide choices for the user (e.g. package
gnucsator), and see what happens.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]