Before describing each of the applications which comprise the OOMMF software, it is helpful to understand how these applications work together. OOMMF is not structured as a single program. Instead it is a collection of programs, each specializing in some task needed as part of a micromagnetic simulation system. An advantage of this modular architecture is that each program may be improved or even replaced without a need to redesign the entire system.
The OOMMF programs work together by providing services to one another. The programs communicate using localhost Internet (TCP/IP) connections. When two OOMMF applications are in the relationship that one is requesting a service from the other, it is convenient to introduce some clarifying terminology. Let us refer to the application that is providing a service as the ``server application'' and the application requesting the service as the ``client application.'' Note that a single application can be both a server application in one service relationship and a client application in another service relationship.
Each server application provides its service on a particular Internet port, and needs to inform potential client applications how to obtain its service. Each client application needs to be able to look up possible providers of the service it needs. The intermediary which brings server applications and client applications together is another application called the ``account service directory.'' Each account service directory keeps track of all the services provided by OOMMF server applications running under its user account on its host and the corresponding Internet ports at which those services may be obtained. OOMMF server applications register their services with the corresponding account service directory application. OOMMF client applications look up service providers running under a particular user ID in the corresponding account server directory application.
The account service directory applications simplify the problem of matching servers and clients, but they do not completely solve it. OOMMF applications still need a mechanism to find out how to obtain the service of the account service directory! Another application, called the ``host service directory'' serves this function. Its sole purpose is to tell OOMMF applications where to obtain the services of account service directories on that host. It provides this service on a ``well-known'' port that is configured into the OOMMF software. By default, this is port 15136. OOMMF software can be customized to use a different port number.
These service directory applications are vitally important to the operation of the total OOMMF micromagnetic simulation system. However, it would be easy to overlook them. They act entirely behind the scenes without a user interface window. Furthermore, they are usually not launched directly by the user. (The notable exception involves launchhost, which is used when multiple host servers are needed to isolate groups of OOMMF applications running on one machine.) When any server application needs to register its service, if it finds that these service directory applications are not running, it launches new copies of them. In this way the user can be sure that if any OOMMF server application is running, then so are the service directory applications needed to direct clients to its service. After all server applications terminate, and there are no longer any services registered with a service directory application, it terminates as well. Similarly, when all service directory applications terminate, the host service directory application exits. The command line utility pidinfo can be used to check the current status of the host and account service directory applications.
In the sections which follow, the OOMMF applications are described in terms of the services they provide and the services they require.