Hi all,

I’m implementing an inverse Jiles-Atherton model in LTspice, mainly based on this paper:

The simulation stops around a quarter cycle. It seems to get stuck when "dH/dt" approaches zero — likely because of? "delta", which is the sign of "dH/dt"

I’ve tried replacing the "delta" with a smooth "tanh" function, but the oscillation and convergence issue still remains.

Any suggestions on how to solve this problem?? I've posted my schematic here: /g/LTspice/files/Temp/invJAmodel_dynamictest.zip

Thanks!

Thanks for your efforts! I’ve seen the JA model you shared earlier—it’s excellent!

However, the circuit I’m working on is the "inverse JA model", where B is the input and H is the output, unlike the usual forward case. I previously implemented the forward model (usual JA model) myself and it worked well without major convergence issues. But this time, the inverse version performs poorly in LTspice, and I’m not sure why. Have you encountered similar convergence problems before?

Additionally, I also tested the inverse model in MATLAB in advance, and it behaved correctly there. But, since MATLAB updates variables sequentially accroding to my codes, while LTspice seems uses matrix-based solving, I wonder if it might be affecting the results. Do you have any suggestions?

Thank you very much for your suggestion — you solved a problem that had troubled me for weeks. The convergence is indeed much better now. However, there are still some aspects of the model that puzzle me.

When my input B is a 50?Hz sine wave, the simulation only converges when the delay "tau" is set to 300?ns. If I reduce tau to 200?ns or smaller, the simulation still gets stuck at some point. Moreover, when I try to increase the frequency of B, tau = 300?ns no longer works. This behavior seems to make the model not very robust across different conditions.

Do you have any insights into what might be causing this?

(The new one is here: /g/LTspice/files/Temp/invJAmodel_2.asc)

Again, thank you so much for taking the time to help!

Thanks for the suggestion — increasing rtol? is truly helpful.

This model seems to struggle when dH/dt is near zero, causing oscillations in all conditional terms. Sometimes it converges, sometimes it doesn't.

Three ways to improve it:

1. Increase delay time (tau): Helps stability, but too large tau introduces more phase shift between B and H,which increases B-H loop area. At an input frequency of f = 50 Hz, using tau?= 300 ns still gives acceptable results, but if the frequency increases, tau must be reduced accordingly.

2. Reduce max timestep: Slower simulation, but improves convergence near dH/dt ≈ 0. Dropping it from 1e-6 to 1e-7 helped. It seems that better numerical resolution earlier in the simulation helps the solver predict the behavior more accurately at those critical points.

3. Increase rtol: Improves convergence but may distort waveforms. But combining this with a smaller timestep can balance accuracy. rtol = 0.005 worked better than the default rtol=0.001.

At this point, I haven’t found a way to eliminate the oscillations, but I can improve both convergence and accuracy by balancing the three strategies above. I’ll continue experimenting to see whether it's possible to reduce the oscillation by improving the inverse Jiles-Atherton algorithm itself.

开云体育

I had to replace the parameter k with k0, because in Qspice k is the Boltzmann constant. At tau=10ns, the counting time was 2.2 seconds. And everything was fine.

k is also defined as Boltzmann's constant in LTspice.

开云体育

On 23/04/2025 09:55, Александр Бордодынов via groups.io wrote:

I had to replace the parameter k with k0, because in Qspice k is the Boltzmann constant. At tau=10ns, the counting time was 2.2 seconds. And everything was fine.

k is also defined as Boltzmann's constant in LTspice.

I should clarify that:

k is pre-defined in LTspice, but only in the waveform viewer, not as a design parameter. Of the defined "constants" (e, pi, k and q) mentioned in the Help, only pi can be used as a design constant.

--
Regards,
Tony

开云体育

Maybe even a bit more explanation is necessary. To use the others in a simulation, it is necessary to include a directive, such as '.param k = 1.3806503e-23'. I hope that's right.

On 23/04/2025 11:00, Tony Casey via groups.io wrote:

On 23/04/2025 09:55, Александр Бордодынов via groups.io wrote:

I had to replace the parameter k with k0, because in Qspice k is the Boltzmann constant. At tau=10ns, the counting time was 2.2 seconds. And everything was fine.

k is also defined as Boltzmann's constant in LTspice.

I should clarify that:

k is pre-defined in LTspice, but only in the waveform viewer, not as a design parameter. Of the defined "constants" (e, pi, k and q) mentioned in the Help, only pi can be used as a design constant.

--
Regards,
Tony

开云体育

That's correct.

I'm still left wondering why only pi is defined for analysis. Of course, for "e", it's shorter to define it:

.param e exp(1)

"pi", "e", "k", ... are short identifiers. The user may want to use these names for node
names/labels or in expressions (K for gain or coupling factor, Pi for input power, e for
error...). This can be hard to find, especially in deeply nested subcircuits or when forgetting
that there is no case-sensitivity, or when brackets are optional.

-marcel

开云体育

"pi", "e", "k", ...  are short identifiers. The user may want to use these names for node 
names/labels or in expressions (K for gain or coupling factor, Pi for input power, e for
error...). This can be hard to find, especially in deeply nested subcircuits or when forgetting
that there is no case-sensitivity, or when brackets are optional.

You can use anything you like for net names containing any printable Latin character, except these: (? )? {? } ? '? *? = ,? :? ;? and space. My curiosity showed that even many non-Latin characters and "graphics" like ? and ? are accepted, although these are often not printed properly in the waveform window, which is more limited. You never knew your schematics could be so interesting!

If you try to redefine pi (perhaps being unaware it is already defined), it will succeed. Personally, I think that should generate at least a warning. OTOH, "temp" is also predefined and can be overridden legitimately.