Investigating a new approach to the fluids module
- I don't really like storing the recipe as a dictionary, so I'm trying to have each fluid actually own the method used for each property estimation
- Also, I"m separating GenericFluid into GenericGas and GenericLiquid, since the default properties of these two will be much different
Merge branch 'develop' into feature/Fluids_v2
More attempts to build Fluids using 'composition'
Use of 'partial' functions to improve the way the Fluids module composition works
More alterations to the new Fluids module
Fixed dict definition errors
Merge branch 'feature/TopologyModule' into feature/MajorReno
A complete rethink of the inheritance structure of the code
Minor tweaks
- At this point the inheritance seems to work
- And composition of fluids onto network object is working well
Major changes to code flow
- Geometry, Physics and Fluids now all operate the same
- They produce composite objects that write their data to the appropriate place
- Renamed many files and methods to be lowercase
Merge remote-tracking branch 'origin/develop' into feature/MajorReno
More major changes
- After drawing up a flow diagram of code, I realized it was illogical
- All modules now write their data to the network object
- We still must decide if and how to attach objects to the network
- run_script works fully upto but not including algorithms...still need a way to specifiy which fluid is of interest
Some fine tuning
- Add Water and Air classes for fluids
- Tried adding more functionality to OpenPNMBase
Added a 'binding' between fluids and the network object as pn._fluids
- pn._fluids is a list that contains all fluid objects.  The fluids add themselves to this list when they are 'created'
- I decided to place the actual fluid object in the list, rather than just the 'name'
- I added two methods to the Network class which interact with the fluids objects: fluid_listing and fluid_update
- I think starting all these method with fluid (or physics, or geometry) will keep the autocomplete cleaner
Same 'binding' changes to Geometry and Physics
- Added methods to Network for listing and updating connected objects.
Rename Diffusivity.py to diffusivity.py
Rename Viscosity.py to viscosity.py
Reverting code to write fluid and physics properties to Fluid objects
- After exploring using the Network to store all data, it got MESSY.  We're much better off storing values on the fluids.
- I think the idea of create a set of methods on Network that can manipulate the Fluids and Physics objects will remedy all issues we anticipated with this silo'd data storage
Surprizingly few minor changes to make OP algorithm run with new arrangement
- This is of course because the code is almost identical to how is used to be!
Added a lot of 'wrapper methods' to the Network class
- These methods allow code to read and write fluids and physics data by calling a generic method in Network.
- If we want to change how and where data is stored, we only need to change these wrapper methods, and the fluids and physics methods remain unchanged