User function name D() not allowed anymore.

Dear twopif ,

We had very good reasons for these changes. You are not allowed to change the meaning of built-in functions anymore.

Functions like D(), Re() etc. are meant for .meas expressions.

They all work as they should.

As for behavioral sources, keep in mind that they describe the time domain behavior.

Best Regards,
Mathias

Hi Mathias,

That’s exactly my point. Now, you can use these special functions Re()/Im()/etc. at a B-source, while they are just producing nonsense. Before, with LTspice 24.0.12, it was not impossible to use them because they were not recognized ("syntax error: no such function"). For a B-source only a subset of functions is meaningful (as described in the LTspice Help). These special functions for complex data are only useful for .meas or waveform arithmetic. The syntax checker should prevent using them at a B-source or even better: do not make them globally available (to make it LTspice24.0.12 compatible).

For this example: ".param abc=im(3+4*sqrt(-1))" an error message "This function is not supported in this context." occurs. -> OK.
But if the same command is used at a B-source, V=im(3+4*sqrt(-1)), no error message appears and the simulation result is 0V (while it should be 4).
In my opinion the same error message should occur in both cases.

Hi twopif ,

twopif said:

Function D() is a waveform arithmetic function, so in my opinion it was not needed to do this renaming.

From my understanding, .func functions are generalized functions that can be used in B sources, .param, .meas and waveform arithmetic (if defined in the plot defs), so it makes sense to disallow this reserved function for .func.

twopif said:

For this example: ".param abc=im(3+4*sqrt(-1))" an error message "This function is not supported in this context." occurs. -> OK.
But if the same command is used at a B-source, V=im(3+4*sqrt(-1)), no error message appears and the simulation result is 0V (while it should be 4).

Yes, 0 is the correct result as all calculations are produced from using the real part of complex numbers, essentially im(re(3+...)). This is not a very useful result, but no error message is produced, because the tautological function is "supported," though not documented.

mike

Hi Mike/Mathias,

To summarize:

1. LTspice24.1 wants to prevent overwriting system functions from now on. In this way we have to accept some incompatibilities with previous versions of the program.
2. The functions for complex data are only useful for post processing (like .MEAS) and should not be used at a B-source, because they produce wrong results.

Possibly the new syntax checker can prevent misuse of these functions (like it is possible at the .param). Consider this as improvement to make it more dummy proof. I leave that to your own judgement.

By the way, with LTspice26.0.0 I can use for the first time all my libraries again (since 24.1.x). I also noticed that it simulates much faster. It really deserves this major step forward. Congratulations to the team!

Dear twopif ,

I'd like to remark that the complex functions do not produce wrong results. Keep in mind that B-sources describe behavior in the time domain, thus all calculations are done with real numbers. As a consequence, the expression sqrt(-1) is ill-formed.

The reason you can use all your libraries again with LTspice26 is that it ignores all the errors within components that are not used. So you are really just postponing the inevitable.

Best Regards,
Mathias

Dear twopif ,

I'd like to remark that the complex functions do not produce wrong results. Keep in mind that B-sources describe behavior in the time domain, thus all calculations are done with real numbers. As a consequence, the expression sqrt(-1) is ill-formed.

The reason you can use all your libraries again with LTspice26 is that it ignores all the errors within components that are not used. So you are really just postponing the inevitable.

Best Regards,
Mathias

Hi Mathias,

The complex functions themself are ok, but in combination with a B-source they produce the wrong results for .AC (as proven with the provided example).
During .AC all simulation data must be complex (also from a B-source). In this way it is possible that the mentioned functions also produce proper results when using them at the B-source. With this modification of the program, you could create .AC models, which are invalid for .TRAN. You normally want to avoid this. So, practically you should not use these complex functions at all in models. Preferably the syntax checker should prevent using them.

Thanks for the warning that LTspice26.0.0 is only syntax checking the used models from a library (back to LTspice24.0.12 behavior). I verified many of my (own written) models. All LTspice24.1.x versions had problems with these (quite large) models, but LTspice26.0.0 accepts them. So, I'm quite happy with this result. Thanks for solving the (reported) bugs.

Dear twopif ,

You misunderstand how these B-sources work. They always describe the behavior in the time domain, even during AC simulation. For the latter, LTspice lineraizes the given expression around the operating point.

The resulting transfer function is not complex valued, unless the original time domain expression contains delay(), ddt(), idt() or idtmod().

Functions like im() and re() do not produce wrong results in B-sources, because by definition they only operate on real values in the time domain. And since the set of real numbers is part of the set of complex numbers, there is nothing wrong about this. LTspice uses these complex functions in a consistent, mathematically correct way on real numbers.

You expressed dissatisfaction about the fact that sqrt(-1) results in 0. But this has always been the case. The only correct alternative would be to abort the simulation with an error message. That would be a drastic breaking change. Not being able to override built-in functions is too, but it only is a minor inconvenience for which we had multiple profound reasons.

Best Regards,
Mathias

Hi Mathias,

Thanks for your patience and the well explanation. I think I understand this now: the B-source is not simply doing conj(x) on the complex signal x, like the .MEAS is doing during post processing. The linearization step makes the models always valid for .AC and .TRAN.

Still, I don't see any useful application for these functions in combination with a B-source. For that reason, rejecting these functions there is still an option.
Or can you provide a good example for this combination?

Dear twopif ,

I agree, these complex functions are completely useless for B-sources.

But we like to keep things simple, and rejecting them would be more work. We'd rather focus our efforts on things that really matter.

Best Regards,
Mathias