From: Oswald B. <os...@kd...> - 2007-01-28 12:26:29
|
moin läutz, for tactical reasons i'll start with some praise: the schematic editor is the best i've used so far - absolutely no comparison with eagle and its horrible clone geda. :-) that's it for the praise. :-P i had a look at the qucsator source. it became immediately clear to me that the properties model is inefficient. so i ran it through callgrind ... it's not inefficient, it's a major perfomance disaster. i suggest you switch to a properties model like qt's one: the properties are normal variables and are publicized with accessors (just in-line them in the headers) and some meta data (in the moc file). in fact, you might want to actually use Qt4Core. qucsator should have a switch to suppress the "notify" messages. it has a significant performance impact as well. i see this only in the cvs version so far, but still. there seem to be some erroneous values in some models: WARNING: Unphysical model parameter Nf = 0.9955 in BJT `BC548BP_1' WARNING: Unphysical model parameter Nf = 0.9872 in BJT `BC560AP_1' capacitor charging seems to be completely broken in cvs as of now, so i can't verify the other problems i had scheduled for reporting. anyway, the basic opamp model could be *a little* less basic: * separate Umin - for obvious reasons, i hope * some noise/randomness at init time ... otherwise many oscillating circuits won't even "fire up" with the idealized components. * putting a "generic non-ideal" opamp based on what is described in the tutorial into the lib would be quite helpful, i imagine. more sure to come later. ;) -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
From: Oswald B. <os...@kd...> - 2007-01-28 13:50:48
Attachments:
capacitor.dpl
capacitor.sch
|
On Sun, Jan 28, 2007 at 01:26:26PM +0100, Oswald Buddenhagen wrote: > capacitor charging seems to be completely broken in cvs as of now, so > i can't verify the other problems i had scheduled for reporting. > interestingly enough, it's the same with 0.0.10. however, 0.0.9 works fine. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
From: Stefan J. <st...@gr...> - 2007-02-09 08:24:49
|
Am Do, 1.02.2007, 00:44, schrieb Oswald Buddenhagen: hello oswald, >> >> probably you can send me a link (inet) where the circuit is described >> as >> >> well as the actual model your version is based on? >> >> >> > i think i got it here: >> > http://homepages.internet.lu/absolute3/tronic/szdiscr.htm >> >> Ok, thanks. >> Unfortunately there are (partly) no values given for the C's and R's. >> :-( >> > who's the electronics engineer here? ;) hm. you are? > i did some more experimenting ... > with R2 (in my schematic) equal to 6k8 and C1 680pF the circuit actually > works - at 50kHz, which also seems to be really close to the limit. if > R2 is too big, the discharge never triggers, if it is too small, it > never unlocks. if the capacitor is too small, the discharge doesn't > trigger as well. i think especially oscillators are sensitive to their components values. so this is something you can actually expect? > i think i assumed too much ideality from the standard components (i > tried the default transistors before the BC5*) - probably because it is > highly inconsistent (compare the opamp model). the default transistors/diodes are quite ideal in fact. no series resistance, no junction capacitances and alike. that's what the properties are for. > some actual bugs in the gui now: > - the schematic view has some selective repainting problems. it seems to > misinterpret the region information (maybe a global vs. local > coordinates thing) - you can observe it very well by moving a small > window over it. that's probably a Qt "proplem"? > - the widgets in the component properties dialog have weird repainting > problems which temporarily disappear when one first resizes the > dialog, then closes and then opens it again. > this sounds a lot like this thing should go through valgrind. that is as well a Qt problem which is known to us. probably also a general X windows problem? i don't know. if you find out it would be a good contribution to Qt/X i think. > another thing ... not a bug, rather an inherent problem (i assume): the > simulation behavior (primarily time) varies *extremely* between even > almost trivial circuits. for somebody not really understanding *all* the > parameters it is virtually impossible to tune the simulation for > acceptable results; in a more complex circuit it is probably actually > impossible to find a compromise between the local optima. > there should be more/more obvious knobs to limit the cpu time spent on a > single simulation step. ideally, it would also give an estimation of the > quality reached. taking this further, the system could tune itself, at > best for particular subcircuits. who wants to make a PhD soon? ;} you're right this is an inherent problem. i assume you refer to transient simulation. this type of simulation solves a set of non-linear equations. this system has the following properties/problems: * there is an unlimited set of solutions * numerical noise plays sometimes an important role * numerical overflow must also be avoided * a "wide-range time-constant circuit" causes ill-conditioned solution matrix -> difficult to solve * etc, etc., etc. i was constantly working on these issues and tried my best so far to handle all these problems. it's always like part of the problem are in the device models and part of them in the simulation algorithm. i think we already get some good results with the current implementations. new ideas and inputs are always welcome. i suggest you to probably read the technical documentation (qucs-doc cvs) or the pdf file on the homepage. most aspects of transient simulation are covered somehow. remarks on it would be nice and could help me to re-consider some things. also a tutorial about the transient simulation and its properties would be welcome. you could use some example schematics with apparent convergence difficulties and show how those "knobs" and "workarounds" can be be applied to solve these issues appropriately. in fact to triggered a topic which is still worth research, though a thousand times already applied. please don't mind this kind of answer. :-) cheers, stefan. |
From: Oswald B. <os...@kd...> - 2007-02-09 09:07:58
|
On Fri, Feb 09, 2007 at 09:24:34AM +0100, Stefan Jahn wrote: > Am Do, 1.02.2007, 00:44, schrieb Oswald Buddenhagen: > > who's the electronics engineer here? ;) > > hm. you are? > i assumed you are (going to be), as this is what the contact page says. ;) i'm not, fwiw. i'm an amateur since my early childhood and had some EE classes at uni, but that's it. i never had much luck with analog electronics, let alone HF. :} > i think especially oscillators are sensitive to their components values. > so this is something you can actually expect? > this is something i definitely expect from reality, yes. :) > > i think i assumed too much ideality from the standard components (i > > tried the default transistors before the BC5*) - probably because it is > > highly inconsistent (compare the opamp model). > > the default transistors/diodes are quite ideal in fact. no series > resistance, no junction capacitances and alike. > hmm, but there must be some timing dependance. i guess one'd have to do further analysis. > > some actual bugs in the gui now: > > - the schematic view has some selective repainting problems. > > that's probably a Qt "proplem"? > > > - the widgets in the component properties dialog have weird > > repainting problems > > that is as well a Qt problem which is known to us. > given that both happen only sporadically, i tend to suspect that we are seeing the effects of some serious memory corruption ... > > this sounds a lot like this thing should go through valgrind. > ... so i can't stress this enough. > > another thing ... not a bug, rather an inherent problem (i assume): > > you're right this is an inherent problem. [...] > new ideas and inputs are always welcome. i suggest you to probably > read the technical documentation (qucs-doc cvs) or the pdf file on the > homepage. most aspects of transient simulation are covered somehow. > remarks on it would be nice and could help me to re-consider some > things. > that's something i'd love to do ... but there is little chance that i will. first, my spare time is unfortunately quite limited. and even if it wasn't, i already have a plethora of other projects in the pipe. second, i must admit that much of what i find in the tech docs is way over my head (and i know i'm a real EE wiz compared to most other software guys :}). > also a tutorial about the transient simulation and its properties would be > welcome. you could use some example schematics with apparent convergence > difficulties and show how those "knobs" and "workarounds" can be be > applied to solve these issues appropriately. > if i only understood them myself ... :} just for fun ;) i attached another schematic. this is supposed to be a synchronous rectifier. in the current configuration it aborts with a jacobian singular (wtf?) before the end of the first period. with ideal opamps it doesn't even get started (in finite time, that is). i managed to get it move a bit by adding capacitors between the opamp's pins, but that didn't help *that* much, either. if you have some tips or even an estimate whether this has a chance of working in reality, i'd be glad to hear it. > in fact to triggered a topic which is still worth research, though a > thousand times already applied. please don't mind this kind of answer. :-) > oh, i can take that. gimme more. :) -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
From: Oswald B. <os...@kd...> - 2007-02-09 09:38:21
Attachments:
gleichrichter-opamp.sch
gleichrichter-opamp.dpl
|
On Fri, Feb 09, 2007 at 10:07:43AM +0100, Oswald Buddenhagen wrote: > just for fun ;) i attached another schematic. > oh, right ... the attachment ... :} > this is supposed to be a synchronous rectifier. > in the current configuration it aborts with a jacobian singular (wtf?) > before the end of the first period. > with ideal opamps it doesn't even get started (in finite time, that is). > i managed to get it move a bit by adding capacitors between the opamp's > pins, but that didn't help *that* much, either. > if you have some tips or even an estimate whether this has a chance of > working in reality, i'd be glad to hear it. > -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
From: Stefan J. <st...@gr...> - 2007-02-09 13:47:31
Attachments:
gleichrichter-opamp.sch
gleichrichter-opamp.dpl
|
Am Fr, 9.02.2007, 10:07, schrieb Oswald Buddenhagen: Hello Oswald, >> > i think i assumed too much ideality from the standard components (i >> > tried the default transistors before the BC5*) - probably because it >> is >> > highly inconsistent (compare the opamp model). >> >> the default transistors/diodes are quite ideal in fact. no series >> resistance, no junction capacitances and alike. >> > hmm, but there must be some timing dependance. i guess one'd have to do > further analysis. There is no timing dependency whithout Caps and Transit times. >> > some actual bugs in the gui now: >> > - the schematic view has some selective repainting problems. >> >> that's probably a Qt "proplem"? >> >> > - the widgets in the component properties dialog have weird >> > repainting problems >> >> that is as well a Qt problem which is known to us. >> > given that both happen only sporadically, i tend to suspect that we are > seeing the effects of some serious memory corruption ... > >> > this sounds a lot like this thing should go through valgrind. >> > ... so i can't stress this enough. Yep. Please do. > just for fun ;) i attached another schematic. this is supposed to be a > synchronous rectifier. > in the current configuration it aborts with a jacobian singular (wtf?) > before the end of the first period. > with ideal opamps it doesn't even get started (in finite time, that is). > i managed to get it move a bit by adding capacitors between the opamp's > pins, but that didn't help *that* much, either. > if you have some tips or even an estimate whether this has a chance of > working in reality, i'd be glad to hear it. The singular Jacobian appears with ill-conditioned matrices. The Jacobian is the derivative matrix of the actual circuit matrix. That's just for your information. I played a bit with simulation options. Also with the input voltage which is now 10V. Attached the "working" circuit. It lasts 1/2 hour or so... So this is actually not acceptable because you might be faster to build it in this time for real... But it's a start. Cheers, Stefan. |
From: roucaries b. <rou...@gm...> - 2007-02-09 17:07:48
|
On 2/9/07, Stefan Jahn <st...@gr...> wrote: > Am Fr, 9.02.2007, 10:07, schrieb Oswald Buddenhagen: > > Hello Oswald, > > >> > i think i assumed too much ideality from the standard components (i > >> > tried the default transistors before the BC5*) - probably because it > >> is > >> > highly inconsistent (compare the opamp model). > >> > >> the default transistors/diodes are quite ideal in fact. no series > >> resistance, no junction capacitances and alike. > >> > > hmm, but there must be some timing dependance. i guess one'd have to do > > further analysis. > > There is no timing dependency whithout Caps and Transit times. > > >> > some actual bugs in the gui now: > >> > - the schematic view has some selective repainting problems. > >> > >> that's probably a Qt "proplem"? > >> > >> > - the widgets in the component properties dialog have weird > >> > repainting problems > >> > >> that is as well a Qt problem which is known to us. > >> > > given that both happen only sporadically, i tend to suspect that we are > > seeing the effects of some serious memory corruption ... > > > >> > this sounds a lot like this thing should go through valgrind. > >> > > ... so i can't stress this enough. > > Yep. Please do. > > > just for fun ;) i attached another schematic. this is supposed to be a > > synchronous rectifier. > > in the current configuration it aborts with a jacobian singular (wtf?) > > before the end of the first period. > > with ideal opamps it doesn't even get started (in finite time, that is). > > i managed to get it move a bit by adding capacitors between the opamp's > > pins, but that didn't help *that* much, either. > > if you have some tips or even an estimate whether this has a chance of > > working in reality, i'd be glad to hear it. > > The singular Jacobian appears with ill-conditioned matrices. The Jacobian > is the derivative matrix of the actual circuit matrix. Nice, now that we are talking about ill and strange circuit, I will like to see qucs simulate a self-mixer oscillator, particularly doing a stabilty analysis and determination of mixer product amplitude By experience, the worst circuit are self-mixer, oscillator, pulse generator. opamps circuit become well behaved if you replace ideal opamps by non ideal opamps. Regards Bastien > That's just for your information. > > I played a bit with simulation options. Also with the input voltage which > is now 10V. > > Attached the "working" circuit. It lasts 1/2 hour or so... So this is > actually not acceptable because you might be faster to build it in this > time for real... But it's a start. > > Cheers, Stefan. > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier. > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Qucs-devel mailing list > Quc...@li... > https://lists.sourceforge.net/lists/listinfo/qucs-devel > > > |
From: Stefan J. <st...@gr...> - 2007-02-09 17:53:49
|
Am Fr, 9.02.2007, 18:07, schrieb roucaries bastien: Hello Bastien, > Nice, now that we are talking about ill and strange circuit, I will > like to see qucs simulate a self-mixer oscillator, particularly doing > a stabilty analysis and determination of mixer product amplitude > > By experience, the worst circuit are self-mixer, oscillator, pulse > generator. > opamps circuit become well behaved if you replace ideal opamps by non > ideal opamps. Well. Good luck. :-) Cheers, Stefan. |
From: roucaries b. <rou...@gm...> - 2007-02-09 18:07:53
|
On 2/9/07, Stefan Jahn <st...@gr...> wrote: > Am Fr, 9.02.2007, 18:07, schrieb roucaries bastien: > > Hello Bastien, > > > Nice, now that we are talking about ill and strange circuit, I will > > like to see qucs simulate a self-mixer oscillator, particularly doing > > a stabilty analysis and determination of mixer product amplitude > > > > By experience, the worst circuit are self-mixer, oscillator, pulse > > generator. > > opamps circuit become well behaved if you replace ideal opamps by non > > ideal opamps. > > Well. Good luck. :-) Yes I know, but If I achieve to have time I will try to implement an tutorial for the circuit on the publication on the previous email. What is the status of HB simulation? If ok , at least I will try to simulate it, even ADS has some problem to simulate this kind of circuit :-). Regards bastien > Cheers, Stefan. > > |
From: Stefan J. <st...@gr...> - 2007-01-28 13:58:14
|
Am So, 28.01.2007, 14:50, schrieb Oswald Buddenhagen: Hi! >> capacitor charging seems to be completely broken in cvs as of now, so >> i can't verify the other problems i had scheduled for reporting. >> > interestingly enough, it's the same with 0.0.10. however, 0.0.9 works > fine. In 0.0.10 you can switch "initialDC" to "no" to get results from earlier versions. :-) Cheers, Stefan. |
From: Oswald B. <os...@kd...> - 2007-01-28 18:03:04
Attachments:
sawtooth-discreet.dpl
sawtooth-discreet.sch
|
On Sun, Jan 28, 2007 at 02:57:59PM +0100, Stefan Jahn wrote: > Am So, 28.01.2007, 14:50, schrieb Oswald Buddenhagen: > >> capacitor charging seems to be completely broken in cvs as of now, so > >> i can't verify the other problems i had scheduled for reporting. > >> > > interestingly enough, it's the same with 0.0.10. however, 0.0.9 works > > fine. > > In 0.0.10 you can switch "initialDC" to "no" to get results from earlier > versions. :-) > much better, indeed. in fact, almost all my interesting circuits fail completely with initialDC yes - either with a straight line or with an error message. so now to the other problems ... sawtooth-discreet: the discharge transistors don't switch through. bah, enough for now. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
From: Stefan J. <st...@gr...> - 2007-01-29 11:11:12
|
Am So, 28.01.2007, 19:02, schrieb Oswald Buddenhagen: Hello! >> >> capacitor charging seems to be completely broken in cvs as of now, so >> >> i can't verify the other problems i had scheduled for reporting. >> >> >> > interestingly enough, it's the same with 0.0.10. however, 0.0.9 works >> > fine. >> >> In 0.0.10 you can switch "initialDC" to "no" to get results from earlier >> versions. :-) >> > much better, indeed. in fact, almost all my interesting circuits fail > completely with initialDC yes - either with a straight line or with an > error message. > > so now to the other problems ... > > sawtooth-discreet: the discharge transistors don't switch through. > > bah, enough for now. So what is the circuit supposed to do? Cheers, Stefan. |
From: Oswald B. <os...@kd...> - 2007-01-29 17:57:06
|
On Mon, Jan 29, 2007 at 12:11:02PM +0100, Stefan Jahn wrote: > > sawtooth-discreet: the discharge transistors don't switch through. > > > So what is the circuit supposed to do? > c'mon, can't you read circuits? ;) it should generate a sawtooth voltage. it's pretty much a standard circuit - taken from the net. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
From: Stefan J. <st...@gr...> - 2007-01-31 08:00:33
|
Am Mo, 29.01.2007, 18:56, schrieb Oswald Buddenhagen: Hi! >> > sawtooth-discreet: the discharge transistors don't switch through. >> > >> So what is the circuit supposed to do? >> > c'mon, can't you read circuits? ;) > it should generate a sawtooth voltage. it's pretty much a standard > circuit - taken from the net. i've never played with this kind of circuit. so i would rather be asked to help getting it go instead of understanding it fully by myself. sorry for my "laziness". probably you can send me a link (inet) where the circuit is described as well as the actual model your version is based on? cheers, stefan. |
From: Oswald B. <os...@kd...> - 2007-01-31 09:40:07
|
On Wed, Jan 31, 2007 at 08:59:41AM +0100, Stefan Jahn wrote: > probably you can send me a link (inet) where the circuit is described as > well as the actual model your version is based on? > i think i got it here: http://homepages.internet.lu/absolute3/tronic/szdiscr.htm dunno what you mean by "actual model". -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
From: Stefan J. <st...@gr...> - 2007-01-31 15:09:56
|
Am Mi, 31.01.2007, 10:40, schrieb Oswald Buddenhagen: Hi! >> probably you can send me a link (inet) where the circuit is described as >> well as the actual model your version is based on? >> > i think i got it here: > http://homepages.internet.lu/absolute3/tronic/szdiscr.htm Ok, thanks. Unfortunately there are (partly) no values given for the C's and R's. :-( > dunno what you mean by "actual model". I thought you had a spice circuit file forming an existing sawtooth generator which is the base for the model you wanted to simulate in Qucs. Apparently you have not such a file. Cheers, Stefan. |
From: Oswald B. <os...@kd...> - 2007-01-31 23:44:18
|
On Wed, Jan 31, 2007 at 04:09:35PM +0100, Stefan Jahn wrote: > >> probably you can send me a link (inet) where the circuit is described as > >> well as the actual model your version is based on? > >> > > i think i got it here: > > http://homepages.internet.lu/absolute3/tronic/szdiscr.htm > > Ok, thanks. > Unfortunately there are (partly) no values given for the C's and R's. > :-( > who's the electronics engineer here? ;) i did some more experimenting ... with R2 (in my schematic) equal to 6k8 and C1 680pF the circuit actually works - at 50kHz, which also seems to be really close to the limit. if R2 is too big, the discharge never triggers, if it is too small, it never unlocks. if the capacitor is too small, the discharge doesn't trigger as well. i think i assumed too much ideality from the standard components (i tried the default transistors before the BC5*) - probably because it is highly inconsistent (compare the opamp model). > Apparently you have not such a file. > indeed. some actual bugs in the gui now: - the schematic view has some selective repainting problems. it seems to misinterpret the region information (maybe a global vs. local coordinates thing) - you can observe it very well by moving a small window over it. - the widgets in the component properties dialog have weird repainting problems which temporarily disappear when one first resizes the dialog, then closes and then opens it again. this sounds a lot like this thing should go through valgrind. another thing ... not a bug, rather an inherent problem (i assume): the simulation behavior (primarily time) varies *extremely* between even almost trivial circuits. for somebody not really understanding *all* the parameters it is virtually impossible to tune the simulation for acceptable results; in a more complex circuit it is probably actually impossible to find a compromise between the local optima. there should be more/more obvious knobs to limit the cpu time spent on a single simulation step. ideally, it would also give an estimation of the quality reached. taking this further, the system could tune itself, at best for particular subcircuits. who wants to make a PhD soon? ;} -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
From: Stefan J. <st...@gr...> - 2007-02-07 20:03:10
|
Am So, 28.01.2007, 13:26, schrieb Oswald Buddenhagen: > moin läutz, hi oswald, > for tactical reasons i'll start with some praise: the schematic > editor is the best i've used so far - absolutely no comparison with > eagle and its horrible clone geda. :-) > that's it for the praise. :-P thanks, anyway. :-) > i had a look at the qucsator source. it became immediately clear to me > that the properties model is inefficient. so i ran it through callgrind > ... it's not inefficient, it's a major perfomance disaster. can you provide testcase + profiler output? > i suggest you switch to a properties model like qt's one: the > properties are normal variables and are publicized with accessors (just > in-line them in the headers) and some meta data (in the moc file). in > fact, you might want to actually use Qt4Core. Qt is currently not an option for the simulator. It's completely written without Qt libraries. > qucsator should have a switch to suppress the "notify" messages. it has > a significant performance impact as well. i see this only in the cvs > version so far, but still. > > there seem to be some erroneous values in some models: > WARNING: Unphysical model parameter Nf = 0.9955 in BJT `BC548BP_1' > WARNING: Unphysical model parameter Nf = 0.9872 in BJT `BC560AP_1' I am going to discuss it with Michael. Michael: We could add such an option. Probably "simulator options" in the GUI (under application settings/document settings)??? Oswald: per document or global? > capacitor charging seems to be completely broken in cvs as of now, so > i can't verify the other problems i had scheduled for reporting. Well, we figured this one out. > anyway, the basic opamp model could be *a little* less basic: > * separate Umin - for obvious reasons, i hope Hm. It's not too obvious to me. What do you mean? zero voltage input should give zero output, did I miss something? > * some noise/randomness at init time ... otherwise many oscillating > circuits won't even "fire up" with the idealized components. Hm. Again. :-) There are LOADS of tutorials/notes how this is performed in pratice. The most common is to add a sin(t)*exp(-t*x) source into the oscillating part of the circuit, but not into the biasing network... > * putting a "generic non-ideal" opamp based on what is described in the > tutorial into the lib would be quite helpful, i imagine. Mike Brinson (author of the tutorial) is going to do that sooner or later. He is on CC. Cheers, Stefan. |
From: Oswald B. <os...@kd...> - 2007-02-08 16:47:09
|
On Wed, Feb 07, 2007 at 09:02:21PM +0100, Stefan Jahn wrote: > Am So, 28.01.2007, 13:26, schrieb Oswald Buddenhagen: > > i had a look at the qucsator source. it became immediately clear to me > > that the properties model is inefficient. so i ran it through callgrind > > ... it's not inefficient, it's a major perfomance disaster. > i should probably note that this applies only to "one-shot" simulation (dc/ac) and becomes relevant for parameter sweeps with very many steps. transient simulation is practically unaffected, as the property values are cached in the components. > can you provide testcase + profiler output? > here are the test cases and callgrind dumps. you need to install kcachegrind yourself to make sense of it. > > i suggest you switch to a properties model like qt's one: the > > properties are normal variables and are publicized with accessors (just > > in-line them in the headers) and some meta data (in the moc file). in > > fact, you might want to actually use Qt4Core. > > Qt is currently not an option for the simulator. > It's completely written without Qt libraries. > that's not a reason not to, though. ;) > > qucsator should have a switch to suppress the "notify" messages. it has > > a significant performance impact as well. i see this only in the cvs > > version so far, but still. > > > I am going to discuss it with Michael. > > Michael: We could add such an option. Probably "simulator options" in > the GUI (under application settings/document settings)??? > > Oswald: per document or global? > i think global is enough. > > anyway, the basic opamp model could be *a little* less basic: > > * separate Umin - for obvious reasons, i hope > > Hm. It's not too obvious to me. What do you mean? zero voltage input > should give zero output, did I miss something? > (+)=0 & (-)=Umax will give -Umax, which is not exactly what should happen in a circuit with a positive supply only. for other circuits it can mask away clipping, pretending that a circuit will work when it would not. fwiw, does somebody feel like adding some p-channel hexfets to the lib? particularly interesting for me would be the two-in-one irf7389. :) -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
From: Stefan J. <st...@gr...> - 2007-02-09 07:04:21
|
Am Do, 8.02.2007, 17:46, schrieb Oswald Buddenhagen: Hello Oswald, >> > i had a look at the qucsator source. it became immediately clear to me >> > that the properties model is inefficient. so i ran it through >> callgrind >> > ... it's not inefficient, it's a major perfomance disaster. >> > i should probably note that this applies only to "one-shot" simulation > (dc/ac) and becomes relevant for parameter sweeps with very many steps. > transient simulation is practically unaffected, as the property values > are cached in the components. > >> can you provide testcase + profiler output? >> > here are the test cases and callgrind dumps. you need to install > kcachegrind yourself to make sense of it. hm. i installed valgrind on my debian machine. fine. unfortunately i don't have kde at hand... we'll see. >> > anyway, the basic opamp model could be *a little* less basic: >> > * separate Umin - for obvious reasons, i hope >> >> Hm. It's not too obvious to me. What do you mean? zero voltage input >> should give zero output, did I miss something? >> > (+)=0 & (-)=Umax will give -Umax, which is not exactly what should > happen in a circuit with a positive supply only. for other circuits it > can mask away clipping, pretending that a circuit will work when it > would not. i see what you mean... going to think about it. > fwiw, does somebody feel like adding some p-channel hexfets to the lib? > particularly interesting for me would be the two-in-one irf7389. :) you could to that? provide a model + symbol, then we can add it to the libraries... btw: you could provide example schematics for the homepage. the examples with those sawtooth generator look good to me. :-) with a little "prosa" around those, we can put it at <http://qucs.sourceforge.net/download.html#example> what do you think? cheers, stefan. |
From: Oswald B. <os...@kd...> - 2007-02-09 09:36:09
|
On Fri, Feb 09, 2007 at 08:04:07AM +0100, Stefan Jahn wrote: > Am Do, 8.02.2007, 17:46, schrieb Oswald Buddenhagen: > > here are the test cases and callgrind dumps. you need to install > > kcachegrind yourself to make sense of it. > > hm. i installed valgrind on my debian machine. fine. unfortunately > i don't have kde at hand... we'll see. > oh, kcachegrind + kdelibs shouldn't be much more than 30 mb. and you already have qt3 ... >8-) i could upload some screenshots, but i deem this to be too selective. > >> > anyway, the basic opamp model could be *a little* less basic: > >> > * separate Umin - for obvious reasons, i hope > >> [...] > > i see what you mean... going to think about it. > thx > > fwiw, does somebody feel like adding some p-channel hexfets to the lib? > > particularly interesting for me would be the two-in-one irf7389. :) > > you could to that? > i tried to modify the irfs' n-channel model, but failed miserably so far (btw, is there a way to automatically create a rudimental schematic from a netlist?). let alone tuning it to some real transistors ... this resembles tuning the color convergence of an old tube with a delta beam configuration ... quite frustrating experience ... :} > btw: you could provide example schematics for the homepage. the examples > with those sawtooth generator look good to me. :-) with a little "prosa" > around those, we can put it at > <http://qucs.sourceforge.net/download.html#example> > let's put it this way: hereby put all my schmatics posted to this list and notes regarding them into the public domain. :) i'm sort of a miserable and unwilling writer, so i'd prefer not to be the one to make something publishable out of it. greets -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
From: Stefan J. <st...@gr...> - 2007-03-05 12:25:51
|
Am Fr, 9.02.2007, 10:35, schrieb Oswald Buddenhagen: Hello Oswald, >> > here are the test cases and callgrind dumps. you need to install >> > kcachegrind yourself to make sense of it. >> >> hm. i installed valgrind on my debian machine. fine. unfortunately >> i don't have kde at hand... we'll see. >> > oh, kcachegrind + kdelibs shouldn't be much more than 30 mb. and you > already have qt3 ... >8-) > i could upload some screenshots, but i deem this to be too selective. ok, i started using valgrind for memory leak detection. it helps a very lot! i used libefence and ccmalloc for these purposes previously but valgrinf seems much better somehow. thanks. >> > fwiw, does somebody feel like adding some p-channel hexfets to the >> lib? >> > particularly interesting for me would be the two-in-one irf7389. :) >> >> you could to that? >> > i tried to modify the irfs' n-channel model, but failed miserably so far > (btw, is there a way to automatically create a rudimental schematic from > a netlist?). let alone tuning it to some real transistors ... this > resembles tuning the color convergence of an old tube with a delta beam > configuration ... quite frustrating experience ... :} unfortunately there is such way to automatically create a schematic for spice netlists... i am sorry. >> btw: you could provide example schematics for the homepage. the >> examples >> with those sawtooth generator look good to me. :-) with a little >> "prosa" >> around those, we can put it at >> <http://qucs.sourceforge.net/download.html#example> >> > let's put it this way: hereby put all my schmatics posted to this list > and notes regarding them into the public domain. :) > i'm sort of a miserable and unwilling writer, so i'd prefer not to be > the one to make something publishable out of it. have now placed 4 working variants of sawtooth generators on the homepage. cheers, stefan. |