Currently, the patches used within the radiative transport/view factor capability are defined via sideset. That is, additional sidesets are defined with a number-based suffix. This is disadvantageous because (1) there is no contiguous numbering for indexing into matrices pertaining to the view factors and (2) the map lookups for the sidesets tend to be expensive.
Design
Develop a contiguous numbering starting with zero for the patches that are generated, that can be stored and accessed in an efficient manner (no maps!).
I'm thinking that we compute the maximum number of sides on each element, and then add this many extra element integers to each element. Set these extra element integers by default to an invalid ID. As a side is defined as a patch, set the integer for said side to the index. We can also store these in a separate structure for quick looping.
There's one problem here: adaptivity. We don't natively transfer these integers to children (at least I don't think we do), but it should be easy to project these.
For visualization, we could create sidesets for the patches or store the values in an aux field (use Roy's new side vars?!).
Impact
Will speed things up. Impact to user should be minimal.
loganharbour
commented
1 year ago
Reason
Currently, the patches used within the radiative transport/view factor capability are defined via sideset. That is, additional sidesets are defined with a number-based suffix. This is disadvantageous because (1) there is no contiguous numbering for indexing into matrices pertaining to the view factors and (2) the map lookups for the sidesets tend to be expensive.
Design
Develop a contiguous numbering starting with zero for the patches that are generated, that can be stored and accessed in an efficient manner (no maps!).
I'm thinking that we compute the maximum number of sides on each element, and then add this many extra element integers to each element. Set these extra element integers by default to an invalid ID. As a side is defined as a patch, set the integer for said side to the index. We can also store these in a separate structure for quick looping.
There's one problem here: adaptivity. We don't natively transfer these integers to children (at least I don't think we do), but it should be easy to project these.
For visualization, we could create sidesets for the patches or store the values in an aux field (use Roy's new side vars?!).
Impact
Will speed things up. Impact to user should be minimal.