CUDS: Type of lattice is not properly described

[itziakos]

It is not clear what are the accepted string values for the type attribute in the CUDS Lattice container.
From the factory functions in https://github.com/simphony/simphony-common/blob/master/simphony/cuds/lattice.py we find four of the possible values, but the full set of acceptable values should be defined in ABCLattice. One might consider that it would be better if the bravais type was given as an Enum.

[kemattil]

I have already proposed the same in a private discussion with IWM: the Bravais type should be an enum (bravais lattices are mathematical concepts are there are only a handful of them). This choice would have additional benefits: then the base_vector could then be set according to the type and spacing(s) in the constructor. That is, the base_vector would be totally internal to ABCLattice (or maybe a read-only property). This is turn would make the factory methods (make_square_lattice etc.) unnecessary. In summary, I slight redefinition of the ABCLattice interface would make sense.

[tuopuu]

Personally, I would like to preserve a possibility of scaling the lattice (not the size parameter, but base_vect) for possible future needs. That would make it easy to "fit" a lattice to different geometries without constructing a new one. Allowing scaling of base_vect in a non-uniform way would possibly change the type of the lattice, for example, from cubic to hexagonal. Therefore I find the lattice type parameter quite irrelevant in practice, unless we really want to keep it fixed and forbid all other changes to ABCLattice attributes except the name.

[tuopuu]

Another option would be to implement 'type' as a function, which returns a Bravais type, IF base_vect is correctly defined for that particular type. Otherwise it would return 'Custom' or so.

[kemattil]

If we restrict to Bravais lattices, the type is a fundamental concept: the type of the lattice defines the base vectors/primitive vectors (of course lattice spacing also needed) and the only way to "scale" a lattice is to change the lattice spacing. Changing a lattice type on-the-fly does not make sense. There is no such thing as a custom lattice (if we restrict to Bravais lattices).

[itziakos]

Personally, knowing the bravais type currently allows me to easily select optimized vtkDataSets for Cubic, Rectangle and Square lattices. While one could check the base vectors to infer the type, I still think that it is more elegant to make a simple type check than floating point comparisons.

Regarding the mutability of the lattice type, I think that this is probably a separate issue.

[tuopuu]

My comment was more of a general kind. I think that we should not make unnecessary restrictions here. It's equally easy to define spacing h and the type, than a tuple (hx,hy,hz) which would then force the lattice into one of the Bravais lattice categories. Anyway, I don't have strong opinion on this: Cubic lattice will be the one that is used most often at least in LB world. And @kemattil, you are absolutely correct, there is no Custom, only Orthorhombic in the case I was referring to. :)

[itziakos]

The SSB has decided on this issue, removing the SSB label.

[tuopuu]

This issue will be fixed in the upcoming lattice API change, when we move from base_vector to primitive vectors representation.

[tuopuu]

Fixed in #205. Lattice type is now defined with BravaisLattice(IntEnum) enumeration members.