From FLUX

The Field Line Universal relaXer (FLUX) is a fluxon model that follows magnetic field evolution in a conductive atmosphere, with exactly prescribed field topology. It can be used for plasma problems that are quasi-static and involve low β. FLUX can be used to study time-dependent 3-D field evolution with a desktop workstation or laptop computer.

FLUX is free software, available under the GPLv2 license. It depends only on other free software, notably GCC, Perl and PDL. Rendering uses openGL.

This wiki is the official FLUX support area; it is the best place to get the latest release or user information.

Contents 1 What is FLUX? 1.1 How it works 1.2 How it performs 2 Where to get the code 2.1 System requirements 2.1.1 Software environment 2.1.2 Architecture 2.2 Release Notes for the current release 2.3 Release Roadmap 3 Theory 3.1 Why bother? 4 Publications 4.1 Papers 4.2 Presentations 4.2.1 2008 4.2.2 2007 4.2.3 2006 4.3 Useful movies & plots 5 Current projects 6 User's Manual 7 Beefs/bugs 8 Author(s) 9 Acknowledgements

What is FLUX?

FLUX is a prototype physics simulation code that is in development to become a full MHD solver. It is currently a time-dependent nonlinear force free field solver: given an input magnetic field topology, it can track evolution of the force-free magnetic field under changes in a boundary condition. FLUX v2.1 (the current version) is thus useful for studying slowly evolving plasma systems in the limit where beta is low and the timescales of interest are longer than the Alfvén dissipation time of the system.

FLUX is single-threaded: it is intended for use on a desktop workstation. Typical idealized plasma systems require only a few MB to represent, and small-but-nontrivial simulations can be constructed that fit entirely with the L2 cache of a modern 64-bit workstation.

FLUX uses the "fluxon" approach to MHD, modeling the field as a collection of curvilinear 1-D manifolds that approximate field lines. Fluxons differ from field lines primarily in that each fluxon carries a finite amount of magnetic flux, while a field line carries only an infinitesimal amount of flux. FLUX stores each fluxon as an ordered list of vertices, each of which contains spatial coordinates and ancillary information of use to the simulation engine.

Unlike more conventional codes, FLUX preserves magnetic topology exactly: unless specifically triggered by the modeling code, no reconnection at all occurs in the modeled magnetic flux system. FLUX is a coordinate-free code: each vertex is free to wander throughout all space, unless you define specific boundary conditions that limit the size of the simulation.

How it works

FLUX is a force-balance relaxation engine. At each relaxation step, the code calculates several vector forces acting at each vertex, and then moves the vertex in the direction of the forces. After a sufficient number of small steps, the system reaches equilibrium (if one exists). Currently, three forces are used: the magnetic tension ("curvature") and magnetic pressure ("field gradient") components of the Lorenz force, and a pseudoforce that keeps the vertices placed optimally along the length of each fluxon. The magnetic pressure and curvature forces are calculated using an analytic geometry technique called "Voronoi analysis": the code derives the locus that is closer to a particular fluxon segment ("flux element" or "fluxel") than to any other, and calculates the magnetic field by considering that all the flux associated with the fluxel is compressed into that locus. The cross-sectional area of the locus gives an estimate of the local magnetic field strength, and the asymmetry of the locus gives an estimate of the magnetic field gradient. The fluxons, in a sense, discretize the topology of the field: topological changes require reconnection of a pair of fluxons, either by exchange or by passing through one another. For time-dependent modeling, each time step consists of an update to the boundary condition, followed by a relaxation of the simulation field to match the new boundaries. Thus we distinguish between "relaxation steps" which take no physical time, and "time steps". A typical time step might require a thousand relaxation steps.

How it performs

Because FLUX grid size need only be large enough to resolve the structures being studied, grids are much smaller than in conventional 3-D magnetic field codes. Typical ideal ("toy") problems use only a few thousand fluxels in less than 100 fluxons. Problems of this size require minutes to relax. Larger problems like semi-empirical studies of solar active regions might require 10⁴ fluxons, and require hours to relax. Most solar magnetic field configurations are scale invariant: the total amount of curvature of each closed field line is roughly constant against total length of the field line. This yields a major scaling advantage for FLUX, which seems to scale more like a conventional 2-D code than 3-D code: the number of vertices in the simulation appears to be proportional to the complexity of the boundary for a large range of systems.

In a direct comparison with a conventional MHD model (ARMS) in early 2008, FLUX obtained similar answers in its appropriate computational domain, but used under 1% of the computing power needed by the conventional code.

Where to get the code

If you want bleeding-edge updates, contact Craig DeForest (e-mail address at the bottom) for an account on the main CVS server.

The current release is v2.1 (3-Apr-2008); you can download it from here (446 kb).

System requirements

Software environment

FLUX needs:

• a POSIX system under which to run. It has been tested under Fedora Linux, Ubuntu Linux, and MacOS X. It is thought to work under Cygwin (but why bother?)

• Perl 5.8.x (standard on most POSIX systems these days)

• PDL 2.4.x (standard on most Linuxes and available through Fink; source is available from http://pdl.perl.org

• gcc & make (standard essentially everywhere). (Other C compilers may work; nobody has yet tried.)

• NetPBM (standard on most Linuxes and Macs; required for rendering; used by the PDL::IO::Pic module).

• OpenGL (required for 3-D rendering; used by the PDL::Graphics::TriD module)

Architecture

FLUX is thought to work on all major architectures. It has been compiled on and for 32- and 64-bit Intel chips, 64-bit AMD Athlon architecture, and G4/G5 architectures. FLUX is currently single-threaded.

Release Notes for the current release

v2.1 includes several minor bug fixes, improvements to the rendering code, and Perl convenience functions for the geometry library.

v2.0 was the first revision for which all the basic field manipulation and Perl interface infrastructure seems to be 100% present. Notable improvements from v1.2 are:

• The "under-the-hood" Perl interface is much more robust and no longer leaks memory or dumps core on Perl quit.
• All tied-hash fields are implemented (so, e.g., you can explore the FLUX tree structures from within your Perl script).
• Magnetic reconnection is fully tested and robust.
• Grid de-refinement is fully tested and robust.
• Open boundaries are fully supported.
• U-loop and omega-loop traversals of the open boundary are supported.
• Plasmoids are fully supported, including reconnection that involves plasmoids.
• Flux emergence and submergence are fully supported.
• New force laws provide better convergence and higher accuracy
• Some improvements to the rendering code
• Addition of footpoint-motion tools to the main tree (the "duction" infrastructure)

Release Roadmap

The current FLUX release is (nominally) updated twice a year, in the fall and the spring.

Currently planned releases of FLUX are:

2.2

(October 2008) - static plasma forces, interface to TecPlot or OpenDX for more sophisticated rendering

2.3

(May 2009) - bug fixes and updates

3.0

(October 2009) - multithreading

Theory

The analogy between field lines and vector field values is pretty well known. It's generally used for visualization of the magnetic field. One develops a vector field, either analytically or numerically, and shoots a collection of field lines through the calculated field. Since it's hard to render a 3-D vector field directly, one then renders the field lines instead.

Fluxon codes use the field line analogy in reverse, treating the field as a collection of discretized field lines. They are discretized in two senses: (A) each line (a "fluxon") carries a finite, rather than infinitesimal, amount of magnetic flux; and (B) the field lines are piecewise linear, composed of vertices and line segments, rather than smooth curves. Approximations to the magnetic pressure and curvature forces can be calculated from the local geometry around each vertex and/or line segment.

FLUX uses 2-D analytic geometry to construct the Voronoi cell around each line segment - the locus (in the plane perpendicular to the fluxon line segment) that is closer to the current line segment than to any other. The Voronoi cell is calculated by a simple hull algorithm acting in the plane perpendicular to each fluxel in turn. The local field strength (hence magnetic pressure) and gradient may be inferred directly from the geometry of this Voronoi cell. The direction is determined from the direction of the line segment itself.

FLUX is a coordinate-free code: while the internal representation of space is Cartesian, the physical simulation interacts with that representation only through vector operations such as inner and cross product. Hence there are no inherent boundaries to the location, and no preferred directions: the code works equally well in spherical geometries as planar ones. In that respect, fluxon codes in general are like smooth-particle hydrodynamic codes: they represent a continuous variable (the vector magnetic field for FLUX, or the fluid density field for a smooth-particle code) as a collection of discrete objects (fluxons vs. particles) in an unbounded space.

For more detail, read DeForest & Kankelborg 2007.

Why bother?

Fluxons have the advantage that they discretize the topology of the magnetic field. Because the differential topology of a true field line map is represented using the discrete topology of individual field lines, it is not possible for fluxons to reconnect "accidentally", and numerical reconnection is avoided. Other advantages include possible scaling and stability benefits compared to conventional codes. FLUX is believed to be the only code capable of running useful 3-D (quasi-)time-dependent MHD simulations on a desktop workstation.

FLUX is currently the only MHD simulation code that can maintain and evolve small open-field regions embedded in the closed "quiet" solar corona. These regions are the leading candidate source region for the slow solar wind that permeates the Solar System near the plane of the ecliptic. It is also the only MHD code that can evolve and maintain indefinitely the large metastable systems of magnetic flux that are thought to cause coronal mass ejections.

Publications

Papers

• DeForest & Kankelborg, JASTP 2007: Description paper of the Voronoi method for estimating magnetic field forces.

Presentations

There have been several. Mediawiki doesn't like to deal with huge files, so it doesn't make good sense to upload whole presentations here into the wiki -- but I'd like to put them on the web somewhere. For now, here's a catalog starting in late 2006:

2008

• Rachmeler, DeForest, Pariat, & Antiochos, poster at AAS/SPD (Ft. Lauderdale): overview of progress, demo of the recent comparison between FLUX and ARMS. Winner: best student poster.

2007

• DeForest & Rachmeler, talk at AAS/SPD (Honolulu): overview of progress, and demo of reconnection
• Rachmeler & DeForest: poster at AAS/SPD (Honolulu): herniation result. Runner-up for best student poster.
• Bruder: Final report, 2007 MSU REU program (Bozeman): archived at MSU. Overview of debugging/validation efforts.
• DeForest & Rachmeler: two (!) invited talks at SHINE (Whistler, BC): overview of fluxon modeling and results; presentation of the herniation result.

2006

• Rachmeler & DeForest: poster at AGU (San Francisco), describing the herniation result. Won an award for best student poster.

Useful movies & plots

Here's a link to a page of useful movies and plots for presentations...

Current projects

A page of current projects shows some of the investigations that use FLUX.

User's Manual

A user's/programmer's manual is in progress.

It is largely a programmer's reference at the moment (October 2007), containing descriptions of the routines and calling conventions in the libraries and code, and some of the design ideas that went into them. It is being expanded to include more examples on how to use the code.

Beefs/bugs

Track Beefs and bugs here.

Author(s)

Fluxons are a joint invention of Craig DeForest and Charles Kankelborg. The code contains contributions from many individuals, including:

• Craig DeForest
• Charles Kankelborg
• Laurel Rachmeler
• Alisdair Davey
• Daniel Bruder
• Teddy Walls

FLUX is maintained by Craig DeForest (e-mail: deforest (at) boulder (dot) swri (dot) edu).

Acknowledgements

Initial development was under internal funding by the Southwest Research Institute.

Current development is funded by NASA, under the Living With a Star and Solar and Heliospheric Physics programs.