[Help-gnucap] Re: using a pipe to make gnucap accept input from other program

[Hugo Coolens]

al davis wrote:
Thanks for the reply Al. It clarifies lots of things. Because the 
message has become rather large, I hope you don't mind I just quote some 
parts
> Now I see what you are asking for ..  You want the stdin pipe to 
> act like the "-b" batch mode, and would probably accept 
> the "-b" option with no file to represent that. 
>
> How about:
>
> "./makespicefile 2 | gnucap -b /dev/stdin"
thanks, that is exactly what I needed

> > when you start making real large circuits this is not elegant
> > to do and a waste of time and resources.
> > The script can be used to produce real large circuits to
> > compare different spice-versions (accuracy, maximum number of
> > nodes ...)
>
>
> I am not convinced that you get a meaningful comparison this 
> way.  I would like to know what you find out.
I have used it to discover the maximum number of nodes some 
Spice-version accept. I didn't perform "speed tests" with it yet.
If I found an example which demonstrates differences in accuracy I'll 
let you know

> I have found that usually gnucap is faster than spice.  There 
> are cases where spice is faster, but not by much.  I have test 
> cases where gnucap is a lot faster, including one that takes 40 
> seconds for gnucap, 8 hours for ng-spice.  Gnucap run time is 
> roughly linearly proportional to size.  Spice run time is 
> quadratic.  Circuits that are small, very connected, and very 
> nonlinear tend to run faster in Spice.  Circuits that are 
> large, sparsely connected, have significant linear or nearly 
> linear content, tend to run faster in gnucap.  Gnucap AC 
> analysis is nothing special, except you should get linear time 
> instead of quadratic.
>
>
>
> > The script:
> >
> > #! /bin/bash
> > #use: makespicefile number_of_sections
> > echo 'test'
> > echo 'vin 1 0 ac 1'
> > for ((i=1; i<$1+1 ; i++))
> >     do
> >       echo r$i $i $((i+1)) '1'
> >       echo c$i $((i+1)) 0  '1'
> >     done
> > echo '.print ac' 'v('$i')'
> > #print-statement _before_ analysis necessary for gnucap
> > echo '.options numdgt=7'
> > echo '.ac dec 20 10m 1000 basic'
> > echo '.end'
>
>
> The "print statement before analysis" is done for good reasons.  
> For one, analyzing and saving "all data" is very inefficient, 
> and you don't really save "all data".  This is what lets you 
> probe anything.  Really saving "all data" including internal 
> values of models would really be inefficient.  The way it is, 
> you pick what you want to see, and are not burdened with what 
> you don't care about today.
>
> In real life, you attach probes to a circuit, then turn it on 
> and observe the instruments.  The gnucap way is more like the 
> real lab.
>
> The reason Spice does it the way it does goes back to the small 
> computers of the 70's, where you needed overlays to fit a large 
> program into small memory.  It is a multi-pass system.  
> The "raw file" is the interface between the simulator engine 
> and a post-processor.  Computers are bigger now, so we don't 
> need to do it that way anymore.
I understand what you mean but wouldn't it be nicer to have gnucap do 
itself the task of choosing the right statement order when using batch-mode?


best regards,
hugo