On Mon, Jan 16, 2012 at 01:45:11AM -0500, al davis wrote: > On Sunday 15 January 2012, Paul Reichl wrote: > > I am fairly new to gnucap and spice and I have a question > > regarding the use of subcircuits and the solution times > > when using them. I have a circuit network with about 500 or > > so sets of either; R and L, R, L and C, or R, L, C and > > I, elements in series. If I perform an AC analysis when > > using this circuit it takes only about 3 seconds to run > > (which is great:-) ). > > > > However, if the same circuit is written in terms of a number > > of subcircuits (essentially RL subcircuits, RLC subcircuits > > and RLCI subcircuits, with roughly 500 or so subcircuit > > elements in total) and I performs the same AC analysis > > again, it now takes roughly 1500 seconds to run. (i.e. the > > same analysis with the same underlying circuit when using > > subcircuits is roughly 500 times slower than the one done > > without using them).
i had different phenomena with a series-of-inverters benchmark circuit. depending on the order option i got *very* different results. obviously this is caused by the matrix structure and roughly the bandwidth of the matrix is crucial. i have hacked the code a bit to support node allocation _after_ all i_want_matrix have been called. also i have implemented a component-wise allocator. this yields a matrix *00000000000000000000000000000000 0***00000000000000000000000000000 0***00*00000000000000000000000000 0***00*0000000000000000000000000* 0000***0000000000000000000000000* 0000***00*0000000000000000000000* 00*****00*000000000000000000000** 0000000***000000000000000000000** 0000000***00*000000000000000000** 00000*****00*000000000000000000** 0000000000***000000000000000000** 0000000000***00*000000000000000** 00000000*****00*000000000000000** 0000000000000***000000000000000** 0000000000000***00*000000000000** 00000000000*****00*000000000000** 0000000000000000***000000000000** 0000000000000000***00*000000000** 00000000000000*****00*000000000** 0000000000000000000***000000000** 0000000000000000000***00*000000** 00000000000000000*****00*000000** 0000000000000000000000***000000** 0000000000000000000000***00*000** 00000000000000000000*****00*000** 0000000000000000000000000***000** 0000000000000000000000000***00*** 00000000000000000000000*****00*** 0000000000000000000000000000***** 0000000000000000000000000000***** 00000000000000000000000000******* 000000*************************** 000****************************** instead of *00000000000000000000000000000000 0*0000000000**0000000000000000000 00*000000000****00000000000000000 000*00000000******000000000000000 0000*0000000********0000000000000 00000*000000**********00000000000 000000*00000************000000000 0000000*0000**************0000000 00000000*000****************00000 000000000*00******************000 0000000000*0********************0 00000000000*********************0 0*******************************0 0*******************************0 00******************************0 00******************************0 000*****************************0 000*****************************0 0000****************************0 0000****************************0 00000***************************0 00000***************************0 000000**************************0 000000**************************0 0000000*************************0 0000000*************************0 00000000************************0 00000000************************0 000000000***********************0 000000000***********************0 0000000000*********************** 0000000000*********************** 000000000000000000000000000000*** with the 'auto' allocator. i guess this is just a corner case, but it shows there are possible improvements. i was planning to give reverse-cuthill-mckee a try (see http://math.temple.edu/~daffi/software/rcm/) due to lack of time, i am stuck in the preprocessor 'tricks' in rcm.{c,h}, so i couldnt compile it in the end (yet). if anybody around likes to play with it: the current state is in my 'rcm' branch (amongst other unimportant things). > If you are so inclined, the best way to improve the run time is > to make plugins that implement the combinations you use as > single elements without internal nodes. Making such optimized > models is not easy, but can be done. There is work in progress > on porting the ADMS model compiler, but I don't think it will > help with the simple devices. so theres another model compiler in production? (we have worked on porting the admsXml spice-wrapper stuff to generate native gnucap code, some parts are missing though). are you proposing to use a model compiler just because the internal nodes are currently allocated unluckily by gnucap? (what am i missing?) regards felix _______________________________________________ Help-gnucap mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-gnucap
