LTspice 24.1.4 incompatibilities (with LTspice 24.0.12 and earlier)

Dear twopif ,

Thank you very much for this detailed bug report. We really appreciate it. The next update (24.1.5) will have all this corrected. Some notes:

In prior LTspice versions, just defining a parameter "temp" does not change the circuit temperature. You need to use ".temp" or ".options temp=...". This is rather messy and has already caused problems. Thus, 24.1 doesn't allow defining a parameter "temp". Starting with 24.1.5, you can do so however inside sub-circuits. I believe this is an acceptable compromise because it only affects top-level-schematics, not libraries.

.param temp={temp}

inside a sub-circuit has always been ill-formed. However, this line was ignored as long as there is a corresponding instance or sub-circuit parameter with the same name. (You don't need this line, the instance and sub-circuit parameters are found anyway.) 24.1.5 will do the same.

The default value for "GMIN" is not the actual gmin-option, but always the constant 1e-12.

Prior versions interpreted "%" as numeric scaling suffix 0.01. (E.g. 23% = 0.23) I removed this when I enabled the "%" as modulo operator. This shouldn't be a problem, because to my knowledge no other spice simulator supports this and it was undocumented.

You'll also find the help updated. For instance, using expressions as node names is now officially supported and documented.

Best Regards,
Mathias

Hi Mathias,

I downloaded 24.1.5 last week and verified each issue:

1. OK.
   Many thanks for officially supporting this functionality now.
2. OK, but possibly there is still a small bug.
   Strangely, it matters if “.temp=27” (the default temperature) is specified on the provided example sheet or not (you get an error “Ill-formed parameter cycle: temp.”). Isn't that weird?
3. OK, perfect.
   Characters “?” and “!” are both accepted again in subckt names.
4. OK.
   Only in some rare cases (due to “.param temp={temp}”), the user has to define “.param Gmin=1E-12” on top level schematic now. So there seems to be a behavior difference between the default Gmin of 1E-12 and a user defined Gmin of 1E-12.
5. OK.
6. OK.

Thanks for fixing all of them.

With the improved LTspice24.1.5 I was able to do further testing. The new syntax-checker even found a few bugs in my own libraries (a few missing “)”), so that’s doing a better job.

I also found a few new (24.1.4/5 - 24.0.12) incompatibilities.

• 7. A "division by zero" error from the syntax checker.

This code “.param C=if(A==0,B,1/A)” is creating a “division by zero” error when .param A=0. We can rewrite this as “.param C=if(A==0,B,1/if(A==0,1,A))” to prevent the error, but that becomes quite bad/silly code in my opinion.

The “else” part is never executed (because A==0), so it should not be evaluated by the syntax checker (and the compiler). I think the usual approach is to do an optimalisation (“.param C=B”) prior to the evaluation of the expressions (but I’m not an expert in this area).
See issue07_divzero.asc.

• 8. Comment (“;”) after .LIB statement produces error: “File not found”.

See issue08_libcomment.asc.

• 9. The “continuation of previous line” syntax is not functioning for comment (*).

See issue09_pluscomment.asc.

Only issue 7 is a showstopper for me.

Issue 8 and 9 are just FYI. A .LIB is not allowed in encrypted libraries, so only Issue 9 can be a problem for some lib-files.Issues_LTspice_24_1_5.zip

Dear twopif,

Thanks for checking and letting us know! Points (7) and (8) are indeed bugs and will be fixed in the next update.

Point (8): The semicolon ";" is a valid character in file names..LIB allows you to specify a filename that contains white space, without using quotes. .INC does not. (Don't beat me for this legacy behavior.) To that end, I argue that prior versions were inconsistent by giving ";" special treatment. Thus we'll leave it as is for the time being. Workaround: Use quotes

.lib "issue08_libcomment.txt" ; my lib.

Points (2) and (4) I cannot reproduce. Could you explain in more detail?

Best Regards,
Mathias

Hi Mathias,

Herewith a bit more explanation on how to reproduce the mentioned errors.

Regarding point 2:
If you remove the two lines “.option temp=..” and “.param temp=..” in file issue02_diode_temp.asc, you should see the error. But if the line “.option temp=..” is put back, the error does not occur anymore.

Regarding point 4:
After removing the two lines “.option Gmin=..” and “.param Gmin=..“, in file Issue04_diode_Gmin1.asc the error should become visible. So the line “.param Gmin=..” is needed to prevent the error.

Both make that the behavior is not exactly equal to LTspice24.0.12. But they can be simply solved by just adding a command on the main-sheet. I have no problem with that, so for me this is very acceptable.

Hi twopif ,

POINT 2
————

Ah, yes, I was able to reproduce the .options temp vs. .temp error in another schematic. Assume you are talking about this:

LTspice 24.1.5 for Windows
Circuit: C:\users\crossover\Documents\LTspice\24.1 Bugs\Issues_LTspice_24_1_4\Issue02_diode_temp.net
Start Time: Tue Mar 18 13:54:25 2025
Options: temp=47
C:\users\crossover\Documents\LTspice\24.1 Bugs\Issues_LTspice_24_1_4\Issue02_diode_temp.net(21): Temperature already set elsewhere.
.option temp=47 ; it is possible to change the default global environment temperature from 27 to ...
       ^^^^^^^^
C:\users\crossover\Documents\LTspice\24.1 Bugs\Issues_LTspice_24_1_4\Issue02_diode_temp.net(20): Previous definition:
.temp = 47 ; alternate syntax for .option temp=47
^^^^^^^^^^

In this case, where .temp has one value, it acts like .options temp = <value>. Note that .temp can also be used as a substitute for .step temp list <value> <value>. See below.

Nevertheless, I could not reproduce getting the error to go away by simply removing .options temp = 47 and then adding back in. Commenting, uncommenting, same result.

That said, you are correct that .temp = <value> acts like .options temp = <value>; but only when .temp has a single value:

LTspice 24.1.5 for Windows
Circuit: C:\users\crossover\Documents\LTspice\24.1 Bugs\Issues_LTspice_24_1_4\Issue02_diode_temp.net
Start Time: Tue Mar 18 13:51:29 2025
solver = Normal
Maximum thread count: 16
tnom = 27
temp = 47
method = modified trap
Direct Newton iteration for .op point succeeded.
Total elapsed time: 0.111 seconds.

Otherwise, with multiple values, it is a shorthand for .step temp list <value> <value>, but not for .op, for some reason. Have to follow up on that. You can see .temp value value acting as .step temp list value value by running a .tran on your circuit.

You don't need to try, since I already did:

.step temp list <value1> <value2>
.temp <value2> <value3>

This will be noted as an error in a later version…

mike

Dear twopif ,

Thanks for clarifying. I adjusted the parameter look-up accordingly to make this work again. Note though that this will only work for sub-circuits at top level, not for nested sub-circuits. As weird as it may seem, this is consistent with the legacy look-up rules. Will go out with the next update.

Best Regards,
Mathias

Hi Mike,

My previous answer was a just recipe to reproduce the error (as requested by Mathias), but I think you did not read it carefully enough. You had to remove (or comment) two other lines to get the proper error: “Ill-formed parameter cycle: temp.”. This error can be prevented by using “.option temp=27” (or any other temperature value).

So isn’t it weird that you get a different result just by “repeating” the default temperature setting. In other words, there seems to be a difference between the (default) temperature set by the program and the user.

It's just something strange I noticed. If you think this normal behavior, don’t spend time here anymore. I already know how to bypass it.

Thanks for the lesson about the several methods to set the temperature in LTspice.

Hi twopif ,

Ah, yes, I misread your statement about commenting out the .option temp line and the .param temp line:

twopif said:

If you remove the two lines “.option temp=..” and “.param temp=..” in file issue02_diode_temp.asc, you should see the error. But if the line “.option temp=..” is put back, the error does not occur anymore.

I did this, and possibly Mathias did the same, since the focus appeared be on the action of commenting then uncommenting the .options line:

So, if I comment out all of the lines, including .temp, I do get the error:

As for the workaround:

twopif said:

So isn’t it weird that you get a different result just by “repeating” the default temperature setting. In other words, there seems to be a difference between the (default) temperature set by the program and the user.

It's just something strange I noticed. If you think this normal behavior, don’t spend time here anymore. I already know how to bypass it.

Workaround aside. I agree, this feels buggy to me. Why would one need to restate the default temp just to use temp?

mike

Hi twopif ,

Ah, yes, I misread your statement about commenting out the .option temp line and the .param temp line:

twopif said:

If you remove the two lines “.option temp=..” and “.param temp=..” in file issue02_diode_temp.asc, you should see the error. But if the line “.option temp=..” is put back, the error does not occur anymore.

I did this, and possibly Mathias did the same, since the focus appeared be on the action of commenting then uncommenting the .options line:

So, if I comment out all of the lines, including .temp, I do get the error:

As for the workaround:

twopif said:

So isn’t it weird that you get a different result just by “repeating” the default temperature setting. In other words, there seems to be a difference between the (default) temperature set by the program and the user.

It's just something strange I noticed. If you think this normal behavior, don’t spend time here anymore. I already know how to bypass it.

Workaround aside. I agree, this feels buggy to me. Why would one need to restate the default temp just to use temp?

mike

Hi Mike,

For your curiosity: I used this construction “temp={temp}” as default parameter value for library components (subckts) to let the user know that the temperature of some of these devices can be set.