Extending network with properties on the network (i.e. as imported) breaks subsequent simulations

OpenPNM.Network.tools.extend() causes parameters that are defined on the network before extending the network (like pore diameters on imported networks) to be increased to the new size, but with the new entries filled with NANs. This causes subsequent steps to show warnings like “RuntimeWarning: invalid value encountered in less”.

The problem is that if I do

pn = op.Network.Cubic(shape=[5,5,5],spacing=1,name='net')
pn['pore.diameter'] = 1
pn.add_boundaries()

I end up after adding boundaries with

pn['pore.diameter'] = array([  1.,   1.,   1.,   1.,   1.,   1.,   1.,   1.,   1.,   1.,   1.,
                  ...  nan,
                  nan,  nan,  nan,  nan,  nan,  nan,  nan,  nan,  nan,  nan,  nan])

If I follow the typical routine of defining Network first, then Geometry, I get

pn = op.Network.Cubic(shape=[5,5,5],spacing=1,name='net')
pn.add_boundaries()
geom = op.Geometry.GenericGeometry(network=pn,pores=Ps,throats=Ts)
geom['pore.diameter'] = 1
pn['pore.diameter'] = array([1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
            ...
                 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0])

Here everything is fine, and I would like to have this behaviour automatically for imported networks also.

When a network is imported (i.e. from the Statoil class), it usually carries network properties like the pore coordinates and usually also pore diameters. If this network is imported, boundary pores cannot automatically be appended, as there is no generic method currently implemented in OpenPNM, the implemented methods to add boundaries are for the Delaunay or Cubic class only, and specific to them. So adding boundaries has to be done manually, i.e. by creating a new network and then stitching this to the imported one. With stitching, the network size increases. OpenPNM.Network.tools.extend() handles the extension of the network. For parameters that are not in a hard coded list in the extend() method, the size of the array is increased to the new network size, but the remaining entries are filled with NANs.

Not knowing about this behaviour can be very confusing, and it took me several hours to track this down. The NANs in cause warnings like “RuntimeWarning: invalid value encountered in less”.

This is a general issue when importing networks that already hold properties, and which have to be extended in OpenPNM to get boundary pores. So there should be a generic approach to it.

Some ideas that I can think of right now:

• special add_boundaries() method for generic imported networks that already hold properties - this method could stitch a cubic network around the network, and could automatically take care of extending the properties that are already on the network - I guess the ideal version, but hard to implement for totally generic imported networks
• allow user to determine behaviour of extend() - i.e. change hard coded list, or use his own extend() method instead, or by inserting a flag in the extend() arguments (i.e. imported network with properties on the network yes/no), or pass a list of specific parameters that are already on the network and which should be increased to the new size, and the remaining entries filled with zeros.
• specify a procedure according to which the user should import networks, and leaving everything as is

I am willing to work on this, as soon as we decided on a way to approach it.

[jgostick]

Also, as for importing Geoms and Networks, the i mport classes ‘could’ return tuples of objects like: (net, geom) = op.Utilities.IO.Statoil.load(file). BUT, I think that the 3 lines of code I gave in my previous comment are probably more straightforward.

[jgostick]

The idea is that you put NaNs in there SPECIFICALLY to get the RunTime warning. That way you know that simulation is not complete yet. The check_data_health method checks for NaNs and tells you where the problems are.

When you add pores to a network you then have to specify properties for those pores. Deleting pores is easy, but adding requires subsequent work. This is all expected behavior.

As for a transfer method, I think it’s a bit overkill, since moving data between dicts and deleting entries is just basic python.

The basic flow would be like this:

geom = op.Geometry.GenericGeometry(network=net, pores=net.Ps, throats=net.Ts)
for item in ['pore.volume', 'pore.diameter', 'throat.length']:
    geom[item] = net.pop(item)

Then you can add boundary pores to the network, and then create boundary pores, THEN create a Geometry object for the boundary pores. This new Geometry object will then either need to have the correct size info assigned. Basically, since you have not imported the boundary pores, you still have to assign porescale models for it.