Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
From: Clifford Wolf <clifford@cl...>  20071226 08:20:20
Attachments:
multivib.tar.gz

Hi, I'm still playing around with multivibrators in transient simulation. This one is nice: attached you will find two identical schematics which produce almost the same netlist. The only difference between the netlists is the order of the statements. But the results of the transient simulation are very different. (the first one fails after producing moreorless accurate results and the other one runs thru but nothing vibrates..) I think the problem is that in the 2nd case the evaluation order of the nodes is different so the transistor is evaluated after the value of its base contact has been calculated, overwriting the initial DC value I have set using the label. Which is quite strange because I thought that my label would cause the initial dc analyses to charge the capacitor on this wire so the wire should stay longer on a high voltage that just for step 0. Whats the error in my understanding of what's going on when doing a transient simulation of this circuit? thanks for your help. yours,  clifford PS: In digital simulation there usually (= verilog does it this way ;) are two state arrays  one for the old and one for the new state, which are swaped after each time slice. This way the evaluation order of the elements is irrelevant..  "The generation of random numbers is too important to be left to chance."  Robert R. Coveyou, Oak Ridge National Laboratory. 
From: Stefan Jahn <stefan@gr...>  20071229 12:07:58

Am Mi, 26.12.2007, 09:15, schrieb Clifford Wolf: > Hi, Hello! > I'm still playing around with multivibrators in transient simulation. This > one is nice: attached you will find two identical schematics which produce > almost the same netlist. The only difference between the netlists is the > order of the statements. But the results of the transient simulation are > very different. (the first one fails after producing moreorless accurate > results and the other one runs thru but nothing vibrates..) > > I think the problem is that in the 2nd case the evaluation order of the > nodes is different so the transistor is evaluated after the value of its > base contact has been calculated, overwriting the initial DC value I have > set using the label. Which is quite strange because I thought that my > label > would cause the initial dc analyses to charge the capacitor on this wire > so > the wire should stay longer on a high voltage that just for step 0. > > Whats the error in my understanding of what's going on when doing a > transient simulation of this circuit? This one is also known... And an ugly one, I know. Right now the position in the netlist in fact determines somehow, how nodes are put into the circuit matrix to be solved which in turn may affect the result due to numerical issues. One of the solution of this problem may be to find a way to reorder the matrix to be solved in a way to 1) get a deterministic ordering 2) and find an order which makes the matrix "easier" to solve If someone on the list has a better clue than me right now how to achieve (2) then please tell me. In the qucsator core there is already an sorting algorithm, but this just cares about pairs of +1 and 1 (e.g. voltage sources) and not about the actual node order... Cheers, Stefan. 
From: Bastien ROUCARIES <roucaries.bastien@gm...>  20071229 12:19:01

Le samedi 29 d=E9cembre 2007, Stefan Jahn a =E9crit=A0: > Am Mi, 26.12.2007, 09:15, schrieb Clifford Wolf: > > Hi, > > Hello! > > > I'm still playing around with multivibrators in transient simulation. > > This one is nice: attached you will find two identical schematics which > > produce almost the same netlist. The only difference between the netlis= ts > > is the order of the statements. But the results of the transient > > simulation are very different. (the first one fails after producing > > moreorless accurate results and the other one runs thru but nothing > > vibrates..) > > > > I think the problem is that in the 2nd case the evaluation order of the > > nodes is different so the transistor is evaluated after the value of its > > base contact has been calculated, overwriting the initial DC value I ha= ve > > set using the label. Which is quite strange because I thought that my > > label > > would cause the initial dc analyses to charge the capacitor on this wire > > so > > the wire should stay longer on a high voltage that just for step 0. > > > > Whats the error in my understanding of what's going on when doing a > > transient simulation of this circuit? > > This one is also known... And an ugly one, I know. > > Right now the position in the netlist in fact determines somehow, how > nodes are put into the circuit matrix to be solved which in turn may > affect the result due to numerical issues. > > One of the solution of this problem may be to find a way to reorder > the matrix to be solved in a way to > > 1) get a deterministic ordering > 2) and find an order which makes the matrix "easier" to solve > > If someone on the list has a better clue than me right now how to > achieve (2) then please tell me. In the qucsator core there is > already an sorting algorithm, but this just cares about pairs of > +1 and 1 (e.g. voltage sources) and not about the actual node > order... Could you please give me the equation to solve? I suppose it is an inversion. IF so the magic key is preconditionning. I can try to help when I will come back form vaccation (ie 2008/01/08). Regards=20 Bastien > Cheers, Stefan. > > >  > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Qucshelp mailing list > Qucshelp@... > https://lists.sourceforge.net/lists/listinfo/qucshelp =2D=20 "ROUCARIES Bastien" roucaries.bastien@...= com =2D= =2D DO NOT WRITE TO roucaries.bastien+blackhole@... OR BE BLACKLISTED 
From: Stefan Jahn <stefan@gr...>  20071229 12:24:35

Am Sa, 29.12.2007, 13:20, schrieb Bastien ROUCARIES: Hello! >> > I'm still playing around with multivibrators in transient simulation. >> > This one is nice: attached you will find two identical schematics >> which >> > produce almost the same netlist. The only difference between the >> netlists >> > is the order of the statements. But the results of the transient >> > simulation are very different. (the first one fails after producing >> > moreorless accurate results and the other one runs thru but nothing >> > vibrates..) >> > >> > I think the problem is that in the 2nd case the evaluation order of >> the >> > nodes is different so the transistor is evaluated after the value of >> its >> > base contact has been calculated, overwriting the initial DC value I >> have >> > set using the label. Which is quite strange because I thought that my >> > label >> > would cause the initial dc analyses to charge the capacitor on this >> wire >> > so >> > the wire should stay longer on a high voltage that just for step 0. >> > >> > Whats the error in my understanding of what's going on when doing a >> > transient simulation of this circuit? >> >> This one is also known... And an ugly one, I know. >> >> Right now the position in the netlist in fact determines somehow, how >> nodes are put into the circuit matrix to be solved which in turn may >> affect the result due to numerical issues. >> >> One of the solution of this problem may be to find a way to reorder >> the matrix to be solved in a way to >> >> 1) get a deterministic ordering >> 2) and find an order which makes the matrix "easier" to solve >> >> If someone on the list has a better clue than me right now how to >> achieve (2) then please tell me. In the qucsator core there is >> already an sorting algorithm, but this just cares about pairs of >> +1 and 1 (e.g. voltage sources) and not about the actual node >> order... > > Could you please give me the equation to solve? > I suppose it is an inversion. Some of the implemented equation system solvers (e.g. LU, QR, SVD) decompose the matrix, then solve the system using additionally the righthand side... > IF so the magic key is preconditionning. I know :))) > I can try to help when I will come back form vaccation (ie 2008/01/08). If you have some preconditionknowledge I would be glad if you can share it... Cheers, Stefan. 
From: Stefan Jahn <stefan@gr...>  20071229 12:59:52

Am Sa, 29.12.2007, 13:27, schrieb Bastien ROUCARIES: Hello! > In fact I know a world class specialist of precondionning and inversion > problem. He is sitting in the building near me at uni. I will try to talk > to > him about the problem. > > Could you give me some pointer to documentation? He is a pure math guy, so > in > order to have a quick and efficient tip, we need to ask him a mathematical > question. THerefore could you explain fully the problem? It is something like this: * equation systems can be solved with different solvers (e.g. LU, QR, SVD, inversion, etc.) * the given matrix and right hand side can be modified (exchanging columns or rows) without chaning the euqation system * during some of the solution algorithms pivoting is used; this leaves also a degree of freedom (pivot element can be choosen) * the method, matrix order as well as the pivotstrategy give slightly different results due to numerical errors Thus the question is: Is there a preconditionmethod which allows a solver to solve the equation system more accurate (even for almost singular matrices). I think a precondition always must consider which solver/decomposer is used and also which pivotstrategy is used. Hope this is a question in fact, Stefan. 
Sign up for the SourceForge newsletter:
No, thanks