Hi all,
I'm going to be doing PR triage tomorrow, and I set up a Zoom meeting
in case anybody wants to join:
https://illinois.zoom.us/j/103327722
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.
-Matt
Hi yt-dev!
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:
https://github.com/yt-project/governance/pull/1
and
https://github.com/yt-project/ytep/pull/7
Our existing governance structure is located at
https://ytep.readthedocs.io/en/master/YTEPs/YTEP-1776.html
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.
Madicken
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.
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.
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.
Many thanks,
-Ronan Hix
Hi folks,
I've just issued a pull request to remove all of the headers that
include the opening comments and the licensing information from the
*individual source files* in the yt-4.0 branch. This means that
information will only be in the top-level repository, rather than in
every file.
It is, evidently, bad practice to include the copyright -- which in
any case has been out of date for several years anyway -- in each
individual file, as it's included in the top-level directory. The
leading comments in almost 100% of cases provided no useful
information; it may be the case that they should be re-added, but as
of present most are just copy/pasted.
I'm posting this here to make sure that it can be considered before
getting merged, although having inspected the diff I believe there are
no behavior changes. The question is basically if we want this
boilerplate, frequently-outdated info in every file or not.
https://github.com/yt-project/yt/pull/2298
(PS the pull request is super long.)
-Matt
Hi all,
I've got a PR that removes py2 compat code:
https://github.com/yt-project/yt/pull/2163
I'm wondering if we had come to a decision on what was required for it
to go in. Are we going to block on getting answer testing re-enabled?
Or is passing the unit tests sufficient?
-Matt
Hi folks,
Nathan's Herculean unyt pull request into yt-4.0 is passing all the tests.
https://github.com/yt-project/yt/pull/2219
Since it's been under review for a fairly long time, I am going to
merge it tomorrow unless I hear otherwise. All of the changes are
really straightforward, and overall a net gain.
-Matt
Hi folks,
With the advent of the ytdata frontend, it seems that all usages of
the GeometryHandler / Index object's functions save_data,
_reload_data_file, load_object and get_data are all dead now.
Any reason they can't be dispensed with? I suspect-without-evidence
that even before ytdata, usage was close to nil.
-Matt
Hello all,
I’ve been in contact with Dr. ZuHone for the last few weeks about my efforts to create a new yt frontend for Chimera data, and he directed me here for further assistance.
Chimera is a unigrid dataset with spherical polar coordinates and a nonlinear r-axis scaling; as a result, it needs a custom mesh rather than the AMR grids or SemiStructured meshes present in some of the existing frontends. The Chimera datafiles all contain arrays which detail the edge positions of the gridblocks, so creating an array of grid-edge coordinates is fairly trivial. Theoretically, I would expect the transfer of this coordinate array into a yt mesh object would be fairly straightforward, but I don’t have enough familiarity with the functionality of the Unstructured Mesh class to do so without some guidance. I was hoping that someone here might be able to shed some light on what the contents of this class do and how it functions as a whole, such that I can create one for Chimera.
Many thanks,
-Ronan Hix
Hi yt-dev,
I may or may not have sent this posting to the list already, but i wanted to alert folks to this open position we have here at the Harvard-Smithsonian Center for Astrophysics as a Python data scientist working for the Chandra X-ray Observatory in Cambridge, Massachusetts. It would be very different from yt work but I think that folks who have developed lots of Python experience with yt would be perfect for this position.
I work for Chandra and I am very happy here. This is a different position from the one I have, as mine is scientific staff and this one is a data scientist position, but I think the work will be interesting and you get to support one of NASA’s great observatories. Although I am not responsible for the posting, you will likely be working and interfacing with me quite a bit also.
This posting is closing in 4 days but so far we have not found any suitable candidates, and there will be another posting:
https://www.cfa.harvard.edu/hr/postings/19-26.html
Please let me know if you have any questions.
Best,
John Z
