Micromagnetism

This page contains some general micromagnetics research. You will also find some of the visualisations produced during some of the micromagnetic simulation runs. Please be patient as some of these images may take some time to load.

Here's a quick page index:

Uniaxial anisotropy
Tools
Sphere visualisations
Bubble domain visualisations
Antisphere visualisations
Compiling OOMMF for AMD Opteron and Athlon 64 processors

Uniaxial anisotropy

Hosted at NIST, the Computational Engineering and Design Group's uniaxial anisotropy add-in for OOMMF provides a generic Oxs extension object, derived from the Oxs_Energy class which provides uniaxial anisotropy with second (K1) and fourth (K2) order terms.

Tools

ngtoucd is now part of the magpar distribution and allows the conversion of Netgen neutral finite element mesh files to AVS unstructured mesh format (for use in magpar and other FE tools supporting this format).

ovf2vtk is hosted by Hans Fangohr here and allows the conversion of OOMMF vector file formats (including ovf, omf and ohf) to the VTK file format allowing these to be visualised by VTK-compliant software packages.

Sphere

The visualisation below is that of a sphere of radius 200nm at zero applied field. The colour scale represents the angle between the x and y components of the magnetisation; the streamlines represent tracers which have been dropped in to highlight the vortex state.

Bubble domains

Below is the second derivative of the demagnetisation field of a thin film (height 50nm) of iron-palladium. From left to right we see the x, y and z components of the demagnetisation field; the upper and lower images highlight the influence different colour maps have on the data. This image clearly shows the bubble domains which form when relaxed from a random initial magnetisation.

Antispheres

This image depicts nine spherical holes carved out of a block sample in a similar vein to Boolean objects with CSG in 3D modelling. The permalloy sample is of the size order 600nm x 600nm x 150nm in zero applied field. The colour is representative of the angle between the x and y components of the magnetisation.

This image shows a slice through the finite element version of the antispheres.

Half-sphere

This image depicts a 200nm diameter nickel half-sphere in zero field. Note the out-of-plane vortex which is perfectly central. Again, the streamlines serve to highlight the vortex core, as well as the monochrome cones. The coloured cone plane shows the x-y angle of magnetisation.

Sphere vortex core A

This image uses an isosurface to outline the in-plane vortex in a 200nm diameter nickel sphere in zero field.

Sphere vortex core B

This is the same sample as above, however it is in a further reduced magnetic field. Note that the core of the vortex has reversed direction whilst the surrounding magnetisation has remained in the same direction.

Droplet

This visualisation shows the vortex which forms in a nickel half-sphere with an ellipsoidal cap of size 200nm at zero field. Monochrome streamlines follow the vorticity whilst the coloured streamlines use the magnetisation of the sample as a guide.

Half-sphere series

This image demonstrates the path which a vortex takes as the applied field is swept across the circular plane. Its nucleation point is the third image from the left at the top, its dissipation the second from the left along the bottom. The tracers follow the magnetisation starting from the right-hand side; the colour scheme is representative of the overall curl of the sample.

Compiling OOMMF for AMD Opteron and Athlon 64 processors

Making the object-oriented micromagnetic framework compile and run on AMD Opteron, Athlon 64 and FX processors requires a little hacking. After getting the source code from http://math.nist.gov and extracting it:

apply the patches from math.nist.gov/oommf/software/patchsets/oommf12a3/patchinfo.html, paying particular attention to patch 3 (evoc.cc - CLK_TCK undeclared) and patch 14 (Unknown feature "TCL_PREFIX" in configuration)

add the following code to oommf/config/names/lintel.tcl to accept this configuration for K8:

 
# before if {![string match i?86 $tcl_platform(machine)]} { ... 
#----------------------- 
if {[string match x86_64 $tcl_platform(machine)]} { 
   return 1 
} 
#-----------------------

this will cause pimake to fall back to the lintel architecture, which is the closest.

make use of the 64-bit features, by editing oommf/config/cache/lintel.tcl and setting the optimisations thus:
```
 
$config SetValue program_compiler_c++_option_opt {format "-O3 \ 
-march=k8 -m64 -msse2 -mfpmath=sse \ 
-ffast-math -fomit-frame-pointer"} 
```
Note that -O3 might be a little aggressive on some systems, so trim it back to -O2 if you run into any issues here. To summarise, I've made use of these flags without ill effect on my personal system. That's not to say they won't break on another. Here's what the flags do:
- -O3 enables all optimisations from the more usual -O2 and adds a couple more. The main thing I'm interested in here is the implied -finline-functions option (i.e. you get it bundled in with -O3) as on balance this should allow the effectiveness of the processor cache to improve.
- -march=k8 may be aliased/replaced by -march=opteron or -march=athlon64 on your compiler (though I've not thoroughly researched this, sorry). This option enables extensions for the K8 family (MMX, 3dNOW!, SSE etc).
- -m64 indicates to the compiler that we have a 64-bit environment, so make longs and pointers long.
- I believe the -msse2 and -mfpmath=sse options are enabled when using an x86-64 compiler, but it won't hurt to tack them in. This should improve stability over 387 code and considerable performance increases. OOMMF doesn't depend on the 80-bit internals of 387, so this won't break anything here.
- The various texts in the gcc man pages regarding -ffast-math are interesting but come with caveats. I tested the code with and without this option to ensure that a it didn't break and b it gave expected outputs.
- -fomit-frame-pointer may well be redundant (I believe the O flag turns this on) and I won't be debugging this build.
The jury is out on other optimisation options. They may or may not break OOMMF, but they may make it run more quickly. Perhaps the improvement is marginal. Maybe it's great. Let me know if you discover something.
now it's time for the mother of all horrible hacks. There is certainly an elegant solution to this but I have had neither the time nor the inclination to find it. Edit the file oommf/pkg/oc/config.tcl and hack in the following lines after the line method GetValue {feature} {
```
 
# --- horrible hack for Opteron (temporary) 
set values(TCL_VERSION) 8.4 
set values(TCL_MAJOR_VERSION) 8 
set values(TCL_MINOR_VERSION) 4 
set values(TCL_LIB_SPEC) "-L/usr/lib -ltcl8.4" 
# --- end horrible hack 
```
Note that this is only valid for Tcl/Tk 8.4 (!) and other versions should set appropriate numbers and library locations.

attempting to build at this point will give:

 
pimake 1.2.0.3 CSourceFile panic: 
Error finding includes in oommf/app/mmdisp/mmdispcmds.cc: 
Error finding includes in oommf/pkg/oc/oc.h: 
Error finding includes in oommf/pkg/oc/autobuf.cc: 
Error finding includes in oommf/pkg/oc/imports.h: 
can't read "env(OOMMF_TCL_INCLUDE_DIR)": no such variable

To solve this one, find tcl.h and tk.h (usually in /usr/include) and set the variable accordingly (the 'env' here is a dead giveaway ;^). For example, with bash:

 
export OOMMF_TCL_INCLUDE_DIR=/usr/include 
export OOMMF_TK_INCLUDE_DIR=/usr/include

now the error will change to:
```
 
No Tk configuration file found (tkConfig.sh) 
```
with an indication to set the OOMMF_TK_CONFIG environment variable. Here, use the locate command to find the appropriate tkConfig.sh, and set the environment variable accordingly. Repeat for tclConfig.sh:

 
export OOMMF_TK_CONFIG=/usr/lib64/tkConfig.sh  
export OOMMF_TCL_CONFIG=/usr/lib64/tclConfig.sh

that's it. A tclsh oommf.tcl pimake should now build successfully.

Compiling OOMMF on Intel Core 2 Duo processors

Thanks to Dr. Nils Wiese (n.wiese@physics.gla.ac.uk) of the Department of Physics and Astronomy at the University of Glasgow for the following updates to the above. This will allow you to tune OOMMF for Core 2 Duo platforms.

For GCC 4.1 (lintel.tcl)

 
$config SetValue program_compiler_c++_option_opt {format "-O3 \ 
-march=nocona -mtune=generic -m64 -msse2 -mfpmath=sse \ 
-ffast-math -fomit-frame-pointer"}

For GCC 4.3 (lintel.tcl)

 
$config SetValue program_compiler_c++_option_opt {format "-O3 \ 
-march=core2 -m64 -msse2 -mfpmath=sse \ 
-ffast-math -fomit-frame-pointer"}