-
Notifications
You must be signed in to change notification settings - Fork 12
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
Implement alternating division schemes between adjacent hexahedra and wedges #172
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the quick fix @connoramoreno
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we need to keep these different alternative scheme variables? For me it's hard to follow. If we require even numbers of poloidal voxels, I think there may be a cleaner way to do it.
Can we just determine the meshing scheme from whether For the very first wedge of the first toroidal plane it's 0+0+0 =0 even. Then it alternates until we get to the last wedge which must be odd if we have an even number of poloidal voxels. Then the first hex on the next cfs layer is 1+0+0 =1 odd and alternates... and so on. The first wedge on the next toroidal slice is 0+1+0 =1 odd - which is what we need it to be... and so on. So within each hex generation method you can have
|
Could then have canonical ordering indexed in a list with index 0 and 1 and directly use the one you want indexed by the alternate scheme variable. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Definitely simpler by making that red/black calculation be calculated in the methods that create the tets, but I have some questions on the choices of indexing.
In particular, I'm not sure (or don't remember) the motivation for theta_idx
to go from [1,num_phi]
instead of [0,num_phi-1]
parastell/source_mesh.py
Outdated
self._create_tet(vertex_ids) | ||
|
||
def _create_tets_from_wedge(self, theta_idx, phi_idx): | ||
"""Creates three tetrahedra from defined wedge. | ||
(Internal function not intended to be called externally) | ||
|
||
Arguments: | ||
idx_list (list of int): list of wedge vertex indices. | ||
theta_idx (int): index defining location along poloidal angle axis. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand the stencil below. Maybe it's been this way for a while, but I don't see any points in this stencil at a s_idx=1
which I expect.
I'm also not sure why this goes from [1,num_phi] istead of [0,num_phi-1]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I agree that it's slightly confusing, and our indexing scheme could use some changes to make it more intuitive. The way we've defined things is that the vertex at the magnetic axis and those on the first closed flux surface all have a s_idx
of 0. This is also why theta_idx
begins at 1, to differentiate the first vertex on the first CFS from that on the magnetic axis.
It would make much more sense to have s_idx = 0
to always refer to the magnetic axis vertices, and s_idx = 1
refer to the first CFS. As such, we could then have theta_idx
start from 0. I think I'll also change the naming convention from using to theta_idx
and phi_idx
to using poloidal_idx
and toroidal_idx
, respectively, to avoid confusion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is all definitely a lot easier to follow!!!
parastell/source_mesh.py
Outdated
self._logger.error(e.args[0]) | ||
raise e | ||
|
||
if angle == 360.0 and self._num_toroidal_pts % 2 != 1: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Later on you compare _toroidal_extent
to 2 pi. It might make more sense to convert to radians before this test for consistency.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this important fix @connoramoreno
Modifies the source mesh workflow to alternate the scheme by which hexahedra and wedges are split into tetrahedra. The alternating schemes ensure that the faces of adjacent tetrahedra, but not belonging to the same hexahedron or wedge, match one another. This avoids gaps and overlaps between adjacent non-planar hexahedron and wedge faces. This alignment is ensured for adjacent wedge-wedge, wedge-hexahedron, and hexahedron-hexahedron pairs. Code changes are as follows:
alternate_scheme
,toroidal_alt_scheme
, andcfs_alt_scheme
boolean parameters to control whether an alternate division scheme should be used for a given elementtest_source_mesh
unit testsThe alternate splitting schemes are illustrated below. Plots will follow to demonstrate expected behavior of total volume and total source strength as a function of mesh discretization.
(a)
(b)
Figure 1. Alternate schemes for adjacent hexahedra. (a) Original and (b) alternate.
(a)
(b)
Figure 2. Alternate schemes for adjacent wedges. (a) Original and (b) alternate.
Closes #168