-
This issue is a documentation of a discussion that Jeff and I had tonight about how two phase invasion algorithms can create results that other programs can interact with.
Invasion algorithms could …
-
There was some discussion about how to restructuring the code so that networks know a bit more about how there were generated. The proposals are outlined in the attached pptx document, but they are su…
-
We need the ability to write new properties in some pores based on some size calculations other than those used in generate()
-
When no geometry or label is given. Physics functions should assume that you are referring to the entire network.
-
I have just realized that we have no way of removing a label, we can only add them. Set_pore/throat_info need to either accept a data arg with true/falses, or add a mode for "remove" labels since the…
-
Hi all,
The pore property 'coords' is missing from boundary pores in networks generated from Cubic because that block of code has been commented out.
We need coordinates on all pores for network cons…
-
It has been discussed a few times about enforcing (or encouraging) the use of custom methods to add or edit property data. I wanted to compile the main reasons why we should be more strict about this…
-
## 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 mo…
-
I pondered this last night and had a vision about how the Geometry module should work now that we're giving it more power. This combines issues #31, #37, (which I've closed) and in some ways also inc…
-
I think the IO folder is redundant. I think that the VTK functions should be moved to Visualization, and the network import function should be in Generators. Generating a network object by importing…