I'm going to be doing PR triage tomorrow, and I set up a Zoom meeting
in case anybody wants to join:
If you can, and want to, feel free to stop by. I'll try to set one up
for further in advance for next time.
As many of you know, the yt-project has been growing and evolving over the
past several years (to new domains, to new datasets, to support new
packages, etc.). To accompany that growth, we'd like to take the
opportunity to update our governance structure. We've been working on
updating our governance model for the yt project and I've submitted two
companion PRs with drafts of this updated governance:
Our existing governance structure is located at
The first PR is to a new governance repository, where our governance
documentation will live separately from the YTEPs. This will allow us to
maintain and minorly update our governance without having to update YTEP.
The second PR is to the YTEP repository and generally outlines the core
values and ideas we want our governance structure to reflect. Hopefully all
of the things I've listed in the YTEP are reflected in the governance docs.
As members of the community, I'd like to solicit feedback from all of you
about these governance documents. Do these reflect our community values?
Should we add anything? Do you feel everything is clear? Is this too much
governance for our community right now? Is there something that's missing?
Feel free to reply here or comment on the pull requests! Our governance
will be better with your feedback.
PS - I tried to build in a mentorship structure into our maintainer
structure to help with onboarding new maintainers. I'd especially like to
know if you all think this would be valuable to you or if it is adding
unnecessary constraints to our community.
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.
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.
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.
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.