H5Mesh conflict between cuba data tables

[itziakos]

It looks that the hdf5 backed mesh defines the two tables to hold the container data attirbute and the items data content on a table node with the same name. See lines:

https://github.com/simphony/simphony-common/blob/master/simphony/io/h5_mesh.py#L128
https://github.com/simphony/simphony-common/blob/master/simphony/io/h5_mesh.py#L791

The problem was not detected because the tests do not really check for that sort of interaction.

[roigcarlo]

Hi @itziakos

I created a branch with the fix. I wanted to add a test as well but I think that the problem is quite more complex that only the name error in my class...

Since I was not sure how to test this with a unittest I decided to ensure internally (at least to check that the bug was corrected ) that this was not going to happen adding:

if not "meshData" in [g.name for g in self._group._f_iter_nodes()]:
    self._data = IndexedDataContainerTable(group, 'meshData')
else:
    error_str = "Trying to create an existing group with name: {}"
    raise KeyError(error_str.format("meshData"))

Of course it detects that prior to the changes in the name the group was duplicated. The problem is that it detects more duplicated groups, and not only with the mesh.

In general, each time that a container is generated here ( for the mesh case for example ):
https://github.com/simphony/simphony-common/blob/master/simphony/io/h5_cuds.py#L211

Specifically, this error is being triggered by

test_add_get_mesh
test_mesh_rename
test_iter_mesh
test_delete_mesh

So I assume that this is happening because the python get_xxx() functions of h5_cuds.py are returning the container by copy. This does not cause problems if the original objects is "normal" object, since the group does not exist, but when python group = self._root.mesh._f_get_child(name) is not empty it duplicates the groups.

I have been able to duplicate this as well with the h5_lattice class, and it looks that h5_particles is going to behave the same way

The problem is that I am not sure how to handle all of this...

[itziakos]

Since I was not sure how to test this with a unittest I decided to ensure internally (at least to check that the bug was corrected ) that this was not going to happen adding:

The best option is to check directly the hdf5 files for the expected layout.

The problem is that I am not sure how to handle all of this...

Thanks for taking the time. I wanted to cleanup the io module for a while but I guess will need to do it earlier and cleanup the layout.

Let me give it go.

[itziakos]

@roigcarlo, I am spliting this issue to the two separates bugs, so that the PR fixes are smaller and easier to review. So discussion ##144 (comment) is now #148