I think there is a misconception in the Eagle ltspice.ulp about the use of "SpiceModel":
Within LTSpiceIV (no effect within Eagle) the "ModelFile" indicates a library of one or more sub-circuits/models within one file, the "ModelFile" requires a filename with syntax [<folder>/]<name>[.<ext>] within the standard \lib\sub\ folder, normally containing the standard sub-circuits/models.
If you want to change, during simulation in LTSpice, the model of a library device, e.g. another voltage for a TVS from the SMAJxxx_CA library, the "SpiceModel" field defines the default model and lets you select one of sub-circuits/models defined in the library from a drop-down list if you click it, if the "ModelFile" exists. The "SpiceModel" field should then contain a valid sub-circuit/model-name from the library file or be empty.
In the Eagle ltspice.ulp, "ModelFile" field is not generated, there is no means of defining the filename for auto symbol generation from the attributes.
Therefor, I think, it makes no sense that "SpiceModel" is implemented, because the "ModelFile" (assuming that the symbols for libraries are auto-generated) is never there.
In the current state it only makes sense to not define the attribute or put "NONE" in the "SpiceModel" field (which the ltspice.ulp skips) of the symbol export, it is only a nuisance now because there is no additional value for defining "SpiceModel".
There can be value for defining the "SpiceModel" field, if a "ModelFile" attribute would also be processed by the ltspice.ulp.
Maybe I missed another usage for the "ModelFile" generation by the ltspice.ulp, then I would be glad to learn its usage.
Best regards, Sjef.
