search

ra3xdh / qucsator_rf

Qucsator-RF is RF circuit simulation kernel for Qucs-S
https://ra3xdh.github.io/
GNU General Public License v2.0
13 stars 5 forks source link

Add transient model for microstrp lines #7

Open ra3xdh opened 4 months ago

ra3xdh commented 4 months ago

See https://github.com/ra3xdh/qucs_s/discussions/681 for context. The ideal transmission line has TRAN model. It's need to implement similar for miscrostrips. Contribution is welcome here. Could be a good BS or MS thesis project for someone.

The following devices need to add transient model:

tomhajjar commented 4 months ago

By placing this issue under qucsator-rf are you not hiding it from those who look at qucs-s issues?

ra3xdh commented 4 months ago

I am placing this at QucsatorRF repository, because it is related to simulator engine, but not related to GUI. I may duplicate this at Discussion/Ideas section of the main repository. No work is required at GUI side to implement microstrip transient models. Everything should be done at QucsatorRF side.

ra3xdh commented 4 months ago

I have started implementation of the transient models for microstrip lines in #16.

felix-salfelder commented 2 months ago

Hi Vadim.

In case you didn't know, or maybe forgot. Missing models in Qucsator was one of the motivations behind Gnucsator.

(It seems QucsatorRF is essentially Qucsator. Is this going to change? I gave up on Qucsator long time ago, and I thought you did so too.)

We have the features ready needed to represent and simulate transmission lines (Using Verilog-A). As it now looks like you intend to keep supporting Qucsator netlists, there should be room for collaboration on models.

Everything should be done at QucsatorRF side.

There is more than one transmission line model, multiple ways to represent it and multiple simulation techniques. It would be nice if Qucs-S had a mechanism to choose a model behind a symbol. I remember the original Qucs had hardwired all the symbols/names/parameters back in the days. A user specified device type (better: user specified parameters, basically the way gEDA did it) would be very useful.

cheers felix

felix-salfelder commented 2 months ago

Could be a good BS or MS thesis project for someone.

Maybe you underestimate the complexity. Some ground work was already done but in a PhD thesis [1]. It gives some clues about what commercial tools do nowadays, and what may work.

[1] https://sedemos.blogspot.com/2024/04/phd-transient-simulation-of-frequency.html

ra3xdh commented 2 months ago

Hello Felix,

Thanks for interest.

Missing models in Qucsator was one of the motivations behind Gnucsator.

What missing models? Could you remember or provide a link?

It seems QucsatorRF is essentially Qucsator. Is this going to change?

Yes, QucsatorRF inherits a code from Qucsator-0.0.20. I have no intention to change the netlist syntax etc.

I gave up on Qucsator long time ago, and I thought you did so too.

The user feedback show that there exists a need in RF simulation engine and Qucsator still be in use. The SPICE cannot resolve this task. The development of the original Qucsator has been stalled, and I decided to make this fork. See also #1

We have the features ready needed to represent and simulate transmission lines (Using Verilog-A).

This may be not a straightforward task. Prof. Mike Brinson has tried to implement MS line mode using Ngspice+OpenVAF about two years ago and failed. He didn't contact me regarding this question in the last year. This also was a motivation to continue support Qucsator. It has many unique RF simulation feature and I am not sure if this could be implemented using SPICE.

I remember the original Qucs had hardwired all the symbols/names/parameters back in the days.

Qucs-S still inherit hardcoded C++ system devices library from old Qucs. The redesign of these devices is technically possible (need something like https://github.com/Qucs/qucs/issues/659), but I don't consider this to be done in the near future. This task requires a huge amount of coding. This is beyond of the scope of this issue.

Maybe you underestimate the complexity. Some ground work was already done but in a PhD thesis [1].

The QucsStudio project has transient model for transmission line for a long time. So, the underlying mathematics should be well known. I am intending at least to reproduce the features implemented in QucsStudio. Unfortunately the developer of QucsStudio has closed the source.

felix-salfelder commented 1 month ago

On Tue, Sep 24, 2024 at 09:54:25AM -0700, Vadim Kuznetsov wrote:

Missing models in Qucsator was one of the motivations behind Gnucsator.

What missing models? Could you remember or provide a link?

Models are everywhere. The real issue is that simulators don't support them. Qucsator had a few baked-in models, and it needs a fork to add another one.

Transmission lines come in various flavours, some use subcircuit macros, some use analog filters. I started to collect a few examples, but the list is practically endless [1]. Needless to say, it's not (yet) on our agenda. To make it a priority, I need a collaborator.

The user feedback show that there exists a need in RF simulation engine and Qucsator still be in use. The SPICE cannot resolve this task. The development of the original Qucsator has been stalled, and I decided to make this fork. See also #1

The original Qucsator is maintained as-is, and the development has moved on to Gnucsator. In the first iteration Gnucsator was supposed to be i/o compatible with Qucsator, but with the intent to move on.

We have the features ready needed to represent and simulate transmission lines (Using Verilog-A).

This may be not a straightforward task. Prof. Mike Brinson has tried to implement MS line mode using Ngspice+OpenVAF about two years ago and failed.

Did OpenVAF exist 2 years ago? Anyway it still does not provide either paramset, generate, subdevices or the analog filters I'd use in transmission line models. Without these features, is there any need to try?

Maybe you underestimate the complexity. Some ground work was already done but in a PhD thesis [1].

The QucsStudio project has transient model for transmission line for a long time. So, the underlying mathematics should be well known. I am intending at least to reproduce the features implemented in QucsStudio. Unfortunately the developer of QucsStudio has closed the source.

Have you asked him to publish it? To my knowledge QS has been discontinued.

Models need to become user data. Closed models are basically worthless, and non-portable models will hold everyone back. There are multiple ways to implement transmission lines. The basic lossless reflection based one has been in Gnucap for decades (C++, hand coded plugin). This one turned out to be effectively 5 lines of Verilog-A. We have added AC loss, but not the general transient support you may be after here.

To get loss into transient, you can discretise RLGC, or employ some filter tricks. There is more than one way. Verilog-A provides the framework for this. Also, you may want to infer coefficients from VNA measurements. It won't end here. With the basics done, you may want to add cross talk, and simulate more complex circuits, perhaps PCB models.

Looking at it this way, it may be more promising to add Verilog-A/MS to a Qucs GUI (see my Qucs-s/vcresistor post for a starting point), than developping yet another simulator.

[1] https://git.savannah.gnu.org/cgit/gnucap/gnucap-modelgen-verilog.git/tree/examples/trln/README?h=develop

ra3xdh commented 1 month ago

Qucsator had a few baked-in models, and it needs a fork to add another one.

The OSDI interface looks "production-ready" and may resolve this issue. I have a little interest in implementing OSDI interface for QucsatorRF myself, but I would accept the patch containing the implementation. This question is beyond the scope of this issue.

Did OpenVAF exist 2 years ago?

Yes, the OpenVAF developer provided an interface for Ngspice by the end of 2022.

Have you asked him to publish it? To my knowledge QS has been discontinued.

The QucsStudio still be alive. The developer has recently posted some intention about preparing a new release. I didn't contact with the developer personally, but there were many requests to make QucsStudio open-source or at least cross-platform. The answer from the developer was "no". For example look here: https://qucsstudio.de/forums/topic/linux-support/

P.S.: these questions are beyond the scope of this particular issue. You may open a new discussion here: https://github.com/ra3xdh/qucsator_rf/discussions

felix-salfelder commented 1 month ago

Yes, the OpenVAF developer provided an interface for Ngspice by the end of 2022.

Oh, true. Time flies :/

The QucsStudio still be alive.

Really unfortunate that QucsStudio is closed. It might save some time, or at least remove some doubts.

Anyway, I am unsure what you are after here. The "help needed" tag and title suggested that you need help with a model implementation.