jgostick

NOTE: If we do this, which we should, we need to update the dependency handler which at present looks for 'pore.blah', so it will need to see 'blah' and realize...

Another problem with this is that we are now allowing 'pore_temperature=373.0' to return 373. So if we do ``T = phase['pore.' + temperature']`` inside the code, this will break.

So, it looks like the dependency handler and the numeric return will both be broken with this change. I'm thinking perhaps we should keep things as they are?

We have discussed this and decided to close it for the following reasons: 1. The values all have defaults, so there is not that much overhead on the part of...

Option 2 is probably a good idea with or without option. Notes: * It might be nice to do this as a health check when you actually run a simulation,...

We can add this as a feature in the future, so I have given it the 3+ milestone

This would really hurt readability. Maybe a better idea would be to add an additional option or function to get this CSR style if needed for performance?

We are currently putting DNS calculations in PoreSpy, using OpenPNM in the background.

I like this idea, a geometry class called ``Continuum`` which does all the stuff needed to create a 'pore-less' region. This could also be used to do porous continuum using...

This would require some pore-scale models like ``bruggeman`` for calculating the effective diffusivity of the "nodes". We had a few models towards this idea in V1 but I purge them...