The Equation_set object is now a simple list of eqns with no more
functionality than List(Equation).  However, we leave it as a separate class
for now.

State_variables represent a particular region of space.  Therefore they are
unique (their id's are numbered consecutively).  They have a pointer back to
the Layer or Air_Mass that "owns" them.  They have a value for the state
they represent, eg temperature.  At the moment this is untyped.
   Should I have a different State_variable subtype for temp, mass_flow,
   etc (allows region of space to be geometrically discretized differently
   for different states) or should each region have many state variables
   (preserves the uniqueness of the region) << also see eqn below >>

Coefficients have a value (float, what should it be - NonDimensional?)
of the coupling and a State_variable they are coupling to.  They live
inside Equations and are not accessible from outside.  Currently,
Coefficients have a type flag: 
enum State_variable_enum { ENTHALPY, TEMPERATURE, MASS_FLOW_RATE }.
  I'd like to change this to alternative types of Coefficient (derived
  classes).  If we type the State_variables, the Coefficients will have to
  be typed as well, eg a Temperature_coefficient couples two
  Temperature_state_variables together.

Equations have a state_variable for which they are an equation (I presume
thercan be >1 eqn per sv) and a list of Coefficients (at least 1, the self
coupling).
  Do eqns have to be homogeneous, ie do all coefficients have to relate to
  the same state variable.  If not, the State_variable of the eqn needs the
  different state values in it (see above).  If yes, then the eqn should be
  typed, ie we`d have a matched set Equation - Coefficient - State_variable.
The domain theories operate in terms of Equations (generating & modifying,
see later).  Each equation stores a total_gain, ie the energy injected into
the region that is not handled by a coupling coefficient.  Each eqn also
holds its left/right resistance/capacitance.
  How about generalizing this to a function that given a direction, will
  return the resistance/capacitance from the "node" to the region boundary
  in that direction.  This would make going to 3d trivial (for the eqns at
  least)

Equations are collected together by the domain theories into a list, and
these lists are passed round the EKS Building & Plant side classes.  This
List is called an Equation_set.  You can have many different Equation sets
pointing to the same Equations - so for example Layer has an Equation_set
pointing to the nodal equations,  Surface has an Equation_set pointing to
the next_to_surface Equation, Room could have an Equation_set pointing to
all its surface equations, etc.


Building / Plant classes  &&  Domain classes

Context asks Building to discretice itself.

Layer gets Conduction::generate_eqns() to make a set of eqns representing
it.  The eqns are internally coupled.
Construction gets Conduction::combine_eqns() to join 1-layer Equation_sets
into a multilayer Equation_set.

Room gets Convection::generate_eqns() to make a set of eqns representing
it.  The eqns are internally coupled.
Building gets Convection::combine_eqns() to join 1-air_mass Equation_sets
into a multiroom Equation_set.

Contents gets Conduction::generate_eqns() to make a set of eqns representing
it.

At this point we have all the equations.

Room gets Convection::add_coupling() to connect its air_mass eqn_set to its
Constructions multilayer eqn_sets.  << It actually interacts with Surface
rather than directly with Construction).

Room gets Radiation::add_coupling() to connect its Constructions multilayer
eqn_sets for longwave exchange.  << Again interacts with Surface >>

Room then does something about coupling in its contents to whatever.
<<don't know what yet>>

At this point we have all the equations coupled together.

Building takes its boundary conditions.  It gets its incident shortwave
radiation and uses Room::shortwave_distribution() << which in turn use
Construction::<< or Surface::>> shortwave_distribution() to distribute
the incomming energy around the building.  It is actually Construction
<<or Surface>> which calls Radiation::inject_energy() to add the gain
to the appropriate Equation.

Rooms then get the energy from their HeatSources, and get Construction 
<<Surface>> to call Radiation::inject_energy() and Air_Mass to call
Convection::inject_energy()

Finally, Building gets the remaining boundary conditions (temp, air movement,
etc) and arranges for external Construction to inject the appropriate energy.
<<not completely sure I understand what has to be done here>>

At this point we have a complete system <<ignoring plant for the time being>>

Context then asks Building for its equations.  Building gets these from
Constructions and Air_Masses and returns them.
The Equation_set is then time discretized and converted into a matrix
<< by Context or by Solver or by Equation_set>> and passed to the Solver.
The Solver returns a vector of state values which are inserted directly
into the State_variables (no propagation => no synchronization required).
The time is advanced, and round we go again.


Domain Classes

Conduction:
	// generate eqns for a solid region of space (internally coupled)
	List(Equation)	generate_equations ( List(State_variable) state_vector,
/**/					     EKSObject*  layer,
					     List(Equation)  prev_set);
	// combine two solid regions of space into one internally coupled one
	List(Equation)	combine_equations  ( List(Equation)  layer1,
					     State_variable  layer1_surface_node;
					     List(Equation)  layer2,
					     State_variable  layer2_surface_node);
		// surfaces could default to SV[n] of layer1 and SV[0] of layer2
//	// couple the specified SV in eqn_set to the given SV with given res/cap
//	void	add_coupling ( List(Equation)  layer1,
//			       State_variable  node_in_layer1,
//			       List(Equation)  region2,
//			       State_variable  node_in_region2,
//			       EKSObject*  data_supplier);
	// add the given conductive energy to the gain for given nodes eqn
	void	inject_energy ( List(Equation)  layer,
				State_variable  node_in_layer,
				Energy  gain);
    /**/ the layer supplies Geometry (thickness) and Substance

Convection:
	// generate eqns for a fluid region of space (internally coupled)
	List(Equation)	generate_equations ( List(State_variable) state_vector,
					     EKSObject*  air_mass,
					     List(Equation)  prev_set);
	// combine two fluid regions of space into one internally coupled one
	List(Equation)	combine_equations  ( List(Equation)  mass1,
					     State_variable  mass1_coupling_node;
/**/					     EKSObject*	building,
					     List(Equation)  mass2,
					     State_variable  mass2_coupling_node);
		// mass flow rates given in Eqn res/cap
	// surface convection: couple the specified SV in eqn_set to the given SV
	void	add_coupling ( List(Equation)  air_mass,
			       State_variable  node_in_air,
			       List(Equation)  layer,
			       State_variable  surface_node,
			       EKSObject*  data_supplier);
	// add the given convective energy to the gain for given nodes eqn
	void	inject_energy ( List(Equation)  air_mass,
				State_variable  node_in_air_mass,
				Energy  gain);
    /**/ the building supplies MassFlowRates & directions


Radiation:
//	generate_equations()	// no radiation eqns
//	combine_equations()	//   ditto
	// longwave exchange: couple the specified SV in eqn_set to the given SV
	void	add_coupling ( List(Equation)  layer1,
			       State_variable  surface_node,
			       List(Equation)  layer2,
			       State_variable  surface_node,
/**/			       EKSObject*  data_supplier);
	// add the given radiant energy to the gain for given nodes eqn
	void	inject_energy ( List(Equation)  air_mass,
				State_variable  node_in_air_mass,
				Energy  gain);
    /**/ the room supplies areas and viewfactors
			  
