3 mumax3.11

A housekeeping update is currently being prepared for mumax³.

[!IMPORTANT] In mumax 3.11, GPUs with compute capability <5.0 will no longer be able to run the mumax³ pre-compiled binaries that are provided on the mumax³ download page. Those binaries will only be compiled with CUDA 10.0 and higher. Check your GPU's compute capability with nvidia-smi --query-gpu="compute_cap" --format="csv".

Changelog

New functionality in input scripts

FunctionFromDatafile(): creates a function from data in a CSV file. #343 by @JeroenMulkers.
GrainsCutShape (default false): after this parameter is set to true, calling ext_make3Dgrains() on a certain shape will complete all voronoi grains whose centre lies within the shape, while grains whose centre lies outside the shape will be cut out. #335 by @JLeliaert.
EdgeCarryShift (default false): after this parameter is set to true, when calling Shift(x), the values of m in the introduced cells are copied from the cells at the border. For cells where this border was outside the geometry, ShiftMagL/R/D/U is used. #316 by @jsampaio.
RedefRegion(old_idx, new_idx): all cells with region index old_idx will be moved to region new_idx. #280 by @RossKnapman.
ext_InitGeomFromOVF(filename): can be used to load a geometry stored in an OVF file (e.g. as saved by save(geom)). Besides loading the geometry as a VoxelShape (which is not accessible by the user), this function also resizes the grid and cells to the same size as in the .ovf file. Part of #311 by @Artemkth.
RemoveCustomEnergies(): clear all user-defined energies. #301 by @FGarcias.

Other changes

Updated README with instructions and troubleshooting for building mumax³ on Windows, and updated deploy_windows.ps1 to be more versatile. Related: #332.
Removed unnecessary torque evaluation in RKF56 solver. Fixed in #341.
Last commit hash when mumax3.exe was compiled is now printed when mumax³ starts. [e07e134bd00192201d4bf642ba5658d3c380e2eb]
20 new GPU benchmarks on homepage.

Bugfixes

OVF files could not contain comments when loaded with mumax³. Fixed in #311 by @Artemkth.
Shifted(x, y, z) could not be used to shift quantities over more than one direction at once. Fixed in #283.
Incorrect equation for magnetoelastic effective field. Fixed in #324 by @marcrovi.
ext_make3Dgrains did not use seeded random generator. Fixed in dcf1e2fda20c33d74e517626ff0ef8c41cbdcefc.
MFM images could not be calculated for some grid sizes. Fixed in #334.
Cone was not a cone. Fixed in ef13cb6c1a0dad9d4f027b6c8d44ce5cb650936a, reported by @gnmp in #287.
🎅 [9c348f6e1a0735f68fd5170f37d43e59c5219d25]
Updated LICENSE with additional permission under GNU GPL version 3 section 7 concerning NVIDIA CUDA Toolkit. Fixed in #296 by @rolandmas.

To do

[ ] Merge feature/functionfromfile, feature/dmitensor (and possibly feature/spatial_quantity) branches.
[ ] Finish issues and PRs in 3.11 milestone.

Oct 14 '24 14:10 JonathanMaes

Hi,

Thanks for this.

Are you taking suggestions? There's a few features (in places like closed pull requests) and the like that would be very useful to have, and hopefully are easy/complete enough to get across the finish line without too much work. But I don't want to dump a ton of extra work onto you :)

Oct 14 '24 18:10 jplauzie

If there are certain PRs etc. you would like to see included, let us know, then we can consider if they should be added to 3.11.

Oct 16 '24 09:10 JonathanMaes

Two nice features would be:

Allowing the user to pass a file for arbitrary time modulation would be useful, as in https://github.com/mumax/3/pull/271#issue-721758649 . It seems Jeroen might have already finished this, and it may just need to be merged and exposed to the user/API?
Similarly, currently there is no way for the user to make an arbitrary spatially varying custom quantity. One can only make quantities from existing quantities, and Const() or Constvector(). It seems like this pull request might be close to allowing that: https://github.com/mumax/3/pull/289#issue-852282613 . However, there might be an easier way, by simply giving the user the ability to promote an arbitrary slice to a Quantity, similar to how @xfong has implemented it in the umagnus fork here: (related test file here) . This would be useful, for instance if one wants to a custom field implementation of a uniaxial anisotropy, but it varies spatially across the sample.

There are a couple other features that would be nice, but are probably beyond the scope of this update:

Currently the custom fields feature does not seem to consider boundary conditions. I'm not sure if there's an easy way to expose this to the user, but it might be nice. You can somewhat do this currently with Masked() I suppose, but only with a pre-existing mumax Shapes. Although, if fully custom spatially-varying quantities mentioned above are allowed, that should solve this at the same time.
In the announcement for the minimize() function, it mentions that it doesn't do a line search once it starts BB. I was never able to find any reasoning for this, so I was wondering if anyone ever looked to see if this might be important? This seems like it might help in cases where minimizer gets stuck, but my intuition for this is not strong, perhaps it is only a marginal benefit. Minimize works so well it seems like it never really came up.
Last, requests for anisotropic DMI have been fairly common. I'm not sure if it is as simple as splitting d into (+/-?)d_x, d_y,d_z, but if so (and there isn't too much impact on e.g. memory usage) that would be nice to have. Although again, this can probably be done via custom fields.

Those are all I can think of off the top of my head. I'll try to see if I can think of anymore.

Oct 18 '24 02:10 jplauzie

Hello, Thank you for the good job.

May I suggest an additionnal PR concerning the magneto-elastic coupling : would it be possible to include the lattice rotation tensor omega similarly to the epsilon tensor as described in M. Xu, K. Yamamoto, J. Puebla, K. Baumgaertl, B. Rana, K. Miura, H. Takahashi, D. Grundler, S. Maekawa, and Y. Otani, Science Advances 6, eabb1724 (2020), https://www.science.org/doi/pdf/10.1126/sciadv.abb1724.

One possible expression for the effective field could be : (see P. Rovillain et al Phys. Rev. Applied 18, 064043 DOI: https://doi.org/10.1103/PhysRevApplied.18.064043 )

This would be very useful for my investigations.

Jan 09 '25 15:01 DanSto67

Thank you both for your suggestions. Ultimately, only the 1st suggestion by @jplauzie was implemented in 3.11. We will consider the remaining suggestions for a future update.

Jun 06 '25 13:06 JonathanMaes