Seth R. Johnson
Seth R. Johnson
From today's planning: the surface physics actions will proceed through multiple stages. 1. Volume finding is part of the along-step (linear) kernel; it establishes the distance-to-boundary and moves the particle...
Lol jinx @hhollenb
Yes agreed, layer ID instead of trying to define a new sense. Forward/reverse for +1/-1 index. ORANGE has an inside/outside sense but it's universally defined by the quadric surface's coefficient,...
> Alternatively something like a LayerTraversalView that encapsulates all of the traversal logic for a surface and has some minimal +1/-1 directions for each trick might be more memory efficient....
Sounds good to me! One point though is I think `LayerId` should be only the "global" reference frame corresponding to the data layout (i.e., a SurfacePhysicsRecord would have an `ItemMap`)....
Discussed yesterday: - `SubsurfaceMaterial` : locally indexed 0 -> N while crossing a surface, includes volumetric materials at entry and exit (integers) - `SubsurfaceInterface`: roughness and other parameters (half integers)...
Surface physics models will look like: ```c++ namespace optical { class SurfacePhysicsModel : virtual public SurfaceModel, virtual public OpticalStepActionInterface { using OpticalStepActionInterface::order; using OpticalStepActionInterface::step; using SurfaceModel::get_surfaces; }; class SmearRoughnessModel final...
Addendum to last post: - Surface physics models won't be concrete actions necessarily; they'll just have the same `step` interface and we'll embed them inside a "surface physics" action. -...
@hhollenb Would you mark this issue as "complete" with your little fixes from validation? 😄
Ah, I guess I didn't know that multiple "beam on" could be run per execution 😅 The *intended* behavior for `SharedParams` is to be set up once and torn down...