Coder Social home page Coder Social logo

qucs / qucsator Goto Github PK

View Code? Open in Web Editor NEW
23.0 23.0 10.0 8.85 MB

Circuit simulator of the Qucs project

Home Page: http://qucs.sourceforge.net

License: GNU General Public License v2.0

CMake 1.75% Makefile 1.13% Perl 0.62% Shell 0.09% C++ 87.16% M4 3.27% C 5.14% MATLAB 0.83%

qucsator's Introduction

--
-- README
--
-- Copyright (C) 2003, 2005, 2011 Stefan Jahn <[email protected]>
--
-- This is free software; you can redistribute it and/or modify
-- it under the terms of the GNU General Public License as published by
-- the Free Software Foundation; either version 2, or (at your option)
-- any later version.
--
-- This software is distributed in the hope that it will be useful,
-- but WITHOUT ANY WARRANTY; without even the implied warranty of
-- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-- GNU General Public License for more details.
--
-- You should have received a copy of the GNU General Public License
-- along with this package; see the file COPYING.  If not, write to
-- the Free Software Foundation, Inc., 51 Franklin Street - Fifth Floor,
-- Boston, MA 02110-1301, USA.
--


Description
===========

Qucs is a circuit simulator with graphical user interface.  The
software aims to support all kinds of circuit simulation types,
e.g. DC, AC, S-parameter and harmonic balance analysis.  For
details see homepage:

http://qucs.sourceforge.net


Requirements
============

Qucs needs Qt version 5 or later. For simplicity, the Qt configuration is
currently obtained through pkg-config, which you need to install in addition
to Qt.

Development
===========

Qucs source code is stored in a git repo. Two build systems are included.
The traditional autotools build system needs to be created by developpers,
when not using a tarball. Run ./bootstrap after cloning. The CMake build
system does not require this step. Choose your pick.

Installation
============

Unpack the distribution tarball:

    $ tar xvzf qucs-<version>.tar.gz               (using GNU tar)
    $ gzip -cd qucs-<version>.tar.gz | tar xvf -   (using another tar)

Change into the source directory:

    $ cd qucs-<version>

Configure the source package for your system:

    $ ./configure

Now compile the package:

    $ make

Install Qucs:

    $ make install

You must have root privileges if you want to install the package in the
standard location (/usr/local) or in any location that is only writable
by root.

For further information on installing the package, please consult the
file INSTALL included in this distribution.

Please note:  Users of the FreeBSD OS may use a GNU make (probably gmake)
to compile and install the package.

Getting the latest Git snapshot
===============================

TODO: repo on sf is oudated.

You can always get the latest Qucs version from our Git repository.
Please use an official release if you want to work with Qucs.  The Git
version might not even compile.

    $ git clone http://git.code.sf.net/p/qucs/git qucs-git

Press 'Enter' when asked for a password.  Run `sh bootstrap' and `configure'
(see above) with the appropriate options.  Maintainance currently requires
Autoconf version 2.57 and GNU automake 1.7.0.

qucsator's People

Contributors

andresmmera avatar bastien-roucaries avatar ckoegler avatar constrictor avatar crobarcro avatar eroen avatar felix-salfelder avatar fransschreuder avatar gildias avatar guitorri avatar in3otd avatar luzpaz avatar mikebrinson avatar nplanel avatar pienjo avatar ra3xdh avatar rmano avatar rubund avatar superman32432432 avatar thliebig avatar yodalee avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

qucsator's Issues

Can you "make -j" qucs-core ?

Recently a couple of users reported that they were not able to compile Qucs using "parallel make" (make -j), which also appears to be the default on some distributions (Gentoo, maybe?).

I also saw this issue sometimes; the quick "fix" I have done is to put .NOTPARALLEL: in qucs-core/src/components/verilog/Makefile.am.

I was wondering if others see this issue...

SPfile file interpolation problem

If the phase in the touchstone file is random or changing quickly the frequency interpolation produces false data.
I assume the interpolation is done base on the real/imaginary values, but I think it should be done based on amp/phase instead.
Ideally it should be done base on the specified format (MA, DB or RI). Any comments on this assumption are welcome.

A test file is attached. If the simulation is setup with 0 to 10GHz and 101 points all is good, but e.g. if the number of points is set too 100 or any other number the results start changing drastically.

Can someone point to me to a file or function to look at for the interpolation? Any ideas how to fix this?

test.s1p.zip

Missing -fPIC

ld: error: can't create dynamic relocation R_X86_64_64 against local symbol in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output
>>> defined in src/math/CMakeFiles/coreMath.dir/matrix.cpp.o
>>> referenced by matrix.cpp
>>>               src/math/CMakeFiles/coreMath.dir/matrix.cpp.o:(.rodata+0x8)

FreeBSD 13.1

Power probe AC results are wrong

The power probe (wprobe) gives wrong results when used with AC simulations:

see this circuit simulation (circuit taken from here):
image
note that the overall power values are correct but that the resistor is apparently generating power and has a significant reactive power component...

The issue is due to a wrong basic calculation of the power in the wprobe component, as in practice it computes the complex power as S = V I and flips the sign of the reactive power instead of using S = V I*. So when using the probe to compute the power provided by a source, so measuring the voltage across the source, the current calculation works, as the voltage from the source is purely real. But when measuring across a component, as shown above, the voltage has a phase different from zero and the results are wrong.

After correcting the formula used the results are fine:
image

I'll open a PR with the fix soon...

Frequency dispersion of impedance and dielectric constant is not used to compute the losses of microstripline

While the frequency dispersion of impedance and dielectric constant of the microstripline are computed, they are not used to compute the losses.

analyseDispersion (W, h, er, ZlEff, ErEff, frequency, DModel,
ZlEffFreq, ErEffFreq);
// analyse losses of line
analyseLoss (W, t, er, rho, D, tand, ZlEff, ZlEff, ErEff,
frequency, "Hammerstad", ac, ad);

However they are properly used to compute gamma.
// calculate propagation constants and reference impedance
zl = ZlEffFreq;
ereff = ErEffFreq;
alpha = ac + ad;
beta = qucs::sqrt (ErEffFreq) * 2 * pi * frequency / C0;

The original paper of Hammerstad and Jensen is ambiguous about this, as it used the same variable names for these values with or without dispersion.
On the other hand, it sounds strange to use the quasi-static constant value for losses and a frequency-dependant value for gamma. This eventually cause Qucs to have a small difference in simulated insertion loss if compared against Keysight ADS (using frequency invariant dielectric and kirschning models, but the loss computation is Hammerstad and Jensen).

Crash due to do "pointer being freed was not allocated"

Here is the crash info:

qucsator(16385,0x7fffa694b3c0) malloc: *** error for object 0x7fb016036800: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug

ERROR: Simulator crashed!
Please report this error to [email protected]

Here is a test example that works just fine with 0.0.18 and it is failing with develop.
bug_malloc_prj.zip

I did not bisect yet, but it is probably related to either f9dbd6, or 654651ca50.

simulation crushes

hello everyone , I made a simple circuit as to try qucs , I used what I learnt in the docs , yet NO SIMULATION would run at all .
this is the netlist :

R:R1 Vout _net0 R="50 Ohm" Temp="26.85" Tc1="0.0" Tc2="0.0" Tnom="26.85"
R:R2 gnd Vout R="50 Ohm" Temp="26.85" Tc1="0.0" Tc2="0.0" Tnom="26.85"
Vdc:V1 _net0 gnd U="1 V"
.DC:DC1 Temp="26.85" reltol="0.001" abstol="1 pA" vntol="1 uV" saveOPs="no" MaxIter="150" saveAll="no" convHelper="none" Solver="CroutLU"

this is the log file :

log.txt

I'm using QUCS 0.0.19 on fedora workstation 33 with GNOME UI , I installed qucs from official repos .

thanks are in advance..

EDIT: not even the examples shipped with qucs by default would run simulation .

BC547 collector overcurrent

Simulating a switch with a BC547 in QUCS 0.0.19 I have noticed that the collector current reaches 265 mA. However, the maximum collector for such transistor is 100 mA according almost manufacturers datasheet and Horowitz bible. Was not expected that simulator crash and raise some error mesage?

Fix warnings about integer comparison

If the -Wsign-compare flag is turned on a bunch of such warnings start to pup up.

 warning: comparison between signed and unsigned integer expressions [-Wsign-compare]

There is also a mix of int, unsigned int and std::size_t.
It is better to choose one and make it uniform.

It is not very hard to fix, but if one starts fixing the member variables, getters and setters on the base classes/templates, you quickly go from a dozen of warnings to thousands...

See also Qucs/qucs#363

Way to export DC operating point to an external file

I've checked all recent documentation for ways of exporting the several voltages qucs computes for the DC simulation.

As qucsator doesn't put this info in the log (at least I've also have not found any switch to do so) I wonder if the only way to record these results is to write down reading in the schematic?

Voltage probe handles noise voltages incorrectly

In an AC simulation, the voltage probe appears to simply calculate the difference in total noise voltage between its terminals, which generally does not provide the correct result.

As a simple demonstration of the problem, let's try measuring the voltage between two uncorrelated noise sources of 1 V^2/Hz:
image

The resulting Pr1.vn is 0, whereas I think the correct result would be โˆš2 V/โˆšHz.

Now, if I replace the voltage probe with an ideal transformer and a label to perform the same measurement, I get the correct result:
image

The "transformer and a label" trick can be used a workaround for now. It seems to be a bug in the implementation of the voltage probe itself.

I'm running the latest Qucs version compiled from develop branch 29432325df75d0c1512624a2c5811e99e4342058 and Qucsator 0.0.20, a08b0a1 . (Btw, I'm not sure whether this issue should in the qucs or in the qucsator repository).

S-parameter file causes simulation error

Hi,

I'm playing with this RF switch, where quite hopeless what should be wrong with my simulation as many different switches was working before. I copy the simulation error log also attach the S parameter file here. In a text editor I was not finding any strange things however sure there is something not usual here. Thats sure that the S parameter file was made with a real desktop VNA.

`Errors and Warnings:

line 23: no trailing end-of-line found, continuing...
line 23: syntax error, unexpected Float, expecting $end
checker error, found 6 options
checker error, option hz' occurred 2x checker error, option s' occurred 2x
checker error, option ri' occurred 2x checker error, option hz' occurred 2x
checker error, option s' occurred 2x checker error, option ri' occurred 2x
D_PE42540_SOLDERED_25C_3.300V_3.300V_0.000V_RF1_S5P_SN22_A.s5p.zip
`

Thank you very much!

DC simulation crashes with some circuit

Dear Qucs mainteners,

DC simulation crashes with some circuit, for example this one:

R:R1 _net0 _net1 R="15 kOhm" Temp="26.85" Tc1="0.0" Tc2="0.0" Tnom="26.85"
BJT:T_2N2222_1 _net0 VC _net2 VC Type="npn" Is="1e-14" Nf="1" Nr="1" Ikf="0.3" Ikr="0" Vaf="100" Var="0" Ise="0" Ne="1.5" Isc="0" Nc="2" Bf="200" Br="3" Rbm="0" Irb="0" Rc="3" Re="1" Rb="10" Cje="25e-12" Vje="0.75" Mje="0.33" Cjc="8e-12" Vjc="0.75" Mjc="0.33" Xcjc="1.0" Cjs="0" Vjs="0.75" Mjs="0" Fc="0.5" Tf="400e-12" Xtf="3" Vtf="0.0" Itf="2" Tr="100e-9" Temp="26.85" Kf="0.0" Af="1.0" Ffe="1.0" Kb="0.0" Ab="1.0" Fb="1.0" Ptf="0.0" Xtb="0.0" Xti="3.0" Eg="1.11" Tnom="26.85" Area="1.0"
R:R2 gnd _net0 R="1 kOhm" Temp="26.85" Tc1="0.0" Tc2="0.0" Tnom="26.85"
R:R3 VC _net1 R="22 kOhm" Temp="26.85" Tc1="0.0" Tc2="0.0" Tnom="26.85"
R:R4 gnd _net2 R="1.2 kOhm" Temp="26.85" Tc1="0.0" Tc2="0.0" Tnom="26.85"
C:C1 Ve _net0 C="100 nF" V=""
R:R5 gnd Vs R="1 kOhm" Temp="26.85" Tc1="0.0" Tc2="0.0" Tnom="26.85"
BJT:T_2N2222_2 VC _net1 Vs _net1 Type="npn" Is="1e-14" Nf="1" Nr="1" Ikf="0.3" Ikr="0" Vaf="100" Var="0" Ise="0" Ne="1.5" Isc="0" Nc="2" Bf="200" Br="3" Rbm="0" Irb="0" Rc="3" Re="1" Rb="10" Cje="25e-12" Vje="0.75" Mje="0.33" Cjc="8e-12" Vjc="0.75" Mjc="0.33" Xcjc="1.0" Cjs="0" Vjs="0.75" Mjs="0" Fc="0.5" Tf="400e-12" Xtf="3" Vtf="0.0" Itf="2" Tr="100e-9" Temp="26.85" Kf="0.0" Af="1.0" Ffe="1.0" Kb="0.0" Ab="1.0" Fb="1.0" Ptf="0.0" Xtb="0.0" Xti="3.0" Eg="1.11" Tnom="26.85" Area="1.0"
Vdc:V2 _net1 gnd U="15 V"
.DC:DC1 Temp="26.85" reltol="0.001" abstol="1 pA" vntol="1 uV" saveOPs="no" MaxIter="150" saveAll="no" convHelper="none" Solver="CroutLU"
Vac:V1 Ve gnd U="10 mV" f="1 k" Phase="0" Theta="0"`

When I made the simulation into text mode, I get a segmentation fault. this segmentation fault appears on Linux Mint 19 (based on Ubuntu 18.04) but not on Linux Mint 18 (based on Ubuntu 16.04).

The thing which is weird is when I add a sweep (even if no parameter is swept), the simulation works well:

.SW:SW1 Sim="DC1" Type="lin" Param="alpha" Start="0" Stop="1" Points="6"

I can give you additional information if you need them.

Amplitude and Phase issue with S-Parameter file

This is a simple simulation of a mini circuits power splitter. You would expect there to be some small insertion loss between port 1 and ports 2&3 as well as a slight phase shift. However, the simulation in QUCS appears to simulate an ideal splitter with no phase shifting or loss of voltage amplitude - the output voltages are literally on top of the input. You can see these effects though in the corresponding Keysight ADS simulation though. The other odd thing is how the S parameter will not work unless the parameter duringDC is set to short when this device is a transformer and at DC it's really an open. Otherwise great program, I hope IBIS simulation capability is on the roadmap.

image
image
image
image

Qucsator crashes on trivial netlists using glibc-2.26

Hello,

Qucsator (from unmodified qucs-0.0.19 sources) suddenly started crashing on my system (void linux, Linux 4.12.10, x86_64, glibc 2.26), with a segmentation fault in qucs::net::containsAnalysis(), line 224. It doesn't really matter what circuit I feed it; my crash dump below is using the supplied netlist, consisting of a voltage source and a resistor.

netlist.txt

Output:

[martijnb@tinkerbell .libs]$ ./qucsator -i ~/.qucs/netlist.txt
project location:
modules to load: 0
factorycreate.size() is 0
factorycreate has registered:
parsing netlist...
checking netlist...
netlist content
1 DC instances
1 R instances
1 Vdc instances
creating netlist...
Segmentation fault
[martijnb@tinkerbell .libs]$

gdb stack trace:

#0 0x00007ffff78b855a in std::list<qucs::analysis*, std::allocatorqucs::analysis* >::begin (this=0x21)
at /usr/include/c++/6.3/bits/stl_list.h:841
Qucs/qucs#1 0x00007ffff78b6fb4 in qucs::net::containsAnalysis (this=0x61ff10, child=0x6214e0, type=1) at net.cpp:224
Qucs/qucs#2 0x00007ffff78b7870 in qucs::net::sortChildAnalyses (this=0x61ff10, parent=0x6226e0) at net.cpp:355
Qucs/qucs#3 0x00007ffff78b7768 in qucs::net::orderAnalysis (this=0x61ff10) at net.cpp:344
Qucs/qucs#4 0x00007ffff78b7144 in qucs::net::runAnalysis (this=0x61ff10, err=@0x7fffffffe61c: 0) at net.cpp:249
Qucs/qucs#5 0x00000000004049a5 in main (argc=3, argv=0x7fffffffe808) at ucs.cpp:251

Relevant source:

220 /* Looks recursively for a type of analysis. */
221 int net::containsAnalysis (analysis * child, int type) {
222 ptrlist * alist = child->getAnalysis ();
223 if(alist != nullptr) {
224 for (auto *a : *alist) {
225 if (a->getType () == type)
226 return 1;
227 else if (a->getType () == ANALYSIS_SWEEP)

228 return containsAnalysis (a, type);
229 }
230 }
231 return 0;
232 }

"alist" is obviously hosed:

(gdb) print alist
$1 = (qucs::ptrlist *) 0x21
(gdb)

but that's as far as my gdb skills get me - Debugging c++ with gdb or ddd is tedious enough when I know what I should be looking for, but I don't :( However, I have a core dump available, if you want, and I'm willing to set breakpoints and inspect data, if you tell me where :)

What's peculiar is that qucsator used to work just fine until recently - it hasn't been updated itself, but glibc has been recently updated. I'll try to double check that. And no, rebuilding qucs from sources doesn't help.

Any help would be appreciated.

Kind regards,
Martijn.

Incorrect Correlated Voltage Noise Source Behavior

I'm trying to test a few circuits that can separate the real and imaginary parts of the cross-correlation of two noise sources. This can be accomplished with a 180degree hybrid (real part) and a 90degree hybrid (imaginary part). This technique was first published by Scott Wedge in the early 90's if you're interested. This may not be the most standard way to test the correlation, but it works. I tested with ADS and got the correct results. Anyway, I have a simple test set up where I have a correlated voltage noise sources object connected to ports 1 and 4 of a hybrid. I was hoping to see the change in output power (which is proportional to the real and imaginary parts of the cross-correlation) as I changed the normalized cross-correlation coefficient. The results are as-expected for the 180-degree hybrid, meaning that when I add a real number to the correlation coefficient, the noise sources behave correctly. Unfortunately, complex or purely imaginary correlation coefficients do not have the expected results. The imaginary portion as detected by the 90-degree hybrid is always zero no matter what coefficient I put in.

NOTE: This is a narrowband design, so it only REALLY works at the design frequency, which is 1.8GHz in this case. The following four images are: (1) setup showing 180-degree on left, 90-degree on right, 0 corr for both sources, (2) results, (3) setup with corr of 1 for 180-degree and +j for 90-degree, (4) results

image

image

image

image

Is this expected behavior? I have not looked "under the hood" at all, but I was hoping this would work without much debugging. Do the correlated noise sources not allow for complex correlation coefficients?

random() is crashing the simulator

Qucs 0.0.20 /pro/share/qucs/ex_stat_prj/verification_random_values.sch

Eqn:Eqn2 var_x="1" Export="yes"
Eqn:Eqn3 value="random()" Export="yes"
Eqn:Eqn1 seed="srandom(1)" Export="yes"
.DC:DC1 Temp="26.85" reltol="0.001" abstol="1 pA" vntol="1 uV" saveOPs="no" MaxIter="150" saveAll="no" convHelper="none" Solver="CroutLU"
.SW:SW1 Sim="DC1" Type="lin" Param="init" Start="1" Stop="10" Points="10"


Output:

Starting new simulation on Mon 16. Jan 2023 at 13:09:13:480

creating netlist... done.
Starting /usr/local/bin/qucsator

project location:
modules to load: 0
factorycreate.size() is 0
factorycreate has registered:
parsing netlist...

Errors occurred during simulation on Mon 16. Jan 2023 at 13:09:13:657
Aborted.

Errors and Warnings:

ERROR: Simulator crashed!
Please report this error to [email protected]

Using a substrate with er=1 produces invalid results (NaN) in S-Parameter simulation

When using a substrate with the relative permittivity "er" set to 1.0, the S-Parameter Simulation yields only results with "NaN". See below for an example schematic.
I had a look at the equations of the Models and my guess is: With EpsilonR set to 1 it equals Epislon_R_eff. In some equations for the Microstrip models is "EpsilonR - EpsilinR_eff" in the denominator, and then probably causes the NaN result.

My configuration is:
Qucs 0.0.18 (installed via guitorri/homebrew-tap)
Mac OSX 10.10.5

<Qucs Schematic 0.0.18>
<Properties>
  <View=0,0,800,800,1,0,0>
  <Grid=10,10,1>
  <DataSet=epsilonR_bug_example.dat>
  <DataDisplay=epsilonR_bug_example.dpl>
  <OpenDisplay=1>
  <Script=epsilonR_bug_example.m>
  <RunScript=0>
  <showFrame=0>
  <FrameText0=Title>
  <FrameText1=Drawn By:>
  <FrameText2=Date:>
  <FrameText3=Revision:>
</Properties>
<Symbol>
</Symbol>
<Components>
  <Pac P1 1 240 220 18 -26 0 1 "1" 1 "50 Ohm" 1 "0 dBm" 0 "1 GHz" 0 "26.85" 0>
  <MLIN MS1 1 410 170 -26 15 0 0 "Subst1" 1 "1 mm" 1 "10 mm" 1 "Hammerstad" 0 "Kirschning" 0 "26.85" 0>
  <GND * 1 240 250 0 0 0 0>
  <Pac P2 1 510 210 18 -26 0 1 "2" 1 "50 Ohm" 1 "0 dBm" 0 "1 GHz" 0 "26.85" 0>
  <GND * 1 510 240 0 0 0 0>
  <.SP SP1 1 300 480 0 51 0 0 "lin" 1 "1 GHz" 1 "10 GHz" 1 "19" 1 "no" 0 "1" 0 "2" 0 "no" 0 "no" 0>
  <SUBST Subst1 1 620 260 -30 24 0 0 "1" 1 "1 mm" 1 "35 um" 1 "2e-4" 1 "0.022e-6" 1 "0.15e-6" 1>
</Components>
<Wires>
  <240 170 380 170 "" 0 0 0 "">
  <240 170 240 190 "" 0 0 0 "">
  <510 170 510 180 "" 0 0 0 "">
  <440 170 510 170 "" 0 0 0 "">
</Wires>
<Diagrams>
</Diagrams>
<Paintings>
</Paintings>

Compile error... missing scan_citi.cpp

After running bootstrap and configure correctly, I have this error: (develop branch):

libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I.. -I../src/math -I../src/components -I../src/components -I../src/interface -I. -O2 -pipe -fno-exceptions -fno-check-new -ldl -rdynamic -MT scan_citi.lo -MD -MP -MF .deps/scan_citi.Tpo -c scan_citi.cpp  -fPIC -DPIC -o .libs/scan_citi.o
cc1plus: fatal error: scan_citi.cpp: No such file or directory

Any hint/help?

qucsator stdin input is broken

a user reported that qucsator does not work (anymore) with the input netlist coming from stdin.

At a first glance it seems to be related to the added part about loading dynamic modules which does a first pass on the netlist expecting to read it from a real file.

Not sure how to handle this, as the usual netlist parser will need to re-read the input again from the beginning so we may need to first explicitly read the whole input netlist.

Convergence problem with no GND

In Qucs there is convergence problem in transient simulation when ground is not present especially for non linear components. As most new users(like me) do not specify ground as it is not mandated, I propose Qucs should display error if GND is not present.

Fix fmod recursion

git/qucs/qucs-core/src/math/real.cpp:256:36: warning: all paths through this function will call itself [-Winfinite-recursion]
nr_double_t fmod( nr_double_t arg) {

Remove the qucs::fmod ? Use std::fmod direclty?

Inconsistent Timestepping Results for Transient Simulation

When I set up a transient simulation with
MinStep * Points > Stop
the results get inconsistent.

For example in the following netlist, I would expect a current of 1 Hz as configured, but if I plot the solution it shows a sine wave of 2 Hz in the plot.
netlist.txt

This should be rejected or handled properly by adjusting one of the parameters.
I'm using the stable release (0.0.18)

N Mutual Inductors does not accept variables

Usually one can specify the value of a component parameter thru a variable, e.g. for an inductor L=myLvalue, where myLvalue is defined in an Equation component.
This does not work for the N Mutual Inductors component (MUTX in the qucsator netlist) : the netlist parser says syntax error, unexpected ScaleOrUnit, expecting ']', for both the inductance values and the coupling coefficients.

I have the impression this just requires some (small ?) changes to parse_netlist.ypp but I know nothing about yacc/bison...

See the enclosed schematic for a failing example (rename .txt in .sch)

harmonic balance error

Hi
I tried simple harmonic balance simulation, I get an error:
terminate called after throwing an instance of 'std::out_of_range' what(): vector::_M_range_check: __n (which is 16) >= this->size() (which is 16)
screenshot at 2018-12-24 15-01-34

S-parameter max size or memory size limitation

There was a topic already on sourceforge, this mirrors it here.
https://sourceforge.net/p/qucs/discussion/311049/thread/ded7d8c9/

Either the S-parameter file parser or the qucs simulator has a memory or file size limit.
If I try to import anything larger than maybe 60MBytes S-parameter file, the simulator crashes with an error.
For professional simulations in digital electronics, we need to chain together multiple S-par files that are 32 ports each, having maybe 4000 samples, that is more than 500MBytes. If we insert 4 Spar files, each being 600MBytes, that is 2.4GBytes.

Typical error message:
line 500880: memory exhausted
checker error, found 6 options
checker error, option s' occurred 2x checker error, option s' occurred 2x

When releasing a new version of QUCS, please increase this limitation, to allow up to 1GBytes S-parameter files each, or 3GBytes or more total for all S-par files in the same schematic combined.

Qucsator@Qucs: p-MOSFET placement influency convergence

Helllo, using the p-MOSFET (4-terminal device) of components/nonlinear_components its placement seems to influence the convergence if the Drain is connected to the power-supply rather than the Source.

Change(s) made to the parameters of p-MOSFET are

  • Lambda=0.01

If the Source is connected to the power supply there are no convergence issues as far as I can tell.

Attached the testbench (inverter, input&output shorted). I_DIFF reports the difference of the current flowing through the inverters. The currents should be the same, if no other parameter is causing an asymmetrical behavior of the MOSFET.

n-MOSFET not checked for this issue.

Environment: Qucs 0.0.19 @ Win7Pro, i5-4310U

Screenshot
pmosfet_convergence

Qucs-Tesbench schematic ... filename extended by ".txt" to comply with Github
zt_pmosfet_orient.sch.txt

Simulator crashes with glibc 2.33

Trying to simulate a simple voltage divider, the simulation crashes with the following helpfull message: "ERROR: Simulator crashed!"

Digging a bit around I did:

qucsator -i netlist.txt

And it provided a bit more help, a coredump:

/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0/bits/stl_vector.h:1045: std::vector::reference std::vector<qucs::nodelist_t *, std::allocator<qucs::nodelist_t *>>::operator[](std::vector::size_type) [_Tp = qucs::nodelist_t *, _Alloc = std::allocator<qucs::nodelist_t *>]: Assertion '__builtin_expect(__n < this->size(), true)' failed.
Aborted (core dumped)

Researching a bit more: I found that the following code provides the same error https://github.com/rstudio/httpuv/issues/133#issuecomment-387499519

This led me to believe that glibc might be the culprit here. Surely enough when browsing through the Archlinux forums My suspicion was confirmed by the (current) top post on the AUR page of QUCS https://aur.archlinux.org/packages/qucs/. It seems the upgrade from glibc 2.25 to version 2.xx throws this error. Running the same simulation on a different computer (also an archlinux pc) with hasn't upgraded in months, seems to work fine.

Of course its Archlinux which is known for having crashes when upgrading packages to soon. But since more Distro's are likely to follow, it will come up more often.

netlist.txt

rectangle voltage source tr and tf functionality

OS windows 7
qucs version 0.0.19

Considering the rectangle voltage source tr and tf, with the default values (1 ns), the simulation (transitory simulation) blocks before finishing. The simulation completes only with tf and tr set to 0 s or higher than 3 ns

wrong BJT fitting with spice model vs SP file

hi,
I'm trying to get back to the latest version of qucs. I'm trying to check if it is working properlly or not to start new design on qucs or not.

the idea:
retrieve from NXP the SP file of a BFU730 @2v,10mA
then I'm using the BFU730 spice model to rebuilt a sbkt in qucs to represent the die and its package. then I'm trying to inject the correct current to have the 10 mA over 2V.

it does not fit ?
by the way do anyone knows why I do have such message with a manufacturer model :

WARNING: Unphysical model parameter Nf = 0.9926 in BJT bjt_BFU730F.BJT1.BFU610F_die_1
WARNING: Unphysical model parameter Nr = 0.98 in BJT bjt_BFU730F.BJT1.BFU610F_die_1
WARNING: Unphysical model parameter Vtf = -17.68 in BJT bjt_BFU730F.BJT1.BFU610F_die_1

I'm facing the same issue as the one faced in 2006 on the BFG425 in the workbook ...

LNA_BFU730_prj.zip

due to some issue using the latest version on linux, I'm using the win version 0.0.19 to have the DC and SP sweep working.

Switch-mode BJT transient simulation failed

Transient simulation for some types of bipolar transistors (switch-mode) failed. 2N2222A works ok, but 2N3055 fails. This bug appears for some other types of BJTs and with some conditions for MOSFETs.

Schematic is here:
2n3055

It is available also at Gist: https://gist.github.com/ra3xdh/6cd1996486c1c5e59e32/download
Simulation log is here.

WARNING: TR1: inserted virtual resistance at node `_net0' connected to [R2,V1]
WARNING: TR1: inserted virtual resistance at node `_net2' connected to [_Rbb#Q2N3055_1,R2,R4]
WARNING: TR1: inserted virtual resistance at node `_base#Q2N3055_1' connected to [_Rbb#Q2N3055_1,Q2N3055_1]
WARNING: TR1: inserted virtual resistance at node `_net1' connected to [R5,V2]
WARNING: TR1: inserted virtual resistance at node `_collector#Q2N3055_1' connected to [_Rc#Q2N3055_1,Q2N3055_1]
ERROR: TR1: Jacobian singular at t = 1.000e-10, aborting transient analysis

qucs can not be built with make -j8

It fails with

...
make[5]: Entering directory `/home/sla/RPM/BUILD/qucs-0.0.19/qucs-core/src/converter'
x86_64-alt-linux-g++ -DHAVE_CONFIG_H -I. -I../..  -I../../src -I../../src -I../../src/math   -pipe -Wall -O2 -std=gnu++11 -pipe -fno-exceptions -fno-che
/bin/sh ../../build-aux/ylwrap parse_spice.ypp y.tab.c parse_spice.cpp y.tab.h `echo parse_spice.cpp | sed -e s/cc$/hh/ -e s/cpp$/hpp/ -e s/cxx$/hxx/ -e
/bin/sh ../../build-aux/ylwrap scan_spice.lpp lex.spice_.c scan_spice.cpp -- flex --nounistd..
x86_64-alt-linux-g++ -DHAVE_CONFIG_H -I. -I../..  -I../../src -I../../src -I../../src/math   -pipe -Wall -O2 -std=gnu++11 -pipe -fno-exceptions -fno-che
x86_64-alt-linux-g++ -DHAVE_CONFIG_H -I. -I../..  -I../../src -I../../src -I../../src/math   -pipe -Wall -O2 -std=gnu++11 -pipe -fno-exceptions -fno-che
/bin/sh ../../build-aux/ylwrap parse_vcd.ypp y.tab.c parse_vcd.cpp y.tab.h `echo parse_vcd.cpp | sed -e s/cc$/hh/ -e s/cpp$/hpp/ -e s/cxx$/hxx/ -e s/c++
/bin/sh ../../build-aux/ylwrap scan_vcd.lpp lex.vcd_.c scan_vcd.cpp -- flex --nounistd..
x86_64-alt-linux-g++ -DHAVE_CONFIG_H -I. -I../..  -I../../src -I../../src -I../../src/math   -pipe -Wall -O2 -std=gnu++11 -pipe -fno-exceptions -fno-che
/home/sla/RPM/BUILD/qucs-0.0.19/qucs-core/src/converter/scan_spice.lpp:628: warning, rule cannot be matched
x86_64-alt-linux-g++ -DHAVE_CONFIG_H -I. -I../..  -I../../src -I../../src -I../../src/math   -pipe -Wall -O2 -std=gnu++11 -pipe -fno-exceptions -fno-che
/home/sla/RPM/BUILD/qucs-0.0.19/qucs-core/src/converter/parse_spice.ypp: warning: 3 shift/reduce conflicts [-Wconflicts-sr]
/home/sla/RPM/BUILD/qucs-0.0.19/qucs-core/src/converter/parse_spice.ypp: warning: 3 reduce/reduce conflicts [-Wconflicts-rr]
x86_64-alt-linux-g++ -DHAVE_CONFIG_H -I. -I../..  -I../../src -I../../src -I../../src/math   -pipe -Wall -O2 -std=gnu++11 -pipe -fno-exceptions -fno-che
updating parse_vcd.hpp
x86_64-alt-linux-g++ -DHAVE_CONFIG_H -I. -I../..  -I../../src -I../../src -I../../src/math   -pipe -Wall -O2 -std=gnu++11 -pipe -fno-exceptions -fno-che
x86_64-alt-linux-g++ -DHAVE_CONFIG_H -I. -I../..  -I../../src -I../../src -I../../src/math   -pipe -Wall -O2 -std=gnu++11 -pipe -fno-exceptions -fno-che
scan_spice.lpp:51:27: fatal error: parse_spice.hpp: No such file or directory
compilation terminated.
make[5]: *** [scan_spice.o] Error 1
make[5]: *** Waiting for unfinished jobs....
updating parse_spice.hpp
make[5]: Leaving directory `/home/sla/RPM/BUILD/qucs-0.0.19/qucs-core/src/converter'
...

With make -j1 everything works.

This means that for make parse_spice.lpp does not depend on parse_spice.hpp and make does not care about correct building order.

Adding explicit dependency: scan_spice.lpp: parse_spice.hpp
to qucs/qucs-core/src/converter/Makefile.am fixes the problem.

Irregularities in qucsator netlist

The Switch device takes a non-scalar time value, which seems to be a string representing an array. Such irregularities make it hard to interoperate with other tools, whilst not adding any value.

Before fixing the netlist that Qucs (GUI) produces, qucsator needs to be extended to avoid regressions. E.g. qucsator could accept values for scalar variables "time0", "time1" ...

(This one was found in Qucs/qucs#986.)

Assertion in stl_vector.h:1123 on Fedora 28

Simulating any circuit leads to a failed assertion on Fedora 28 and the version of the project from Fedora rep qucs-0.0.20~rc2-3.fc38.x86_64
Assertion string looks like:
/usr/include/c++/13/bits/stl_vector.h:1123: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator [with _Tp = qucs::nodelist_t*; _Alloc = std::allocatorqucs::nodelist_t*; reference = qucs::nodelist_t*&; size_type = long unsigned int]: Assertion '__n < this->size()' failed.
The picture of the circuit:
image
It seems it is the same issue as the following rstudio/httpuv#133.
Here is a fix rstudio/httpuv@6cf767f.

Since there is no trace and only logs, it is quite tricky to determine the exact line where undefined behaviour happened. Here is the log though:
log.txt
Please, do not hesitate to contact me if you need any help with gathering additional info or even debugging the program.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.