search

Qucs / gnucsator

This package provides a gnucap based qucsator implementation.
GNU General Public License v3.0
13 stars 4 forks source link

Assertion failed #9

Closed ddrake closed 3 years ago

ddrake commented 3 years ago

Hi, I've been running numerous transient simulations of diode and bjt circuits using gnucsator, qucsator and sometimes ngspice. The gnucsator option has been very helpful. In most cases, gnucsator succeeds even if qucsator fails, and its results match those of ngspice, but for this simple emitter follower, which simulates correctly with qucsator and ngspice, a gnucsator assertion fails resulting in a seg fault.

Here's the netlist generated by Qucs:

# Qucs 0.0.20  /home/dow/.qucs/ch2_prj/emitter_follower.sch

BJT:Q2N3904_1 in c out c Type="npn" Is="1.4e-14" Nf="1" Nr="1" Ikf="0.025" Ikr="0" Vaf="100" Var="0" Ise="3e-13" Ne="1.5" Isc="0" Nc="2" Bf="300" Br="7.5" Rbm="0" Irb="0" Rc="2.4" Re="0" Rb="0" Cje="4.5e-12" Vje="0.75" Mje="0.33" Cjc="3.5e-12" Vjc="0.75" Mjc="0.33" Xcjc="1" Cjs="0" Vjs="0.75" Mjs="0" Fc="0.5" Tf="4e-10" Xtf="0" Vtf="0" Itf="0" Tr="2.1e-08" Temp="26.85" Kf="9e-16" Af="1" Ffe="1" Kb="0" Ab="1" Fb="1" Ptf="0" Xtb="1.5" Xti="3" Eg="1.11" Tnom="26.85" Area="1"
Vdc:V1 c gnd U="5 V"
R:R3 gnd out R="100 Ohm" Temp="26.85" Tc1="0.0" Tc2="0.0" Tnom="26.85"
Vpulse:V2 in gnd U1="0 V" U2="3 V" T1="0" T2="1 ms" Tr=".1 ms" Tf=".1 ms"
.TR:TR1 Type="lin" Start="0" Stop="1.5 ms" Points="1000" IntegrationMethod="Trapezoidal" Order="2" InitialStep="1 ns" MinStep="1e-16" MaxIter="150" reltol="0.001" abstol="1 pA" vntol="1 uV" Temp="26.85" LTEreltol="1e-3" LTEabstol="1e-6" LTEfactor="1" Solver="CroutLU" relaxTSR="no" initialDC="yes" MaxStep="0"

The message is: 

gnucsator: s_tr_swp.cc:292: bool TRANSIENT::next(): Assertion `new_dt >= _sim->_dtmin' failed.

/usr/bin/gnucsator.sh: line 47: 104922 Aborted                 (core dumped) $GNUCSATOR <<EOF
qucs
include $infile
go ${out}
status notime
EOF

I've tried a number of different values for Tr and Tf ranging from 1ps up to .1ms. I've also tried reducing MinStep to 1e-18, but so far, I haven't found a way to get the simulation to complete. I'm using the current master branch of gnucsator. Please let me know if there is any other information that might be helpful, such as the Qucs .sch file.

felix-salfelder commented 3 years ago

On Fri, Sep 17, 2021 at 12:38:34PM -0700, Dow Drake wrote:

Hi, I've been running numerous transient simulations of diode and bjt circuits using gnucsator, qucsator and sometimes ngspice. The gnucsator option has been very helpful. In most cases, gnucsator succeeds even if qucsator fails, and its results match those of ngspice, but for this simple emitter follower, which simulates correctly with qucsator and ngspice, a gnucsator assertion fails resulting in a seg fault.

Here's the netlist generated by Qucs:

# Qucs 0.0.20  /home/dow/.qucs/ch2_prj/emitter_follower.sch

BJT:Q2N3904_1 in c out c Type="npn" Is="1.4e-14" Nf="1" Nr="1" Ikf="0.025" Ikr="0" Vaf="100" Var="0" Ise="3e-13" Ne="1.5" Isc="0" Nc="2" Bf="300" Br="7.5" Rbm="0" Irb="0" Rc="2.4" Re="0" Rb="0" Cje="4.5e-12" Vje="0.75" Mje="0.33" Cjc="3.5e-12" Vjc="0.75" Mjc="0.33" Xcjc="1" Cjs="0" Vjs="0.75" Mjs="0" Fc="0.5" Tf="4e-10" Xtf="0" Vtf="0" Itf="0" Tr="2.1e-08" Temp="26.85" Kf="9e-16" Af="1" Ffe="1" Kb="0" Ab="1" Fb="1" Ptf="0" Xtb="1.5" Xti="3" Eg="1.11" Tnom="26.85" Area="1"
Vdc:V1 c gnd U="5 V"
R:R3 gnd out R="100 Ohm" Temp="26.85" Tc1="0.0" Tc2="0.0" Tnom="26.85"
Vpulse:V2 in gnd U1="0 V" U2="3 V" T1="0" T2="1 ms" Tr=".1 ms" Tf=".1 ms"
.TR:TR1 Type="lin" Start="0" Stop="1.5 ms" Points="1000" IntegrationMethod="Trapezoidal" Order="2" InitialStep="1 ns" MinStep="1e-16" MaxIter="150" reltol="0.001" abstol="1 pA" vntol="1 uV" Temp="26.85" LTEreltol="1e-3" LTEabstol="1e-6" LTEfactor="1" Solver="CroutLU" relaxTSR="no" initialDC="yes" MaxStep="0"

The message is: 

gnucsator: s_tr_swp.cc:292: bool TRANSIENT::next(): Assertion `new_dt >= _sim->_dtmin' failed.

/usr/bin/gnucsator.sh: line 47: 104922 Aborted                 (core dumped) $GNUCSATOR <<EOF
qucs
include $infile
go ${out}
status notime
EOF

I've tried a number of different values for Tr and Tf ranging from 1ps up to .1ms. I've also tried reducing MinStep to 1e-18, but so far, I haven't found a way to get the simulation to complete. I'm using the current master branch of gnucsator. Please let me know if there is any other information that might be helpful, such as the Qucs .sch file.

Hi Dow.

(CC gnucap-devel, because it has to do with gnucap. Hope you don't mind.)

There are two hacks that interfere with your circuit. The first one is the "R" device wrapper, see bm_wrapper.cc. It was meant to wrap parameters (and probes?) to qucs in a sort of flexible way. But it has side effects (a non constant resistor uses step control...) The possible approaches are

The first is certainly useful for trying out things, the third option is a bit overkill -- if everything else fails. The middle option would have to get past the test suite...

The second hack is the BJT device. Qucs has two devices in one, and there is no proper mechanism implemented in gnucap-qucs to disambiguate. See "Type" in nonlinear.v. Comment out the one you don't use to improve results. Certainly this is worth fixing with a more elaborate wrapper, or again a hacked copy of the upstream model(s). Note that the wrapper is meant to work with other BJT implementations, and a hacked copy is a bad idea long term.

ddrake commented 3 years ago

Hi Felix,

Thanks for the speedy reply!

I tried the first hack you mentioned, changing the line in my netlist.txt to: resistor:R3 gnd out r="100 Ohm", then calling gnucsator from the command line like this: $ gnucsator.sh -i netlist.txt -o ch2_prj/emitter_follower.dat This generated messages: default plugins: master 2017.10.03 ;: already installed, replacing stashing as ;:0 : already installed, replacing stashing as :0 ': already installed, replacing stashing as ':0 ": already installed, replacing stashing as ":0 L: already installed, replacing stashing as L:0 open circuit: internal node 5 open circuit: internal node 3 (+ many more warnings like this)

Gnucap System status iterations: op=0, dc=0, tran=12251, fourier=0, total=12291 transient timesteps: accepted=39, rejected=567, total=606 nodes: user=3, subckt=0, model=2, total=5 dctran density=92.0%, ac density=92.0%

A dataset was generated -- here is the plot: [cid:29244bdf-a197-4d8e-a7cc-12dca8180c38] The plot is correct except during the rise time (Tr) interval and after the fall time (Tf) interval. In contrast, Qucsator and Ngspice produce output like this (expected): [cid:cd042e99-62ca-4a7c-8b77-58273dcfaa34] I'll try the other ideas you suggested.

Best, Dow

export export_good

ddrake commented 3 years ago

I temporarily commented out the PNP version of the transistor to test -- I don't really understand why Qucs has two versions, since, for example, a 2N3904 is always an NPN -- this gave much better results. The only issue was with the output voltage during the pulse fall period -- it should reach zero before the input pulse does because of the base-emitter drop.

Best, Dow

export_better

felix-salfelder commented 3 years ago

On Fri, Sep 17, 2021 at 04:24:43PM -0700, Dow Drake wrote:

The only issue was with the output voltage during the pulse fall period -- it should reach zero before the input pulse does because of the base-emitter drop.

If I understand correctly... the simulation does not show that the output voltage does not reach zero before .0012s. The plot is a bit misleading here, look at the data points (few).

The Gnucsator transient command wrapper ignores most arguments, and runs with automatic time steps. There was no need to change this yet. Some simulator options are global, and can be set in the .rc file or at the top of the input file, by hand. ".options trtol=1" etc. But fixed time stepping is an argument to the transient command.

If you are interested in the timing of the signal approaching zero, you could add a component that depends on it. In Qucs, that would be something like

Relais:XX gnd gnd gnd out Vt="0"

Which is actually just a voltage controlled switch. Time step control should kick in, as soon as the voltage approaches the threshold.

ddrake commented 3 years ago

If I understand correctly... the simulation does not show that the output voltage does not reach zero before .0012s. The plot is a bit misleading here, look at the data points (few).

Right, I expected the output voltage to reach zero when the input voltage reached about 0.6-0.7 V (about 20 us before the input pulse reached zero) I originally used 1000 points for the transient simulation, which gives a resolution of 1.4 us. I just tried increasing to 5000 points, but it didn't make any noticeable difference in either plot.

The Gnucsator transient command wrapper ignores most arguments, and runs with automatic time steps. There was no need to change this yet.

That explains another difference between the qucsator and gnucsator simulations, namely with qucsator, the input pulse reaches zero precisely at the specified T2 value, while with gnucsator, it reaches zero 0.2 ms later; this is more like ngspice, which specifies the pulse width rather than T1 and T2 values.

Some simulator options are global, and can be set in the .rc file or at the top of the input file, by hand. ".options trtol=1" etc. But fixed time stepping is an argument to the transient command.

Thanks -- that's good to know. I'll also try your suggestion to capture the exact time when the signal reaches zero.

ddrake commented 3 years ago

From the discussion on the gnucap-devel list, I think I've misunderstood the intended use of gnucsator.

This is what Dow is trying to to: build a circuit for Qucsator, and then run it with gnucsator.

Correct!

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? 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 should probably re-read the Workbook.pdf and some of the other Qucs documentation on this topic...

felix-salfelder commented 3 years ago

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.

felix-salfelder commented 3 years ago

On Sat, Sep 18, 2021 at 11:56:30AM +0200, Felix Salfelder wrote:

The bjt wrapper in qucsator looks like this typo. read gnucsator ^

""" parameter npn=1 parameter pnp=-1

module BJT(b, c, e, s); parameter Area; parameter Type; parameter Temp; [..]

paramset mynpn npn; [..] endparamset

paramset mypnp pnp; [..] endparamset

mynpn #(.area(Area(1.+Type).5+1e-20) .temp(Temp)) p(c, b, e, s); mypnp #(.area(Area(1.-Type).5+1e-20) .temp(Temp)) p(c, b, e, s); // ** endmodule """

I've had another go at this. Actually, there is a mix of issues here.

And this is where I once gave up. Now there is a solution that fixes things where they are much easier to fix. The bjt model in Gnucap can be patched, so that it correctly handles the zero area case.

In the gnucsator/resistor+bjt branch I have included a copy of the bjt model with the patch applied, and also removed the 1e-20 hack in the wrapper. For me, this gives the same (correct) result as commenting out **, but also works for qucs bjt instances of the other polarity.

NB: passing area=0 to the spice bjt (from gnucap-models) is asking for trouble all the same.

felix-salfelder commented 3 years ago

This should be fixed in develop

ddrake commented 3 years ago

Thanks for making all those updates! I'm trying to test this, but can't get the develop branch to build:

I built and installed the latest gnucap from savannah and added it to my path I checked out the develop branch of gnucsator gnucsator seemed to configure OK: 

prefix: /home/dow/local/gnucap/install
pkglibdir: /home/dow/local/gnucap/install/lib/gnucap
plugpath: /home/dow/local/gnucap/install/lib/gnucap

I tried to build gnucsator:

In file included from /usr/include/gnucap/globals.h:24,
                 from subst_wrap.cc:2:
/usr/include/gnucap/l_dispatcher.h: In instantiation of ‘TT* DISPATCHER<TT>::clone(std::string) [with TT = MODEL_CARD; std::string = std::__cxx11::basic_string<char>]’:
subst_wrap.cc:18:42:   required from here
/usr/include/gnucap/l_dispatcher.h:196:27: error: invalid conversion from ‘CARD*’ to ‘MODEL_CARD*’ [-fpermissive]
  196 |       return proto->clone();
      |                           ^
      |                           |
      |                           CARD*
c++    -I. -std=c++11 -fPIC    -I/home/dow/local/gnucap/install/include/gnucap -DADD_VERSION -o s_sparam.so s_sparam.cc -lgsl -lblas -lgslcblas  -shared # 2
make: *** [Makefile:126: subst_wrap.so] Error 1

Any idea what I'm missing?

felix-salfelder commented 3 years ago

On Thu, Sep 23, 2021 at 03:12:40PM -0700, Dow Drake wrote:

Thanks for making all those updates! I'm trying to test this, but can't get the develop branch to build:

I built and installed the latest gnucap from savannah and added it to my path I checked out the develop branch of gnucsator gnucsator seemed to configure OK: 

prefix: /home/dow/local/gnucap/install
pkglibdir: /home/dow/local/gnucap/install/lib/gnucap
plugpath: /home/dow/local/gnucap/install/lib/gnucap

I tried to build gnucsator:

In file included from /usr/include/gnucap/globals.h:24,
                 from subst_wrap.cc:2:
[..]

Any idea what I'm missing?

It's a bug: subst_wrap.cc includes a bunch of <gnucap/*.h> ending up with the wrong installation. Possibly removing the extra "gnucap/" there is sufficient.

Will fix this one shortly. But there may be more funny problems showing up with two versions installed. Please let me know!

felix-salfelder commented 3 years ago
  • Gnucap only has spice style bjts without a polarity parameter.

... because it was designed to mimic spice.

The polarity parameter does exist internally. It would be a simple mod to bring it out. While you are there, please check the diode and mosfet too.

The spice plugins, in gnucap-models, are straight from spice with no mods.

on the bjt_zero_area branch .... catching divide by zero is good. It needs a test file to demonstrate that the problem did exist and is now fixed. When you are substituting a value, please check to be sure the substitute value makes sense.

It would have been easier if the original model just used conductance there instead of resistance. That might have completely solved the problem. It probably is not worth the effort to rewrite now.

While you are there, why not bring out the "polarity" parameter?

In some places, Spice uses a zero value as a flag to say to use the default. That may be the case here.

ddrake commented 3 years ago

Will fix this one shortly. But there may be more funny problems showing up with two versions installed. Please let me know!

I pulled your last commit and reran ./configure and tried to make, but some of the gnucap headers aren't being found now:

$ make -j4
asking /home/dow/local/gnucap/install/bin/gnucap-conf
make -C qucsator GNUCAP_CPPFLAGS="-I/home/dow/local/gnucap/install/include/gnucap -DADD_VERSION"
make[1]: Entering directory '/home/dow/local/gnucsator/qucsator'
g++ -c -fPIC matrix.cpp -o matrix.o -DNR_TINY=1e-15 -Dnr_double_t=double -DHAVE_STD_ERF
g++ -c -fPIC vector.cpp -o vector.o -DNR_TINY=1e-15 -Dnr_double_t=double -DHAVE_STD_ERF
g++ -c -fPIC complex.cpp -o complex.o -DNR_TINY=1e-15 -Dnr_double_t=double -DHAVE_STD_ERF
g++ -c -fPIC real.cpp -o real.o -DNR_TINY=1e-15 -Dnr_double_t=double -DHAVE_STD_ERF
In file included from matrix.cpp:94:
logging.h:2:10: fatal error: io_error.h: No such file or directory
    2 | #include <io_error.h>
      |          ^~~~~~~~~~~~
compilation terminated.
make[1]: *** [Makefile:23: matrix.o] Error 1
make[1]: *** Waiting for unfinished jobs....
c++    -I. -std=c++11 -fPIC    -I/home/dow/local/gnucap/install/include/gnucap -DADD_VERSION -o lang_qucs.so lang_qucs.cc   -shared # 2
In file included from vector.cpp:41:
object.h:2:10: fatal error: e_model.h: No such file or directory
    2 | #include <e_model.h>
      |          ^~~~~~~~~~~
ddrake commented 3 years ago

If it would help for sanity, I could uninstall the older apt-installed version of gnucap. I could also install the new version to the default location if that would simplify things.

ddrake commented 3 years ago

I don't know what I'm doing, but I tried also adjusting the include directives for matrix, vector, etc.. in 'qucsator/Makefile.in' like this:

fspecial.o real.o complex.o vector.o matrix.o: %.o: %.cpp
    $(CXX) $(GNUCAP_CPPFLAGS) -c -fPIC $< -o $@ -DNR_TINY=1e-15 -Dnr_double_t=double -DHAVE_STD_ERF

The compile was able to proceed, but I got a seg fault executing gnucap-modelgen d_diode.model

asking /home/dow/local/gnucap/install/bin/gnucap-conf
make -C qucsator GNUCAP_CPPFLAGS="-I/home/dow/local/gnucap/install/include/gnucap -DADD_VERSION"
make[1]: Entering directory '/home/dow/local/gnucsator/qucsator'
g++ -I/home/dow/local/gnucap/install/include/gnucap -DADD_VERSION -c -fPIC matrix.cpp -o matrix.o -DNR_TINY=1e-15 -Dnr_double_t=double -DHAVE_STD_ERF
g++ -I/home/dow/local/gnucap/install/include/gnucap -DADD_VERSION -c -fPIC vector.cpp -o vector.o -DNR_TINY=1e-15 -Dnr_double_t=double -DHAVE_STD_ERF
g++ -I/home/dow/local/gnucap/install/include/gnucap -DADD_VERSION -c -fPIC fspecial.cpp -o fspecial.o -DNR_TINY=1e-15 -Dnr_double_t=double -DHAVE_STD_ERF
make[1]: Leaving directory '/home/dow/local/gnucsator/qucsator'
c++    -I. -std=c++11 -fPIC    -I/home/dow/local/gnucap/install/include/gnucap -DADD_VERSION -o c_list.so c_list.cc   -shared # 2
c++    -I. -std=c++11 -fPIC    -I/home/dow/local/gnucap/install/include/gnucap -DADD_VERSION -o c_uninst.so c_uninst.cc   -shared # 2
c++    -I. -std=c++11 -fPIC    -I/home/dow/local/gnucap/install/include/gnucap -DADD_VERSION -o c_vpp.so c_vpp.cc   -shared # 2
c++    -I. -std=c++11 -fPIC    -I/home/dow/local/gnucap/install/include/gnucap -DADD_VERSION -o c_include.so c_include.cc   -shared # 2
c++    -I. -std=c++11 -fPIC    -I/home/dow/local/gnucap/install/include/gnucap -DADD_VERSION -o c_prbcmd.so c_prbcmd.cc   -shared # 2
c++    -I. -std=c++11 -fPIC    -I/home/dow/local/gnucap/install/include/gnucap -DADD_VERSION -o d_eqn.so d_eqn.cc   -shared # 2
c++    -I. -std=c++11 -fPIC    -I/home/dow/local/gnucap/install/include/gnucap -DADD_VERSION -o d_poly_g_uf.so d_poly_g_uf.cc   -shared # 2
c++    -I. -std=c++11 -fPIC    -I/home/dow/local/gnucap/install/include/gnucap -DADD_VERSION -o bm_poly.so bm_poly.cc   -shared # 2
c++    -I. -std=c++11 -fPIC    -I/home/dow/local/gnucap/install/include/gnucap -DADD_VERSION -o d_gpolyk_wrap.so d_gpolyk_wrap.cc   -shared # 2
c++    -I. -std=c++11 -fPIC    -I/home/dow/local/gnucap/install/include/gnucap -DADD_VERSION -o d_probe.so d_probe.cc   -shared # 2
c++    -I. -std=c++11 -fPIC    -I/home/dow/local/gnucap/install/include/gnucap -DADD_VERSION -o functions.so functions.cc   -shared # 2
c++    -I. -std=c++11 -fPIC    -I/home/dow/local/gnucap/install/include/gnucap -DADD_VERSION -o bm_value.so bm_value.cc   -shared # 2
c++    -I. -std=c++11 -fPIC    -I/home/dow/local/gnucap/install/include/gnucap -DADD_VERSION -o bm_trivial.so bm_trivial.cc   -shared # 2
c++    -I. -std=c++11 -fPIC    -I/home/dow/local/gnucap/install/include/gnucap -DADD_VERSION -o bm_wrapper.so bm_wrapper.cc   -shared # 2
c++    -I. -std=c++11 -fPIC    -I/home/dow/local/gnucap/install/include/gnucap -DADD_VERSION -o cmd_wrapper.so cmd_wrapper.cc   -shared # 2
c++    -Iqucsator -std=c++11 -fPIC    -I/home/dow/local/gnucap/install/include/gnucap -DADD_VERSION -o mscoupled_wrap.so mscoupled_wrap.cc  qucsator/mscoupled.o qucsator/msline.o qucsator/fspecial.o qucsator/complex.o qucsator/matrix.o qucsator/real.o qucsator/vector.o -shared # 2
c++    -Iqucsator -std=c++11 -fPIC    -I/home/dow/local/gnucap/install/include/gnucap -DADD_VERSION -o subst_wrap.so subst_wrap.cc  qucsator/substrate.o qucsator/fspecial.o qucsator/complex.o qucsator/matrix.o qucsator/real.o qucsator/vector.o -shared # 2
c++    -I. -std=c++11 -fPIC    -I/home/dow/local/gnucap/install/include/gnucap -DADD_VERSION -o s_tr.so s_tr.cc   -shared # 2
c++    -I. -std=c++11 -fPIC    -I/home/dow/local/gnucap/install/include/gnucap -DADD_VERSION -o s_dc.so s_dc.cc   -shared # 2
c++    -I. -std=c++11 -fPIC    -I/home/dow/local/gnucap/install/include/gnucap -DADD_VERSION -o s_sparam.so s_sparam.cc -lgsl -lblas -lgslcblas  -shared # 2
c++    -I. -std=c++11 -fPIC    -I/home/dow/local/gnucap/install/include/gnucap -DADD_VERSION -o s_sweep.so s_sweep.cc   -shared # 2
gnucap-modelgen d_diode.model
make: *** [Makefile:101: d_diode.cc] Segmentation fault (core dumped)
ddrake commented 3 years ago

Testing from the command line in ~/local/gnucsator, I can't seem to get gnucap-modelgen to work with either model file (with or without the -cc flag).

$ which gnucap-modelgen 
/home/dow/local/gnucap/install/bin/gnucap-modelgen
$ gnucap-modelgen -cc d_diode.model
Segmentation fault (core dumped)
$ gnucap-modelgen -cc d_bjt.model 
Segmentation fault (core dumped)

I tried gdb; it seems to fail trying to open the model file.

(gdb) r d_diode.model
Starting program: /home/dow/local/gnucap/install/bin/gnucap-modelgen d_diode.model

Program received signal SIGSEGV, Segmentation fault.
0x000055555556e4e0 in File::File(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) ()
(gdb) bt
#0  0x000055555556e4e0 in File::File(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) ()
#1  0x00005555555602ee in main ()
felix-salfelder commented 3 years ago

On Thu, Sep 23, 2021 at 06:34:38PM -0700, Dow Drake wrote:

Will fix this one shortly. But there may be more funny problems showing up with two versions installed. Please let me know!

I pulled your last commit and reran ./configure and tried to make, but some of the gnucap headers aren't being found now:


$ make -j4
asking /home/dow/local/gnucap/install/bin/gnucap-conf
make -C qucsator GNUCAP_CPPFLAGS="-I/home/dow/local/gnucap/install/include/gnucap -DADD_VERSION"
make[1]: Entering directory '/home/dow/local/gnucsator/qucsator'
g++ -c -fPIC matrix.cpp -o matrix.o -DNR_TINY=1e-15 -Dnr_double_t=double -DHAVE_STD_ERF
g++ -c -fPIC vector.cpp -o vector.o -DNR_TINY=1e-15 -Dnr_double_t=double -DHAVE_STD_ERF
g++ -c -fPIC complex.cpp -o complex.o -DNR_TINY=1e-15 -Dnr_double_t=double -DHAVE_STD_ERF
g++ -c -fPIC real.cpp -o real.o -DNR_TINY=1e-15 -Dnr_double_t=double -DHAVE_STD_ERF
In file included from matrix.cpp:94:
logging.h:2:10: fatal error: io_error.h: No such file or directory
    2 | #include <io_error.h>
      |          ^~~~~~~~~~~~

this was one more of the same. fixed in develop.

c++ -I. -std=c++11 -fPIC -I/home/dow/local/gnucap/install/include/gnucap -DADD_VERSION -o lang_qucs.so lang_qucs.cc -shared # 2 In file included from vector.cpp:41: object.h:2:10: fatal error: e_model.h: No such file or directory 2 | #include | ^~~

this one I don't understand. it should have found /home/dow/local/gnucap/install/include/gnucap/e_model.h

felix-salfelder commented 3 years ago

On Thu, Sep 23, 2021 at 07:42:36PM -0700, Dow Drake wrote:

gnucap-modelgen d_diode.model make: *** [Makefile:101: d_diode.cc] Segmentation fault (core dumped)

I think gnucap-modelgen is looked for in $PATH, which I think is set correctly, or it wouldn't have found gnucap-conf. perhaps there is a library confusion. check LD_LIBRARY_PATH. it should include /home/dow/local/lib (or so). try

$ which gnucap-modelgen $ ldd which gnucap-modelgen

felix-salfelder commented 3 years ago

On Thu, Sep 23, 2021 at 07:06:32PM -0700, Dow Drake wrote:

If it would help for sanity, I could uninstall the older apt-installed version of gnucap. I could also install the new version to the default location if that would simplify things.

I will add instructions to build and install *.deb archives for the latest version. Perhaps the correct way forward is to test them and eventually upload new ones.

felix-salfelder commented 3 years ago

On Fri, Sep 24, 2021 at 09:49:37AM +0200, Felix Salfelder wrote:

I will add instructions to build and install *.deb archives [..]

http://gnucap.org/dokuwiki/doku.php/gnucap:debian_manual_build

ddrake commented 3 years ago

perhaps there is a library confusion. check LD_LIBRARY_PATH. it should include /home/dow/local/lib (or so). try

$ which gnucap-modelgen $ ldd which gnucap-modelgen\

Yes! that was the issue -- it was referencing the old library. Adding the local/gnucap/install/lib to LD_LIBRARY_PATH then building gnucsator at commit 6d62501 succeeds :-). I should have thought to check that -- I appreciate your help!

Even though this fixed the build, I ran into other version issues so I uninstalled the old gnucap via apt and tried the instructions you posted for the debian manual build. The only issue was with: dpkg-buildpackage -rfakeroot I had to modify it to: dpkg-buildpackage -rfakeroot -d --no-sign The -d option was necessary because debhelper-compat (=13) is not available for Ubuntu 20.04. debhelper only includes debhelper-compat (<=12)

The issues with the resistor and transistor polarity are fixed now. The only issue remaining is a warning: 

@@#
@@@
incomplete:qucsator/component.h:97:~circuit

also I think the output voltage (out.Vt) of the emitter follower during the fall time period is still not quite correct (the difference in pulse durations is not an issue since I see how to set it). These simulations have 1000 points. gnucsator export_gnucsator qucsator export_good

felix-salfelder commented 3 years ago

On Fri, Sep 24, 2021 at 02:36:16PM -0700, Dow Drake wrote:

[build debian package manually] I had to modify it to: dpkg-buildpackage -rfakeroot -d --no-sign

Great, thanks. I updated the wiki.

@@#
@@@
incomplete:qucsator/component.h:97:~circuit

also I think the output voltage (out.Vt) of the emitter follower during the fall time period is still not quite correct

(the difference in pulse durations is not an issue since I see how to set it).

Probably this is an oversight in bm_wrapper.cc line 332.

It should really all go to include/*.v following the resistor...

These simulations have 1000 points.

With the switch (bjt_pulse1.net) I get a pretty useful answer with only 20 points.

You can have more points. look at cmd_wrapper line 400. substitute

The third parameter is the maximum time between two printed timesteps. Sure you'll find a way to feed in the value from the input file.

ddrake commented 3 years ago

The pulse time is consistent with Qucs now -- that's great! But I'm still seeing the same warnings (incomplete in circuit destructor etc...), and the output voltage is still not staying a diode drop below the input during the fall time period. qucsator export_good gnucsator export_timefix

felix-salfelder commented 3 years ago

On Sat, Sep 25, 2021 at 08:28:41AM -0700, Dow Drake wrote:

[..] the output voltage is still not staying a diode drop below the input during the fall time period.

From your plot, it seems you are not using a switch ("Relais"). Please paste the full netlist.

cf. tests/bjt_pulse{0,1}.net and tests/ref/bjt_pulse{0,1}.net.gc.out.

Please plot with dots only, not with lines. Lines between dots are not meaningful. They can be misleading and may hide the actual data.

ddrake commented 3 years ago

You're right, I'm not using a switch, its the "Voltage Pulse" component in Qucs. The netlist is the same as in my original comment above:

# Qucs 0.0.20  /home/dow/.qucs/ch2_prj/emitter_follower.sch

BJT:Q2N3904_1 in c out c Type="npn" Is="1.4e-14" Nf="1" Nr="1" Ikf="0.025" Ikr="0" Vaf="100" Var="0" Ise="3e-13" Ne="1.5" Isc="0" Nc="2" Bf="300" Br="7.5" Rbm="0" Irb="0" Rc="2.4" Re="0" Rb="0" Cje="4.5e-12" Vje="0.75" Mje="0.33" Cjc="3.5e-12" Vjc="0.75" Mjc="0.33" Xcjc="1" Cjs="0" Vjs="0.75" Mjs="0" Fc="0.5" Tf="4e-10" Xtf="0" Vtf="0" Itf="0" Tr="2.1e-08" Temp="26.85" Kf="9e-16" Af="1" Ffe="1" Kb="0" Ab="1" Fb="1" Ptf="0" Xtb="1.5" Xti="3" Eg="1.11" Tnom="26.85" Area="1"
Vdc:V1 c gnd U="5 V"
R:R3 gnd out R="100 Ohm" Temp="26.85" Tc1="0.0" Tc2="0.0" Tnom="26.85"
Vpulse:V2 in gnd U1="0 V" U2="3 V" T1="0" T2="1 ms" Tr=".1 ms" Tf=".1 ms"
.TR:TR1 Type="lin" Start="0" Stop="1.5 ms" Points="1000" IntegrationMethod="Trapezoidal" Order="2" InitialStep="1 ns" MinStep="1e-16" MaxIter="150" reltol="0.001" abstol="1 pA" vntol="1 uV" Temp="26.85" LTEreltol="1e-3" LTEabstol="1e-6" LTEfactor="1" Solver="CroutLU" relaxTSR="no" initialDC="yes" MaxStep="0"

I see your point about plotting with dots. The lines were causing me to misinterpret the gnucsator results. Here's a Matplotlib-generated plot using dot markers:

emitter-follower

It may be that if the data file generated by gnucsator included a few data points during the fall period (similarly to what it's doing in the rise period), the line plots would appear to match. I didn't understand what you were saying here earlier, but I'll try it now:

You can have more points. look at cmd_wrapper line 400. substitute

  • x << j._start << " " << j._stop << " " << j._stop
  • x << j._start << " " << j._stop << " " << j._stop/1000.

The third parameter is the maximum time between two printed timesteps. Sure you'll find a way to feed in the value from the input file.

ddrake commented 3 years ago

OK -- with additional points, the plots agree. Sorry -- should've tried that sooner! I guess it's OK to disregard the warning. Thanks for your patience on this!

ddrake commented 3 years ago

Sure you'll find a way to feed in the value from the input file.

This might have side-effects I'm not aware of, but I modified the tran_t struct to include _points, then used it here: x << j._start << " " << j._stop << " " << j._stop/(j._points - 1)

That makes the gnucsator and qucsator transient simulations essentially identical.

Edit: to handle nonzero start, changed to: x << j._start << " " << j._stop << " " << (j._stop-j._start)/(j._points - 1)

Edit: to be a bit more careful...

x << j._start << " " << j._stop << " ";
if (j._points > 1) {
        x << (j._stop-j._start)/(j._points-1);
}
x << " trace=a basic > " << _outfile << ".tr";