Open Edgar-21 opened 2 months ago
I think the first approach would be more streamlined since it would use the same method for any surface definition. Not needing to root solve is a nice plus. Funny that this was the initial approach we thought up for NWL calculations before implementing our current one.
If we converted the theta-phi grid to x-y-z, could we just bin the surface points into those x-y-z patches? It's still not algorithmically "cheap" but maybe cheaper than root finding
We can calculate phi directly from x-y, right? So we can know which toroidal slice of the theta-phi grid we're in, and then just search in poloidal space?
(x,y) -> (R, phi)
Find nearest phi_grid < phi
Map theta-phi points @ phi_grid to {R_grid,Z_grid}
Search for (R,Z) in {R_grid, Z_grid}
Map (R_grid_found, Z_grid_found) back to (theta_grid, phi_grid) and check neighboring grid patches to confirm location
NWL utils currently rely on using some value for wall_s to root solve for theta, assuming the points lie on the surface defined by that wall_s value. For a custom FW (constant offset or whatever), this doesn't work.
My suggestion is an approach in which the surface used for calculating the NWL is already broken up into the appropriate patches during the geometry creation phase (using the point cloud definition and some cubit commands). The surface source retains the surface id which the particle crossed. The corners of each bin would then also be known ahead of time (from the point cloud). I think dagmc files retain the same surface IDs as in cubit, if not this is much harder. No root finding is required for this approach, and it works the same for a wall_s surface and a custom one.
The following steps jump to mind to implement this.
An alternative would be to find the poloidal angle for which the offset vector from the plasma surface in the toroidal plane passes through the point where the neutron crossed the first wall. This approach can be used to bin the crossings and perform the area approximation/normalization in a similar manner to how it is currently implemented. I think this should be provided as an alternate method, alongside the current implementation.
I'd suggest the following steps to implement this.
2 and 3 could be combined.