There is more than one sub-circuit definition with this name, which is ill-formed

Question

There is more than one sub-circuit definition with this name, which is ill-formed. updated today from older version 17.0.36 i believe. Now get this error on older simulation that worked. Someone else post this issue back in January as well. What is the solution?

MStokowski · Accepted Answer

Hi jsteck , 
 LTspice used to arbitrarily choose a model or subcircuit definition from multiple defs of the same name. No warning; no way of knowing LTspice had done this. Earlier versions of LTspice gave the impression that it had done something deterministic, when it had at best, flipped a coin. The best solution is to get rid of the definitions you do not want to use, or subjugate them. 
 Or, if you prefer the lottery approach&mdash;a return to the previous behavior&mdash;you can add this to your schematic (but you will still get a warning): 
 .options allow_ambiguous_models 
 mike)

MStokowski · Answer

Hi Mark536 , 
 Mark536 said: Without the "=true" there is no syntax error but does not solve the problem, it still fails with 
 Can you upload your schematics, symbols, and libraries. Zip it all up and drag to this window. 
 Mark536 said: Near as I can tell the duplicates are always identical. I saw a suggestion elsewhere that LTspice should check if they are the same, and if so use it without failing. 
 I believe this is only the case for entire files being identical, not if sections within libraries are duplicated. I will confirm. 
 MStokowski said: Or, if you prefer the lottery approach—a return to the previous behavior—you can add this to your schematic (but you will still get a warning): 
 .options allow_ambiguous_models=true 
 I made a mistake. It should be: 
 .options allow_ambiguous_models 
 mike

MStokowski · Answer

Hi Mark536 , 
 Have your tried clearing these errors: 
 Y:\Downloads\ShowLTspiceProblem	lv1861.lib(81): No such node. 
 G_G1 IN+ V- TABLE { V(CONTROL_IBN+, 0) } 
 ^^^^^^^^^^^^ 
 Y:\Downloads\ShowLTspiceProblem	lv1861.lib(88): No such node. 
 G_G2 IN- V- TABLE { V(CONTROL_IBN-, 0) } 
 ^^^^^^^^^^^^ 
 mike

MStokowski · Answer

Hi Mark536 , 
 SPICE (generic) netlists have no scoping; they are flat. 
 Mark536 said: OK, so I came across a solution somewhere else (can't even remember now). Someone said the models are written incorrectly (or at least not best practice). The problem is that every subckt in the LIB file is at the top level of scope. If you take the first .ENDS statement in the file and move it to the end of the file, then all the subckts are inside the first (main) model -- e.g. the are scoped to only that single device model. 
 Correct. 
 Change the names of the problem subckt statements in one of the libraries and you should be good to go. I can't vouch for the veracity of the models themselves, of course. 
 Longer historical explanation below: 
 Old LTspice (like XVII) did not check for duplicate models in a syntax checker, it simply ran the simulation from the flattened nettlist and picked a model, which is non-ideal. In fact, before the duplicate model check was implemented, this essentially made LTspice nondeterministic, with it coin-flipping the choice of duplicate model. 
 The "Allow ambiguous models" option was only added to appease users of Old LTspice who complained about the syntax check stopping their (probably) non-deterministic simulations. The statement, "it worked" was fraught, in that it wasn't working; Old LTspice (XVII) was giving the appearance of working. Allow ambiguous models enabled the return of the coin flip, buyer beware. It is highly discouraged. In your particular case, you would not want to allow such ambiguity, it would cause problems because the models are not identical in the different libraries. 
 Mark536 said: I have to believe the models work correctly as-is in the PSPICE-FOR-TI simulation tool (a derivative of Cadence PSpice). Maybe PSpice automatically scopes everything in a LIB files to avoid this sort of problem. 
 This might make the case for a work-stopping syntax check even stronger. I checked to see if Pspice also flattens the netlist and then simulates. It does , suggesting that these libraries are malformed if ever used in conjunction in Pspice, as you have done in LTspice, with Pspice actually simply picking the first sub it finds. Google search suggests this is actually the case. Odds are quite low that these two libraries were ever tested together. 
 In short, the appearance of "working" is really mistranslating "running" to "working", when there is no logical reason to do so. 
 So it is tempting to equate "it simulated" to "I have to believe the models work correctly". You are not the first to make this illogical leap, nor will you be the last. :-) The syntax checker, although annoying when pointing out the problems of old models, might, in this case, indicate that neither Old LTspice (XVII) nor even current Pspice are actually using the models as intended. My belief is that both Old LTspice and Pspice would yield a wrong result in some cases without fixing the duplicate names problem. 
 mike

Popular Forums

Product Forums

Application Forums

Design Center Forums

Highlighted Webinar

Places

Libraries

Challenge Yourself!

What's Brewing

Places

Resources

Visit ContentZone

The Latest Read

New Release

Recent Technical Insights

Related Questions

Multiple sub-circuit definition with same name 0

Thread Details

There is more than one sub-circuit definition with this name, which is ill-formed

Thread Summary