Internal field terms show no units in 3.9 and 3.10

[JakubChecinski]

Our supercomputer cluster has recently updated NVIDIA drivers to release 418, which has broken some of my simulations on MuMax versions 3.9 and 3.10. When including the effective field term in the table.txt, I see the following headers in the table now:

B_effx (?) B_effy (?) B_effz (?)

With field units apparently being unrecognized. The numerical values displayed are also wrong, although the relationship between x,y and z components is correct. It seems that the whole vector is multiplied by some obscure factor, which varies slightly between different simulations. Similarly, if I save B_eff to an .ovf file instead of writing it to table.txt, I get the following lines in the ovf header:

# valuelabels: B_eff_x B_eff_y B_eff_z # valueunits: ? ? ?

Interestingly though, the numerical values are printed correctly this time and match the real values that should be seen in Teslas.

The problem occurs for internal field terms (B_exch, B_anis, B_demag, B_eff), but does not occur for the external field B_ext, which is still showed in Teslas and with correct numerical value. Other parts of the simulation also appear to be unaffected.

I have obtained this bug both in the version 3.10.beta and in 3.9.3. However, the legacy version 3.8 produces correct results from the same configuration files, with internal field terms listed in Teslas as expected.

[JeroenMulkers]

Thank you for reporting the bug related to the units. I fixed it in f1aadab.

Could you provide a minimal inputscript which clearly indicates that the numerical values of the effective field printed in the table are wrong?

[JakubChecinski]

Thank you for responding so quickly. I believe any simulation with B_eff term included will work, but the example code below is enough for me to see the difference in behavior between 3.8 and 3.10:

SizeX := 64e-9 SizeY := 64e-9 SizeZ := 4e-9 Nx := 16 Ny := 16 Nz := 1

// GEOMETRY CellX := SizeX/Nx CellY := SizeY/Ny CellZ := SizeZ/Nz SetCellsize(CellX, CellY, CellZ) SetGridsize(Nx, Ny, Nz) setgeom(circle(50e-9))

// PARAMETERS Bapp := 0.15 Angle := 90*pi / 180 IPAngle := 0*pi / 180 B_ext = vector((Bapp cos(Angle))cos(IPAngle), (Bapp cos(Angle))sin(IPAngle), Bapp * sin(Angle)) alpha_v := 0.01 Msat = 795775 Aex = 13e-12 GammaLL = 176.1e9 m = uniform(0.,0.,1.) SetSolver(5)

// OUTPUTS tableAdd(B_eff) tableautosave(1.0e-11) run(1.0e-9)

Simulation in 3.8 displays the initial effective field as about [0, 0, -280 mT], which looks realistic based on a quick analytical calculation. Simulation in 3.10 displays the same quantity as about [0, 0, -0.67] in (?) units.

[JeroenMulkers]

I do not get the erroneous values. I get [0,0,-284.46]mT with mumax3.8 and mumax3.10.

Could you double check your results and attach the table.txt file obtained with mumax3.10 if you still get the wrong result.

[jpsinnecker]

Hi, to contribute to the discussion.

I just used JakubChecinski code in mumax3.10 and got the following results:

1 # t (s) mx () my () mz () B_effx (?) B_effy (?) B_effz (?) 2 0 0 0 1 9.184851e-18 0 -0.28446794

Path applied to outputquantities.go.

My mumax is running in the following configuration:

lsb_release -a: Distributor ID: Ubuntu Description: Ubuntu 18.04.3 LTS Release: 18.04 Codename: bionic

uname -srm Linux 5.0.0-31-generic x86_64

mumax 3.10 linux_amd64 go1.10.4 (gc) CUDA 10010 GeForce RTX 2080 Ti(11019MB) cc7.5 (10210 MB free)

NVIDIA Driver Version: 430.26

[JeroenMulkers]

@jpsinnecker , these results are OK.

[jpsinnecker]

@JeroenMulkers, thanks. The values are OK. However, the units (line 1) are showing as "B_effx (?) B_effy (?) B_effz (?)", so no units. Is this expected?

[JakubChecinski]

Please find my both .txt files attached below.

mumax3.8.txt mumax3.10.txt

[JeroenMulkers]

@jpsinnecker , the 'missing unit bug' is already fixed (see discussion above).

@JakubChecinski , I was able to reproduce your results using the mumax3.10.beta binary. So for the z component of B_eff I get the following values for different versions:

• -284mT with mumax3.8
• -669mT with mumax3.10.beta
• -284mT with mumax3.10(master, since 87d696ce)

This means that the 'bug' was already resolved in commit 87d696ce some time ago. The origin of this 'bug' is due to the fact that the definition for the average of a magnetic field is a bit arbitrary.

Commit 87d696ce will ensure backwards compatibility between mumax3.8 and the final release of mumax3.10, so this issue can be closed.