Structure relative widths incorrect when specifying labels and repeating more than once

[PieceMaker]

Structures have a method relative_widths which standardizes the layer widths to be out of 1. However, this standardization is currently implemented based on the label name. When appending layers to a structure, specifying labels, and setting repeats to a value greater than 1, the labels get duplicated as well. Therefore, when the relative widths are calculated, they wind up combining all layers with the same name and returning inflated relativities.

In the below example, there are two layers with the same width. I would expect each layer to have a relative width of 0.5. However, since the relative width is calculated based on layer label, only one relative width is returned and it is 1.

from solcore import material
from solcore.structure import Layer, Structure

T = 300
Bmat = material('GaAsP')(T=T, P=0.1)
layer = Layer(width=10e-9, material=Bmat, role="barrier")

structure = Structure([])
structure.append(layer, layer_label='layer', repeats=2)
print(structure.__len__())
# 2
print(structure.relative_widths())
# defaultdict(<class 'float'>, {'layer': 1.0})

[dalonsoa]

It is a (very) weird behaviour, to be honest, however, it is the intended one if we consider where it comes from:

This method was implemented to calculate what is call the strain balanced condition in quantum wells ages ago. In this condition, you need to know the relative widths of the quantum well, the barrier and the interlayers (if any). Now, it is often the case that barrier and interlayers are split in two (or more) individual layers, but that is irrelevant. The important bit is how much is the well, how much the barrier (in total) and how much the interlayers (in total). That is why all layers with the same label contribute as one.

So:

• It is weird? Yes.
• It is the intended behaviour? Yes.
• Should be the method renamed or do that calculation somewhere else? Certainly!
• Should we change it now? Well... maybe. For what it seems, it is not used anywhere else within the Solcore package anymore, but change it will break the backwards compatibility and we are not ready for that... yet.

I'm going to mark this issue with the tag "Next version" to include it in the next major release of Solcore.