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
Hi everyone,
The last yt team meeting can be found here
<https://github.com/yt-project/project-records/blob/master/meeting-notes/n...>
.
Here are a few highlights:
- Madicken Munk and Stephanie Tonnesen have joined the steering committee
and we are extremely glad to have them. Welcome!
- This was the first team meeting (not counting workshops) in almost a
year, and the first in over two years in which the entire steering
committee was present. We are going to try to meet more regularly from now
on and are going to aim for quarterly meetings in the future.
- We will try to bring back regular PR triage hangouts to keep PR review
moving. This will also give PR submitters an opportunity to work directly
with reviewers. Stay tuned for more on these.
Thanks to everyone who participated!
Britton
Hi everyone,
We'll have our next yt team meeting on Tuesday, May 28 at 11:00am EDT via
Hangouts. All the yt project steering committee members will be there and
anyone else is free to attend. If you'd like an invitation to the hangout,
just sent me a message. I'll also post a link in slack when it starts.
We'll discuss various aspects regarding the state of the project. If there
is something you'd like to discuss, this is a good opportunity voice your
thoughts.
Have a great day!
Britton
Hi all,
This may be worth lookin into if someone is interested in setting up Azure
Pipelines CI for yt.
-Nathan
---------- Forwarded message ---------
From: Sam B <brices(a)gmail.com>
Date: Thu, May 23, 2019 at 3:39 PM
Subject: [NumFOCUS Projects] Microsoft/Azure offering to increase capacity
in free tier
To: <ci-working-group(a)numfocus.org>
bcc: projects(a)numfocus.org
Hi everyone,
We're in touch with the Product Marketing Manager for Microsoft Azure
DevOps and they are offering to increase the capacity for NumFOCUS projects
using their free/opensource tier.
If you're currently using Azure or would be interested please let us know
what you need and we can work something out for you.
Thanks,
Sam
--
You received this message because you are subscribed to the Google Groups
"Fiscally Sponsored Project Representatives" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to projects+unsubscribe(a)numfocus.org.
To post to this group, send email to projects(a)numfocus.org.
Visit this group at https://groups.google.com/a/numfocus.org/group/projects/
.
To view this discussion on the web visit
https://groups.google.com/a/numfocus.org/d/msgid/projects/CAAzXVxunL8_R40...
<https://groups.google.com/a/numfocus.org/d/msgid/projects/CAAzXVxunL8_R40...>
.
Hey everyone,
This tweet [1] was brought to my attention. There is good criticism in
that thread so let me respond:
1. It is ridiculous the YT paper is not cited. It defiantly was last I
checked. How that was dropped is beyond me. I will make sure that is
somehow fixed.
2. The "single slice plot of a single time step took 13 minutes" is also
misleading and is a mistake that I will make sure is somehow corrected. I
ran the simulations and wrote those sections and someone else ran the
plotting routines - who is admittedly a Paraview developer - and I should
have checked this text more closely. They were running both YT and
Paraview from their Apple Macbook. The 13 minutes was how long it took
that Macbook to volume render the dump versus Paraview, also running on a
Macbook but using an HPC set of nodes in the backend. It's a feature of
Paraview that you can do this.
Thus it is very misleading, I am embarrassed I missed it, and will make
sure it is corrected.
3. That said, there are some real deficiencies in YT for HPC-class datasets
- The ability to overlay several variables using different color schemes
on the same plot. There are times when having a temperature field and
metallically field - for example - overlaying a density field is helpful.
This was mentioned in the paper.
- The ability to volume render interactively until you get a plot exactly
how you want it. With YT you have to keep running a script over and over
again until it looks right. With paraview - even with a 26 Tb dump on our
classified systems - files can be open and rotated and modified in real
time to be exactly how you want in like 5 minutes. This was the cumbersome
comment.
- Paraview's ability to open up a huge file - again, we have a 26
terabyte file on our classified side we used Paraview - and let the
clusters do all the work in minutes from the comfort of your personal
Macbook. A file that YT was unable to ever fit in memory for volume
rendering no matter how many nodes we tried. This failure was not
mentioned in the paper, even though some working with such huge datsets may
be interested.
- Another omission from the paper is we did the same thing with gadget
data, that is arguably used more than Enzo. Long story short, YT could
never volume render the data, a known issue for at least 5 years [2],
whereas paraview both reads and volume renders gadget data natively.
Again, there is no reason to point this out in print even though some would
be interested.
- The issue with Paraview not reading Enzo natively was true at the time
of the analysis but is no longer true. There is a development version by
the above developer that reads Enzo.
- Some of you work with Alex Gagliano. Though he has been working on
this water network, he has nothing to do with how any of this paper is
worded. Please do not give him grief for what is in it. He has a future
paper on the subject and I guarantee these problems will not be repeated.
Anyway, I think YT is a fine product. I use it almost every day and
encourage all students to use it. I am embarrassed this was lost from the
paper and will work to restore it. But at the same time, to deny that
Paraview comes with many advantages - especially as the world becomes more
huge 3D TB sized datasets - is a little naive.
[1] https://twitter.com/njgoldbaum/status/1113163672120119298
[2]
http://lists.spacepope.org/pipermail/yt-users-spacepope.org/2014-June/005...
--
------------------------------------------------------------------------
Joseph Smidt <josephsmidt(a)gmail.com>
Theoretical Division
P.O. Box 1663, Mail Stop B283
Los Alamos, NM 87545
Office: 505-665-9752
Fax: 505-667-1931
If someone would be interested in leading this I think this would be very
valuable for the yt docs.
---------- Forwarded message ---------
From: 'sttaylor' via Google Summer of Code Mentors List <
google-summer-of-code-mentors-list(a)googlegroups.com>
Date: Mon, Mar 11, 2019 at 5:32 PM
Subject: [GSoC Mentors] Announcing Season of Docs 2019
To: Google Summer of Code Mentors List <
google-summer-of-code-mentors-list(a)googlegroups.com>
We’re delighted to announce the inaugural year of Season of Docs, a Google
program that fosters collaboration between open source projects and
technical writers. Season of Docs is similar to Summer of Code, but with a
focus on open source documentation and technical writers. Details are on
our website: g.co/seasonofdocs
<https://developers.google.com/season-of-docs/>.
Would you like to take part as an open source mentor in the inaugural year
of Season of Docs? Open source organizations can start thinking now about
the projects you’d like a technical writer to work on. Take a look at
the examples
of project ideas
<https://developers.google.com/season-of-docs/docs/project-ideas>. Reach
out to your community members to see who’d like to be a mentor for Season
of Docs. As a mentor, you don’t need technical writing skills. Instead,
you're a member of the open source organization who knows the value of good
documentation and who is experienced in open source processes and tools.
See the guidelines on working with a technical writer
<https://developers.google.com/season-of-docs/docs/tech-writer-collaboration>.
Organization applications open on April 2, 2019. See the full timeline
<https://developers.google.com/season-of-docs/docs/timeline> on the Season
of Docs website.
From April 30, Technical writers can explore the list of participating open
source organizations and their project ideas. Technical writers bring their
skills in designing and developing documentation to the open source
organization. Technical writer applications open on April 30. The list of
accepted technical writing projects is announced on July 30.
Please do tweet and blog about Season of Docs if you’d like to share the
news. We want as many people to know about it as possible. We’ve provided
logos that you can download and some example content on the press page
<https://developers.google.com/season-of-docs/docs/press>.
We’re looking forward to an exciting pilot of the Season of Docs program!
If you have any questions about the program, please email us at
season-of-docs-support(a)googlegroups.com.
Best regards
Sarah Maddox, Andrew Chen and the Season of Docs team
--
You received this message because you are subscribed to the Google Groups
"Google Summer of Code Mentors List" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-summer-of-code-mentors-list+unsubscribe(a)googlegroups.com.
To post to this group, send email to
google-summer-of-code-mentors-list(a)googlegroups.com.
Visit this group at
https://groups.google.com/group/google-summer-of-code-mentors-list.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-summer-of-code-mentors-list/5635...
<https://groups.google.com/d/msgid/google-summer-of-code-mentors-list/5635...>
.
For more options, visit https://groups.google.com/d/optout.
Hi yt-dev!
Over the past few days at the yt development workshop we added some new
bots/features to the yt repository that will hopefully help streamline some
aspects of the maintenance of the project. Here is what we came up with so
far:
- We added a welcome bot that welcomes and thanks new contributors to the
project on their first issue or PR.
- We added a triage bot that adds a "triage" label to all new issues. Once
they have been triaged and relevant labels have been added, the bot
automatically removes the triage label.
- We added a few "projects" to the projects tab of the repo (yt 4.0,
weather data, and frontend refactor). The intent here is to document what
needs to be done and track our progress on projects/milestones that we have
for yt.
- We added new labels for issues and PRs. We've added domains, index, and
coordinates labels to help refine our classifications of different issues.
I also updated the coloring on some of these labels, so
* greens: things that are direct improvements or are related to new
contributors
* browns: related to project infrastructure / tests / docs
* blues: future ideas / aspirations
* yellows: awaiting actions
* everything else is random
If any of you have feedback/concerns/other ideas on how we can improve what
I've mentioned here, ideas on what else can be done to streamline things,
or declaring your love for different color palettes, please chime in! These
are intended to be a helpful starting point, not random
unilaterally-decided additions to the project.
Best,
Madicken
Hi everyone,
Here at the yt developers workshop, we're experimenting with bots that will
help us with some project management. For example, we're about to enable a
bot that will prevent WIP pull requests from being merged. When we're done,
we'll send a summary email of everything we've done. If anyone starts
seeing weird behavior on the github repo or with PRs, either reply to this
email or say something on slack. We'll try to keep the noise down.
Britton
Hi all,
I'd like to publicly announce that I will be leaving my current position at
NCSA at the beginning of May and starting a 12-week batch at the recurse
center in NYC this summer. If you're curious about the recurse center, take
a look at their website for details (https://recurse.com). While I will
still be around and able to participate in the community at a lower level,
I will need to step down from my current role as primary maintainer of yt
when I leave NCSA so I can focus on new projects and opportunities.
Matt has volunteered to take up some of the slack on code review but I'm
hoping that everyone else can also chip in. We also have two postdocs here
at NCSA (Madicken Munk and Jared Coughlin) who have both expressed interest
in stepping up their contributions to yt and helping out with day-to-day
support and maintenance. I also hope we can have a conversation about
updating yt's governance documents and adding rotating members to the
steering committee at the development workshop next week.
I would like to continue maintaining unyt as part of the yt project going
forward as I expect that will take substantially less time than maintaining
yt as a whole. If people are nervous about yt depending on unyt when I'm
not employed to work on yt development that is fair and I'm happy to talk
about the relationship between unyt and yt in light of all of this.
My plan for the next few weeks is to help get yt-4.0 in a state where we
can do a release. That means merging the yt-4.0 branch into master, helping
out with testing and documentation, and triaging and fixing remaining
issues. I don't know if we'll be able to do a yt 4.0 final release by May
but hopefully we'll at least have a much more solid base to work from.
I'm going to try my best to make this transition as smooth as possible. If
you're aware of places where I could take action now to lead off headaches
down the road it would be great to get reminders about those places.
It's been an amazing experience to have so much of my professional life and
achievements influenced by yt and the yt community over the past 8 years or
so. I'm looking forward to seeing all the cool new things you all will
build in the next few years.
With a heavy heart,
Nathan
The yt community is proud to announce the release of yt 3.5.1. This is a
patch release and includes a number of minor improvements and bugfixes.
yt (https://yt-project.org) is an open source, community developed toolkit
for the analysis and visualization of volumetric data. Development is
hosted on GitHub (https://github.com/yt-project/yt).
See the changelog below for a summary of new features, changes, and
bugfixes.
For more information, including installation instructions, links to
community resources, and information on contributing to yt’s development,
please see the yt homepage at http://yt-project.org and the documentation
for yt 3.5.1 at http://yt-project.org/docs/3.5.1
<http://yt-project.org/docs/3.4.1>.
Binaries for yt 3.5.1 are available via pip and conda. If you installed via
the install script or use conda to manage your python installation, you can
update yt via:
$ conda update -c conda-forge yt
And via pip if you manage your python installation with pip:
$ pip install -U yt
As always, if you have any questions, concerns, or run into any trouble
updating please don’t hesitate to send a message to the mailing list or
stop by our Slack or IRC channel.
yt is the product of a large community of developers and users and we are
extraordinarily grateful for and proud of their contributions. Please
forward this announcement on to any interested parties.
Best,
The yt development team
*Changelog*
- Avoid use of deprecated field names internally, silencing some
user-visible deprecation warnings. See PR 2073
<https://github.com/yt-project/yt/pull/2073>.
- Fix crash using clump.save_as_dataset when field_data is not defined.
See PR 2079 <https://github.com/yt-project/yt/pull/2079/>. Thank you to
Adam McMaster (@adammcmaster) for the fix.
- Fix for ramses RT and group reading under Python3. See PR 2092
<https://github.com/yt-project/yt/pull/2092>.
- The line integral convolution annotation no longer erroneously
includes noise in regions where the vector field under consideration has a
value of zero. See PR 2094 <https://github.com/yt-project/yt/pull/2094>.
- Explicit set language_level to 2 in yt's cython code to avoid breakage
with a future Cython release that changes the default language_level. See PR
2100 <https://github.com/yt-project/yt/pull/2100>.
- Add support for matplotlib 3.0, fixes issue where colorbar values were
sometimes incorrect. See PR 2101
<https://github.com/yt-project/yt/pull/2101>.
- Fix incorrect weighting function used in definition of
mozotta_weighting field. See PR 2102
<https://github.com/yt-project/yt/pull/2102>.
- Fix an issue that caused reading a particle field from a cut_region to
produce a crash. See PR 2106 <https://github.com/yt-project/yt/pull/2106>
.
- Fix unit issues leading to incorrect angular momentum calculations.
See PR 2114 <https://github.com/yt-project/yt/pull/2114>.
- Fix incorrect behavior when creating a covering_grid or arbitrary_grid
with a left_edge or right_edge that has specified units. See PR 2119
<https://github.com/yt-project/yt/pull/2119>.
- Avoid reading big-endian Gadget binary data. See PR 2120
<https://github.com/yt-project/yt/pull/2120>.
- Convert radius to appropriate unit in the sphere plot callback. See PR
2128 <https://github.com/yt-project/yt/pull/2128>.
- Fix issues doing CIC deposition on a chunk containing only one oct.
See PR 2130 <https://github.com/yt-project/yt/pull/2130>.
- Fix FutureWarning generated by NumPy 1.16. See PR 2133
<https://github.com/yt-project/yt/pull/2133>.
- Fix issues reading ARTIO multiresolution N-body particles. See PR 2140
<https://github.com/yt-project/yt/pull/2140>. Thank you to Gillen Brown
(@gillenbrown) for the fix.
- Fix crashes when a plugins file has a function that uses global
variables defined in the file. See PR 2144
<https://github.com/yt-project/yt/pull/2144>.
- Fix several bugs in the Enzo-p frontend. See PR 2150
<https://github.com/yt-project/yt/pull/2150>.
- Fix issues reading ramses data on Windows. See PR 2152
<https://github.com/yt-project/yt/pull/2152>.
