Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NWL utils do not work for first wall definitions other than extrapolating with wall_s>1 #146

Open
Edgar-21 opened this issue Sep 4, 2024 · 4 comments
Labels
bug Something isn't working robustness

Comments

@Edgar-21
Copy link
Contributor

Edgar-21 commented Sep 4, 2024

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.

  1. Add a method to the surface object that build the faceted representation in cubit, keeping things like surface id and area as metadata
  2. Add a function that extracts the source information and puts it in some useful format (probably use the centroid of each bin to refer to the NWL value)

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.

  1. Add a utility to find where the normal on a poloidal profile will pass through a point in space. There is potential with the convex profiles to have multiple points on the profile satisfying the condition, but for small offsets this is not really a concern (known issue with parastell). This is also useful for creating theta, phi plots of mesh tally results.
  2. Modify NWL utils to use either wall_s or the utility in 1 to find theta
  3. Modify NWL utils to use the utility in 1 to do the area approximation/normalization

2 and 3 could be combined.

@connoramoreno
Copy link
Collaborator

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.

@gonuke
Copy link
Member

gonuke commented Sep 7, 2024

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

@gonuke
Copy link
Member

gonuke commented Sep 7, 2024

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?

@gonuke
Copy link
Member

gonuke commented Sep 7, 2024

(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}

  • if Z > 0
    • if R > R_grid(Z_grid_max)
      • binary search in quadrant 1 of {R_grid, z_grid}
        Etc...

Map (R_grid_found, Z_grid_found) back to (theta_grid, phi_grid) and check neighboring grid patches to confirm location

@connoramoreno connoramoreno added invalid This doesn't seem right bug Something isn't working and removed invalid This doesn't seem right labels Sep 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working robustness
Projects
None yet
Development

No branches or pull requests

3 participants