Hermes has been developed over several decades. It began as
			a UCSD Pascal program running on a Terak
			 computer in a office in
			 Calwell Hall at Cornell University, overlooking the quad of the College of Agriculture.
			(It was the nicest office I  ever had, on the second floor, just above the door.)
			 The program has recincarnated several times since then,
			sequentially in a IBM PC, a Symbolics Lisp Machine,
			and a Macintosh, both with its original OS, and OS X, where it now happily resides.
			Calwell Hall at Cornell University, overlooking the quad of the College of Agriculture.
			(It was the nicest office I  ever had, on the second floor, just above the door.)
			 The program has recincarnated several times since then,
			sequentially in a IBM PC, a Symbolics Lisp Machine,
			and a Macintosh, both with its original OS, and OS X, where it now happily resides. 
			
 For historic reasons, the current incarnation is 
			divided into three parts.
			The eponymous application is the model editor. There is a small set of predefined classes, each of which
			performs a role in the simulation by applying a function to a set of inputs and
			producing a set of outputs. Connecting  outputs and inputs between components
			creates a network which can be executed as a simulation. One of the classes packages
			a set of components together, so that the model becomes a hierarchical tree, reducing
			the apparent complexity.
For historic reasons, the current incarnation is 
			divided into three parts.
			The eponymous application is the model editor. There is a small set of predefined classes, each of which
			performs a role in the simulation by applying a function to a set of inputs and
			producing a set of outputs. Connecting  outputs and inputs between components
			creates a network which can be executed as a simulation. One of the classes packages
			a set of components together, so that the model becomes a hierarchical tree, reducing
			the apparent complexity.
			
 Once the model is defined, it can be 
			executed using Crocus. The execution
			is governed by an XML file, and Crocus began as little more than a editor specialized to
			create these files in the proper format. The execution engine itself (called Mercury) is written as
			a faceless Objective-C program, which can be hosted on other platforms besides the Mac,
			taking its parameters from the same XML file produced by Crocus. Crocus also has some ability to create
			graphs from simulated data.
Once the model is defined, it can be 
			executed using Crocus. The execution
			is governed by an XML file, and Crocus began as little more than a editor specialized to
			create these files in the proper format. The execution engine itself (called Mercury) is written as
			a faceless Objective-C program, which can be hosted on other platforms besides the Mac,
			taking its parameters from the same XML file produced by Crocus. Crocus also has some ability to create
			graphs from simulated data.
 After a simulation is run, its results can be stored in a lightweight database called 
			Igor. Igor is also a simple word processor, so that simulations and their result 
			streams can be easily annotated. Igor can also send data to pro Fit, which will produce
			plots and return them to Igor, where they can be added to any annotation.
			After a simulation is run, its results can be stored in a lightweight database called 
			Igor. Igor is also a simple word processor, so that simulations and their result 
			streams can be easily annotated. Igor can also send data to pro Fit, which will produce
			plots and return them to Igor, where they can be added to any annotation.