qucs / qucsator Goto Github PK
View Code? Open in Web Editor NEWCircuit simulator of the Qucs project
Home Page: http://qucs.sourceforge.net
License: GNU General Public License v2.0
Circuit simulator of the Qucs project
Home Page: http://qucs.sourceforge.net
License: GNU General Public License v2.0
-- -- 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.
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...
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?
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
The power probe (wprobe
) gives wrong results when used with AC simulations:
see this circuit simulation (circuit taken from here):
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:
I'll open a PR with the fix soon...
While the frequency dispersion of impedance and dielectric constant of the microstripline are computed, they are not used to compute the losses.
qucsator/src/components/microstrip/msline.cpp
Lines 75 to 80 in 22126bb
qucsator/src/components/microstrip/msline.cpp
Lines 82 to 86 in 22126bb
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.
When using two coupled inductors, the Imaginary part of input impedance appears positive as expected. However, when using the same circuit using four coupled inductors, he Imaginary part of input impedance appears negative (third and fourth inductors effectively open circuited. by high resistances).
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 :
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 .
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?
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
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?
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:
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:
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).
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.
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!
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.
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.
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.
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.
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
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?
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"
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.
ERROR: Simulator crashed!
Please report this error to [email protected]
Do the authors have a PDF file of the article "Arguments and an accurate model for the power-current formulation of microstrip characteristic impedance"?
I've been looking for it for a long time but can't find it
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>
Ok, sourceforge seems dead https://sourceforge.net/p/qucs/discussion/311050/thread/394e4f130b/?limit=25#6350 , so I try it here:
I try to understand the nigbt model written in Verilog-A. But making a sweep with the default parameter set for output characteristic I only get values in nA. range w/o any expected characteristic.
BTW - same behaviour I have with openVAF compiled model and ngspice.
Has this model worked at any time?
Thank you.
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?
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.
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.
Working on a Coupled Microstrip Line that will support coupling to 2 adjacent microstrips. This will enable the design of interdigital and hairpin filters.
Having more than one subcircuit containing an EDD component in a schematic results in simulation errors; see discussion on Sourceforge.
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?
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)
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
)
where can we find some python examples for driving Qucs?
if we can pip install qucs we could make a gdsfactory extension for Qucs
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.
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
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
Qucs-Tesbench schematic ... filename extended by ".txt" to comply with Github
zt_pmosfet_orient.sch.txt
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.
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
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 ...
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.
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.
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
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.
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.)
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:
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.