Menu

Can I use subcircuit parameter for ACMAG?

simpletk
2023-05-31
2023-05-31
  • simpletk

    simpletk - 2023-05-31

    I'm using subcircuit, in AC analysis I need to specify the amplitude e.g. 0.5 in this case it works (I see amplitude approaching 0.5 as that's the fixed value I used for ACMAG):

    * first line is ignored
    .subckt MYSOURCE pos neg PARAMS: v=0.2 f=200
    V1 pos neg DC 0 AC 0.5 SIN (0 {v} {f} 0 0 0)
    .ends
    X1 1 0 MYSOURCE PARAMS: v=0.7 f=400
    C1 1 2 10n
    R1 2 0 50k
    .print ac vm(2)
    .ac oct 40 16 2000
    .end
    

    But if I try to put {v} in place of ACMAG, it does not work:

    * this does not work
    .subckt MYSOURCE pos neg PARAMS: v=0.2 f=200
    V1 pos neg DC 0 AC {v} SIN (0 {v} {f} 0 0 0)
    .ends
    X1 1 0 MYSOURCE PARAMS: v=0.7 f=400
    C1 1 2 10n
    R1 2 0 50k
    .print ac vm(2)
    .ac oct 40 16 2000
    .end
    

    It shows error:

    Error on line 0 :
      v.x1.v1 1 0 dc 0 ac ( 1 0 )    7.000000000000000e-01     sin (0    7.000000000000000e-01        4.000000000000000e+02     0 0 0)
    no such parameter on this device
        Simulation interrupted due to error!
    

    Does it mean I cannot use parameter for ACMAG? or does it need some other format?

    I'm using ngspice 36

     

    Last edit: simpletk 2023-05-31
  • Giles Atkinson

    Giles Atkinson - 2023-05-31

    It seems fine in the current version (40). So your syntax is OK, but that is a limitation of version 36.

     
    • Holger Vogt

      Holger Vogt - 2023-05-31

      This was a bug in ngspice-36 and has been fixed in ngspice-37.
      Please see https://sourceforge.net/p/ngspice/bugs/604/.

       
  • dick freebird

    dick freebird - 2023-05-31

    I seldom (if ever) "stack" those kinds of source-type arguments, and
    it seems to me like declaring both a "DC" and a "SIN" either bakes in
    some conflict, or demands that "somebody" decide which is in play for
    .tran (is it the DC level, or the sine wave?

    If that decision is being made, its basis and outcome ought to be made
    plain to the user. If this is part of later versions which made that line
    syntax "acceptable", is there anything by way of an examples superset,
    and a description about "superseding" logic where too many attributes
    in conflict, are parsed out to "whatever the .tran is really going to do"
    (sometime before run and results, would be nice, so as to be able to
    predict rather than debug and react)

    I might also suggest a debug aid, which I have seen sometimes - that is,
    a caret (^) printed below the offending line, indicating just where it
    went off the rails. OP asks whether it's the AC magnitude that is the
    problem; I can't see in the report line, any indication of which bit
    offends. If this were made plain, perhaps fewer "WTF?" posts as
    "local debug" would be more enabled?

     

Log in to post a comment.