Source mesh total source strength scaling incorrectly with mesh discretization

[connoramoreno]

The expected scaling behavior for total source strength (sum of SourceMesh.strengths) with increasing mesh discretization is asymptotic. One would expect that with finer discretization, total source strength would approach some singular value (hopefully, the true value).

In particular, what I would expect (though please check my logic) is that closed flux surface (CFS) discretization would have the largest impact on source strength accuracy, since source strength is directly dependent on CFS value. I would then expect poloidal and toroidal angle discretizations to have a lesser though still asymptotic impact since those are mostly related to accurately representing the shape of the plasma.

However, in the current source mesh implementation, as @Edgar-21 pointed out, this is not the observed behavior. Varying each mesh dimension independently, I observed the trends in the following plots, with fusion power representing total source strength.

Figure 1. Calculated fusion power as a function of CFS discretization. Number of poloidal grid points and number of toroidal grid points are kept constant at 61 each.

Figure 2. Calculated fusion power as a function of poloidal angle discretization. Number of CFS grid points and number of toroidal grid points are kept constant at 11 and 61, respectively.

Figure 3. Calculated fusion power as a function of toroidal angle discretization. Number of CFS grid points and number of poloidal grid points are kept constant at 11 and 61, respectively.

Doing the same for the source mesh implementation in PR #167, we observe an entirely different set of trends. This may warrant some discussion.

Figure 4. Calculated fusion power as a function of CFS discretization. Number of poloidal grid points and number of toroidal grid points are kept constant at 61 each.

Figure 5. Calculated fusion power as a function of poloidal angle discretization. Number of CFS grid points and number of toroidal grid points are kept constant at 11 and 61, respectively.

Figure 6. Calculated fusion power as a function of toroidal angle discretization. Number of CFS grid points and number of poloidal grid points are kept constant at 11 and 61, respectively.

[gonuke]

A couple of things to try discussed in person:

• confirm whether or not the total volume of the mesh is asymptotic with these variations
• refine the mesh uniformly in all dimensions at the same time and plot total source strength vs average tet volume or similar

[connoramoreno]

Variation of total mesh volume (sum of tetrahedral volumes) with each mesh parameter, using updated element splitting. For each parameter sweep, other mesh discretizations are kept constant in the same manner as previously done.

Variation of total mesh source strength and total mesh volume with total number of elements, increasing mesh fineness in each dimension simultaneously. Again, using the updated element splitting routine.

[gonuke]

What is the plasma volume reported by Cubit?

[gonuke]

The total volume should be independent of the number of CFS grid points!?!?! The total enclosed volume should only depend on the resolution of the outer surface. All internal volume should be part of some internal element.

[gonuke]

Is the code for these calcs in the repo somewhere? Perhaps as a 'utility' or something?

[connoramoreno]

The plasma volume reported by Cubit is 1.09764e+08 cm^3. It may be worth mentioning that only a single period is being modeled, so number of elements, total volume, etc. are for that single period. However, I've scaled the fusion power calculations to be for a full four-period source (not sure why but here we are).

The change in total volume as CFS grid points varies is rather small (~2.3%) but agreed, it should be zero.

I don't have the code for these calculations available in this repository but I could include them? Not sure how useful they'd be as an actual utility. Fusion power is calculated as a conversion of sum(source_mesh.strengths) and total volume is calculated as sum(source_mesh.volumes), which are rather simple, so I'm not sure it's quite worth including a utility function for them.

[gonuke]

I wonder what happens if you go from N layers in the CFS directions to N+1 by dividing only a single layer?

[connoramoreno]

Using the same parameters we use for our source mesh tests, num_s = 6, num_theta = 41, num_phi = 9, toroidal_extent = 15.0, yields a total volume of 3.1599e7 cm3. The CFS grid for that mesh is [0.0, 0.2, 0.4, 0.6, 0.8, 1.0]. No negative volumes are present.

Inserting an additional grid point at s = 0.1, such that the CFS grid is [0.0, 0.1, 0.2, 0.4, 0.6, 0.8, 1.0] increases total volume to 3.1839e7 cm3 (+0.76% change). No negative volumes are present.

Inserting an additional grid point at s = 0.5, such that the CFS grid is [0.0, 0.2, 0.4, 0.5, 0.6, 0.8, 1.0] decreases total volume to 3.1244e7 cm3 (-1.12% change). No negative volumes are present.

Inserting an additional grid point at s = 0.9, such that the CFS grid is [0.0, 0.2, 0.4, 0.6, 0.8, 0.9, 1.0] decreases total volume to 3.1183e7 cm3 (-1.32% change). 0.73% of tetrahedra have negative volume.

[connoramoreno]

Using the same poloidal and toroidal angle grids as above, using a CFS grid of [0.0, 1.0] (no CFS division) yields a total volume of 3.1313e7 cm3. Adding an additional grid point at s = 0.5, such that the CFS grid is [0.0, 0.5, 1.0], increases total volume to 3.2149e7 cm3 (+2.67% change).

It's worth noting that for each of these, there are tetrahedra present with negative volumes. For no CFS splitting, 6.56% of tetrahedra have negative volume. Splitting the CFS grid once results in 0.82% of tetrahedra having negative volume.

[connoramoreno]

I wonder if maybe some tetrahedra are being created multiple times? Or perhaps some tetrahedra are created incorrectly (e.g., the wrong vertices are used such that some tetrahedral volumes extend beyond where they're supposed to)?

For the record, I checked our tetrahedral volume calculation against OpenMC's and they agreed for each tetrahedron (checking many thousands of tetrahedra).

[gonuke]

Can we check the tet count as we just add one layer in the CFS direction? Generally speaking, I'm a little concerned about this and not entirely sure how to test it properly.

[connoramoreno]

The number of tetrahedra created seems to check out. Using num_s = 6, num_theta = 41, num_phi = 9, toroidal_extent = 15.0, yields 7,360 total tetrahedra, which matches the expected value (using the same calculation we do in the source mesh test). The CFS grid for that mesh is [0.0, 0.2, 0.4, 0.6, 0.8, 1.0]. No negative volumes are present.

Inserting an additional grid point at s = 0.5, such that the CFS grid is [0.0, 0.2, 0.4, 0.5, 0.6, 0.8, 1.0] increases the total number of tetrahedra to 8,960, which also matches the expected value. No negative volumes are present.

[gonuke]

And what's the change in volume in those two cases? Can get get the volume of the different CFS layers?

[connoramoreno]

For the first case, the total volume is 3.1599e7 cm3 and the volume per layer is [6.3775e6, 6.7710e6, 6.3808e6, 6.1233e6, 5.9464e6] cm3. For the second, where s = 0.5 is inserted, the total volume decreases to 3.1244e7 cm3 (-1.12% change) and the volume per layer is [6.3775e6, 6.7710e6, 3.0502e6, 2.9753e6, 6.1233e6, 5.9464e6] cm3.

As expected, it would seem that the volume discrepancy is coming from the layer that is split. The split layer has volumes 3.0502e6 cm3 and 2.9753e6 cm3, combined 6.0255e6, whereas the whole layer has volume 6.3808e6 cm3 (-5.57% change).

[gonuke]

That is a big change in those layers, especially since it's 100% internal and there should be no change.... 😕

[gonuke]

Neighboring hexes need to be divided in an alternating pattern to avoid "pillow" or "overlapping" sets of triangles