Hi Ronan,
Sorry for the late reply -- have been traveling, and this required more
concentration than I had available! :)
On Tue, Aug 13, 2019 at 10:11 AM Ronan Hix
Hey all,
I’ve been putting the finishing touches on the new frontend for Chimera data, which means I’ve been working on adding support for yin-yang 3D data.
For any unfamiliar with this format, the model is compromised of two identical grids in spherical polar coordinates, each of which is comprised of 16 h5 files. One of these grids undergoes a rotation such that the 2 sections fit together like 2 halves of a baseball.
I'm not 100% sure that I understand this -- but one very helpful set of info for this would be to understand if that data is defined at cell centers or other locations, and if there are any overlapping cells.
Issues with getting the second (rotated) grid to transform correctly in polar coordinates have prompted us to have the frontend convert to cartesian before grid generation, which had yielded promising results; however, there is an issue that I was hoping someone on this list might be able to shed some light upon.
OK, that's interesting; ideally we'd want to avoid that step, but I won't second guess you here! :)
As seen in the first attached image, the two pieces appear to be rotating and meshing correctly (The two bright rays on the left are the overlapping border zones of the two grids), but there are some fairly significant artifacts which peak at the 45-degree angles and have minimums on the cardinal directions. Additionally, ss you can see in the second image, where the mesh lines have been overplotted, the pixelation extends beyond the borders of the actual cells. The combination of these factors lead me to believe that this issue is a result of the cartesian pixelation subroutine’s functionality with SemiStructuredMesh grid formats. My supposition, which I invite anyone more versed in the topic to correct, is that the routines to pixelize use the delta x and delta y of the grid cells, which results in a pixelation region larger than the actual cell (due to its askant orientation). This would cause overlap from neighboring cells which would be maximized on the 45s (As delta x/y in the frame of the broader coordinate system is maximally misaligned with the actual cell) and would be essentially zero along the cardinal directions, in keeping with the observed behavior.
While I'm not completely positive, I believe this is a very plausible reason. Just to make sure I understand what's going on, we are using this stack of components: * *Cartesian* geometry, as converted by the code Chimera * Semi-structured mesh (i.e., varying dx, dy, dz within a grid, but consistent in planes along each axis) * Cartesian pixelizer
If this is indeed the case, what sort of workaround exists? I’ve seen examples on the website of slice plots of completely unstructured meshes, so it must be within the realm of possibility, but I don’t have enough experience to be sure how to implement this.
I have to understand the problem more fully, but there are almost certainly things to do, including re-centering the pixel values. By any chance could you send a sample output of x, y, z, dx, dy, dz values that I could test? Or, if we're using spherical, r, theta, phi, and the corresponding dr, dtheta, dphi?
Many thanks, -Ronan Hix _______________________________________________ yt-dev mailing list -- yt-dev@python.org To unsubscribe send an email to yt-dev-leave@python.org
