Open ChRen95 opened 7 months ago
A solution that came up to me would be to add another nested class to DiskElementUnit
:
class DiskElementUnit(Unit):
# ... (existing code)
class PillarElement(Unit):
"""
Represents a pillar element unit, a unit used to subdivide a DiskElement in its width direction.
"""
def __init__(self, parent: 'DiskElement', index: int, **kwargs):
"""
:param kwargs: Additional hook values as keyword arguments to set explicitly.
"""
super().__init__(label=f"{parent}[{index}]", parent=parent, **kwargs)
self.length = length
class Profile(Unit.Profile):
"""Represents a profile in context of a pillar element unit."""
@property
def pillar_element(self) -> 'DiskElementUnit.PillarElement':
"""Reference to the pillar element. Alias for ``self.unit``"""
return cast(DiskElementUnit.PillarElement, self.unit)
# ... (rest of the existing code)
In my opinion this would make sense, since a pillar_element
and a disk_element
, share attributes like the length e.g.
`
Result of the internal discussions.
Regarding the PillarElement (and RingElement in the same manner) my main concerns are about computation speed. The current approach in https://github.com/pyroll-project/pyroll-pillar-model with array valued hooks is not as clean as it could be, but it is fast. The count of pillars has a very small impact on speed, whereas the count of disks has heavy impact due to the expensive unit and hook mechanics.
I have moved all regarding the protocols to a new issue #163. Diskussion here only about the new elements.
A seperate
PillarElement
class should be created to be able, to subdivideDiskElements
in width direction. This would of course make adjustments inside the PillarModel necessary. I'm pretty much up for suggestions about how this is useful and should be a part of the pyroll-core package.