mumax3.11

[JonathanMaes]

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

Functions

• FunctionFromDatafile(file, xcol, ycol, interp): creates a function from columns in a CSV file. Add FunctionFromDatafile() function to be used in input scripts #343 by @JeroenMulkers.
• RedefRegion(old_idx, new_idx): all cells with region index old_idx will be moved to region new_idx. Clear region if previously defined #280 by @RossKnapman.
• RemoveCustomEnergies(): clear all user-defined energies. Add simple function RemoveCustomEnergies #301 by @FGarcias.
• ext_centerWallInLayer(reg, comp) and ext_centerWallInRegion(reg, comp): follow a domain wall in only one layer/region (useful e.g. in SAF or odd-shaped geometries). Feature/center wall per layer region #222 by @jsampaio.
• ext_InitGeomFromOVF(file): 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 (not accessible by the user), this function also resizes the grid and cells to the same size as in the .ovf file. Part of New build system migration (issue #298 + 2 more improvements) #311 by @Artemkth.

Boolean parameters

• EdgeCarryShift (default false): if set to true, calling Shift(x) uses the values of m at the border to set the magnetization of the introduced cells. For cells where this border was outside the geometry, ShiftMagL/R/D/U is used. Feature/fudgeShift #316 by @jsampaio.
• ext_grainCutShape (default false): if 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. Feature/complete grains at shape edge #335 by @JLeliaert.

Other changes

• Updated README with instructions and troubleshooting for building mumax³ on Windows, and updated deploy_windows.ps1 to be more versatile. Related: Building the mumax3 from source code on windows #332.
• Warn the user when the grid is not 7-smooth, when it contains an odd number of cells at nonzero temperature, or when cells have a high aspect ratio. See Warn the user when choice of grid size can cause a CUDA error #340.
• Removed unnecessary torque evaluation in RKF56 solver. Fixed in In RK56: remove unnecessary torque evaluation #341.
• Print extra system information when mumax³ starts, including commit hash when mumax3.exe was compiled. Merged in e07e134 and Add CPU info on Windows #344.
• Updated GPU benchmarks on homepage (20 new, 12 removed).

Bugfixes

• OVF files could not contain comments when loaded with mumax³. Fixed in New build system migration (issue #298 + 2 more improvements) #311 by @Artemkth.
• Shifted(x, y, z) could not be used to shift quantities over more than one direction at once. Fixed in Fix shifted quantity for shifts in more than one direction #283.
• Incorrect equation for magnetoelastic effective field. Fixed in Update magnetoelasticfield.cu #324 by @marcrovi.
• ext_make3Dgrains did not use seeded random generator. Fixed in dcf1e2f.
• MFM images could not be calculated for some grid sizes. Fixed in Allow Nz=2,3,4,5 for MFM images #334.
• Cone was not a cone. Fixed in ef13cb6, reported by @gnmp in Wrong shape output from "cone" shape in API. #287.
• Demag kernel calculation did not always print 0% and 100% completion.
• Scrolling in mumax-view was broken in Firefox.
• 🎅 9c348f6
• Updated LICENSE with additional permission under GNU GPL version 3 section 7 concerning NVIDIA CUDA Toolkit. Fixed in Add GPL-3 exception for linking to NVidia's CUDA libraries #296 by @rolandmas.

To do

• Merge feature/dmitensor (and possibly feature/spatial_quantity) branches.
• Finish issues and PRs in 3.11 milestone.

[jplauzie]

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 :)

[JonathanMaes]

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.

[jplauzie]

Two nice features would be:

1. Allowing the user to pass a file for arbitrary time modulation would be useful, as in Feature/Time series signal from file support #271 (comment) . It seems Jeroen might have already finished this, and it may just need to be merged and exposed to the user/API?

2. 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: Feature/spatial_quantity #289 (comment) . 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:

3. 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.

4. 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.

5. 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.