Features/blocking

[MarleneBusch]

Description

This changes a lot:

• Blocking:

  • I have implemented ray blocking.
  • I have used linear bounding volume hierarchies as acceleration structure. I followed an implementation by Karras.
  • Per definition blocking happens between the heliostat and the target (after the reflection) and shading happens between the light source and the heliostat. Only blocking is implemented.
  • Ray extinction works globally.
  • Blocking is disabled for surface and kinematic reconstruction, the user cannot change this with their input. It is enabled in the motor position optimization.

• Data:

  • I have updated all data files with the updated PAINT data, i have also recreated all scenarios with the new data and adapted the tests using these scenarios.

• Kinematic/Initial orientation:

  • When I used the new PAINT data to execute ARTIST I realized we did make a conceptual mistake. I think the initial orientation was originally introduced to define the overall orientation of the heliostats when loaded. It used to UP and everything worked out, we included rotations in the kinematic to compensate for ARTISTs SOUTH orientation. In PAINT we changed the initial orientation to SOUTH. One would expect that the additional rotation in ARTIST is now not needed anymore because the systems are oriented same. However, even though PAINT changed its orientation, the surfaces (doesn’t matter if from deflectometry or ideal nurbs directly) are per definition still sampled "parallel to the ground"/ UP. -> The initial orientation in PAINT has no influence.

• Regularizers:

  • The regularizers for the surface reconstruction are new. I have read about regularization strategies in optimizers and I realized that it makes more sense to regularize the control points directly instead of the surface points, as the control points are the actual optimizable parameters, so applying smoothness or deviation penalties there, directly affects the gradients during optimization. This makes the regularization more effective.
  • The total variation loss is replaced by a Laplacian loss on the difference of old and new control points because I realized that the total variation loss in its previous implementation didn’t discourage piecewise-constant, sharp changes, which we don’t want, the Laplacian control-point regularization produces continuous, smooth deformations.

• Nurbs:

  • Nurbs control points are not canted anymore. The canting is applied to heliostat surfaces when they are sampled. This makes more sense as Nurbs are defined in their own parametric space, independent of any global or heliostat-based coordinate system. The rotation should only be applied when sampling the surface because the control points themselves represent the intrinsic surface geometry, not its orientation in the environment. Rotating control points would distort the surface definition rather than simply changing its placement in space.

• Gradient reduction and distributed setup:

  • The gradient reduction in the kinematic reconstruction and surface reconstruction on distributed devices was not entirely safe. For very specific device/heliostat_group/rank configurations (mostly caused by unequal distribution of samples to ranks and when samples from one heliostat were split up to different ranks) it didn’t reduce properly. The new reduction strategy is safe, but I had to add the assumption that each heliostat is optimized by the same number of samples.

• Examples:

  • I have adapted the paint plot examples to work with this new setup.
  • I have included an example for a full field reconstruction with aim point optimization.

---

Questions:

• Is the /core directory still structured in a meaningful way? -> core_utils.py, blocking.py and util/raytracing_utils.py

Remarks:

• I have intentionally not changed the read the docs tutorials, I will do this after one of your reviews as soon as I know the changes in artist are accepted.
• This change is not backwards compatible.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• [] I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules