Oct 11, 2013

[jgostick]

1 - Go Over Issues

Issue #41 - import scipy as _sp? We could do a mass search and replace, and also remove np while we're at it.

Issue #33 - The GUI can write VTKs using the new Visualization module, but we still need to think of some way to get data 'out' of the GUI.

Issue #39 - JTG made a lot of changes to the Geometry module. The main reason was to get the generation params out of the Geometry class call, and sent to the .generate() call instead. (See issue #39 for history of JTGs thoughts on this process). Are we all happy with these?

Issue #20 - Windows machines don't have Graphviz, so inheritance diagrams don't work. Extra incentive to get this working.

Issue #19 - SandboxDoc is gone, but other issues remain

2 - Development Discussions

• The use of staticmethods, are we overdoing objects?
• Self-protecting dictionary
• Constants dictionary
• Thermofluid properties: vector vs scalar pore_properties?
• @maghighi and JTG did a big reno of the Physic folder...BUT maybe we should revert it back to a class-less form? (See feature/PhysicsClassToModule)
• Algorithms...how should parameters be passed? What is the meaning of an algorithm object? Should we remove the explicit .run()?

3 - Documentation Updates

Lesson: please explain the correct usage of library, module, object, class, function, method, etc.

Proposal 1: All physics methods are fully documented in the docstring. For an example see OpenPNM.Physics.CapillaryPressure.Purcell()

Proposal 2: Agree to use Numpydoc style, which means we can't make up headings

Nothing has been done to the 'developer' guide yet

JTG has created an examples folder under docs, and started creating example scripts.

4 - Transport Solver Updates and Discussions

Mahmoud's work

5 - Status of the GUI

[jgostick]

Major Outcomes:

1. We've decided to allow SCALAR pore and throat properties, for things like temperature, pressure, surface tension, etc. Mostly physical fluid properties. A scalar temperature means that all pores have the same temperature. This will naturally work with the code since numpy automatically broadcasts. So if you calculate molar density (P/RT) with P and T as scalars, then you get a scalar value of c, if you send P and T for each pore you get c as a vector. The calculation will be transparent.
2. Physics module has been converted by to a file of functions, not objects. This just make more sense.
3. Algorithms will be altered to accept arguments more like the new Geometry class, so instead of sending arguments to the algorithm object, they will go to a configure() method, then a run. The idea is to keep it like a real experiment. You build the experiment:

Exp1 = OpenPNM.OrdinaryPercolation(object related params like loglevel)
then you set the experimental conditions:
Exp1.configure(experiental conditions like inlets, number of points, etc)
Then you run it on your sample (network):
Exp1.run(pn)
This may change, but something to this effect.

[maghighi]

@jgostick , Do you think we need a dictionary for this configure() method? And if we need a dictionary, where should we create it? Inside the Algorithm modules or as a part of network?
In other words,
self._net.Exp1_configuration['temperature']
or
OpenPNM.Algorithms.FickianDiffusion.configuration['temperature']
?