Initial work on Fluids Module
run script for feature/FluidsModule
The DiffusiveConductance method now demonstrates roughly how this module will work
Little change to DiffusiveConductance to catch nans
Interface type properties are now specified relative to a phase
* as in: water['surface_tension']['air'] = 0.072
* also added contact angle as a fluid property, but not sure about this.
Enabled interface type properties (surface tension) to be specified relative to other phase
* as in: water['surface_tension']['air'] = 0.072
Refinements of the Fluids module, I almost like the way it works now
* Still not sure how to deal with surface tension and contact angle since they are the result of interactions between several phases
* Still not sure how to store "conditions", which are the result of Fluids and Network properties.
* The main issue is that multiple fluids means multiple versions of each 'conditions'
More Refinements
* I realized that fluid dependent pore and throat conditions should be stored with the FLUID not the NETWORK.  This is implimented in OrdinaryPercolation
* Still not sure how to deal with surface_tensiona and contact_angle rigorously
Created GenericFluid class, which creates a "fluid" object, that interfaces with a pore network, in a very specific way to populate common fluid properties.

See run_scriptJTG3.py for an example of how to use it.
My version of a GenericFluid class
* James: I deleted a bunch of your methods only because I wanted to see the bare behavior.  I envision your methods being readded.
* At the moment it returns a dictionary.  I'd like to to have more methods, such as update.
Attempting to associate fluids (phases) with a specific pore network
More or less complete prototype now
* The fluids are NOT generated, they are SPECIFIED by a set of parameters that dictate how to predict properties, like a recipe
* A recipe for each is stored on a network under pn.phases[name']
* The network updates its fluid properties by combining its conditions with the fluid recipe
* Also included an example subclass of GenericFluid for Water, which mearly contains the specific recipe for water
* This is either genius, or completely ridiculous.  We'll see in the morning.
more refinements to Fluids
* added a create method, but basically just renames the params to a more logical name.
* Added a remove method to disassociate a fluid from a network
* Made the asssign method also run the update so the fluid properties are created
Fluid properties are now written to the network
* the fluid module write pore_conditions['property_phase'], so pore_conditions['viscosity_water'] and pore_conditions['viscosity_air']
* there may be a bug in the way the phase name string is passed around and stored...will fix later if necessary
* renamed fluid.update to fluid.refresh to avoid confusion with the dictionary.update method
Confirmed that the name cascade properly
* The 'name' field inside the params_fluid1 will be the name that is used within the network (ie. ph.phases['name'] and pn.pore_conditions['property_name'])
* Added rename method to change the name stored in the dictionary
Some changes to boundary and solver.

There may be a bug, because it's not fully connected to Physics module
yet.
Merge branch 'feature/FluidsModule' of https://github.com/PMEAL/OpenPNM into feature/FluidsModule
Changing the name of TransportLinearSolver

Removing TransportLinearSolver from import section of the algorithms.
Changing the solver for Permeability