Holger Vogt

Its just the other way round. The model of a variable cap is completely handled inside of ngspice. rshunt is added to that model, as it it added to all of the flattened device nodes. If the user adds rshunt, he/she is not aware that an intrinsic model is changed (with negative outcome). Unfortunately a warning is not possible, nor an automatiuc exclusion of the cap model. The warning I have been talking about is just to say that if XSPICE is not compiled in, rshunt is not available., as .option statements...

tiny correction

ngspice is an open source project. If you have any comments, feedback or patches to improve ngspice, you are welcome.

The control block is the way to go. Why do you think it may be slow? Of course things may be added. When I had to do it, I would use an automated control block. If you are aware of any other means, you might provide a patch.

Unable to set the number of pulses on PULSE voltage sources (46)

Your circuit from above will not produce a single pulse. For obtaining a single pulse: You may change the PER parameter to 500u or larger. You may add the NP parameter 1 (after compiling master branch, see below). However, a large PER and "set ng-behavior=xs" are compatible only in a very limited range of phase given, as the phase (in degrees) is transformed into a time shift as PHASE/360*PER, so phase relative to PER. With PER=500u (single pulse) a phase (NP)=-3.6 will yield a shifting of the pulse...

I think this can transition to closed-invalid. Maybe not quite, for two reasons (even if a poster should not make useless recommendations to the devs): Even if it is documented that rshunt depends on XSPIXE made available, there is no logical or funtional connection between the two. Thus a warning is reasonable (three lines of code). We might even think of shifting the rshunt option into the base ngspice code. When I add rshunt, I try try to estimate that such resistors (say 1e9 Ohms) will not hurt...

I think this can transition to closed-invalid. Maybe not quite, for two reasons (even if a poster should not make useless recommendations to the devs): Even if it is documented that rshunt depends on XSPIXE made available, there is no logical or funtional connection between the two. Thus a warning is reasonable (three lines of code). We might even think of shifting the rshunt option into the base ngspice code. When I add rshunt, I try try to estimate that such resistors (say 1e9 Ohms) will not hurt...