dick freebird

The qualities of VSIG probably matter but it's all {} so no way to check. Maybe you should plot and inspect that and the first buffer output after.

Since you're coarse-stepping the analysis ("by") you could as easily put the dc OP (no sweep) inside an alterparam / reset loop. Look for those examples specifically. Then, how to export what you want saved so you can grind on the results either inside or outside ngspice.

When you say "wrong", best consult the man in the mirror about criteria and confidence (about who's actually "right"). Many analog transistor bodges have multiple stable states besides the one you might be imagining or working toward. You could have a lame startup circuit or just a bad captured schematic or stupid units on every transistor (meters vs microns). Or that startup might not be as robust to the character of supply-ramp as you'd like (to Matthias' ramp suggestion - play with ramp rate,...

I think that all I want to do, is be able to something like tail -f myBuffer | ngspice -blahblah >&barfGoesHere so I can throw command sstream at the front (from other application, like Xschem augmentation menu subtree or some "SPICE manager") and catch the stuff coming out (by a similar tail-sniffer). That's how SDA>Cadence ran our Harris SLICE (2G6++) FORTRAN engine as their cdsSpice.

And your debug of this issue, according to advice so far, says what? Here is the root of the "Docker" mess you seem to be using. There's pages and pages of setup advice below the "ReadMe" bookmark. https://github.com/iic-jku/IIC-OSIC-TOOLS I still suspect you have put your .lib file someplace that the blindered Docker doesn't allow you to access. Or that you have simply failed to inform ngspice of the searchPath. These should be easy to check (especially the latter). If you can "see" the .lib using...

What I have seen is that these "containers" block off whole swaths of the filesystem and the user knows nothing. You'd have to wade through "container" docs or see if the file manager tool cooperates and only shows you what "the container" sees (trouble I had was, I could see everything but the software couldn't; how do you debug when there's "two sets of books" but you only get to see one?). Sandboxes are for toddlers. The containerized CAD bundles that have been deployed around the few open source...

What I have seen is that these "containers" block off whole swaths of the filesystem and the user knows nothing. You'd have to wade through "container" docs or see if the file manager tool cooperates and only shows you what "the container" sees (trouble I had was, I could see everything but the software couldn't; how do you debug when there's "two sets of books" but you only get to see one?). Sandboxes are for toddlers.

Way back when, I cut my baby engineer teeth on a corporate-enhanced SPICE2G. Our scheme used a "TEMPDC" user variable and eschewed TEMP, the built-in. All our models used table functions for the model params, defined in a long include-chain and indexed by TEMPDC (TEMP left at 25 or 27) so no aspect of operation was left to built-in defaults. We "owned" that. Not sure that anecdote is helpful but it shows things that could be done, with function definitions and startup scripts inlined to the simulation...