Mailman 3 January 2016 - yt-dev

PR Triage Hangout (New Time!)
by Hilary Egan 19 Jan '16

19 Jan '16

Hi everyone, This spring's PR Triage Hangouts will be at *12pm EST every Wednesday*. Here's the link to the next hangout, and let me know if there are any problems with this time. https://plus.google.com/b/107728486871834552760/events/cr17uqi688edbscsae41… -- Hilary Egan Astrophysical and Planetary Science Department University of Colorado Boulder _______________________________________________ yt-dev mailing list yt-dev(a)lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

2 1

Issue #1160: Analysing GIZMO output by using yt (yt_analysis/yt)
by Ka Hou Leong 19 Jan '16

19 Jan '16

New issue 1160: Analysing GIZMO output by using yt https://bitbucket.org/yt_analysis/yt/issues/1160/analysing-gizmo-output-by-… Ka Hou Leong: I have analysed some GIZMO test problems by using yt .I found a weird situation.In two particular test problems, yt can identify gas, but can't read the date of gas correctly. In the others test problems, yt can identify and read the date of gas correctly.The situation is strange as it may sound. It seem like a bug. The following is the problem list : Square Test and Gresho Vortex (unsuccessful tests) Zeldovich pancake collapse and spherical collapse and Keplerian Disks and santa barbara cluster(successful tests) The following is the website of test problems of GIZMO: https://bitbucket.org/phopkins/gizmo/wiki/Test%20Problems.md _______________________________________________ yt-dev mailing list yt-dev(a)lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

1 0

Some updates from AAS
by Matthew Turk 17 Jan '16

17 Jan '16

Hi folks, I wanted to write a quick email about some neat things that I heard about at AAS. The coolest one was that, on the heels of their announcement that software papers (of any length) would be welcome in AAS journals, the AAS is going to be making it possible for some articles to feature updating author lists. These author lists would be tied in to ADS as well. What this would mean is that future software and instrument papers can have authors added to their list, which will be tracked by ADS. I am over the moon about this, as it is by far my most wanted feature for software papers. More information will be coming, and this is not ready yet, but Chris Lintott has been pushing this forward. The other one, which is also quite cool, is that interactive figures are on their way to AAS journals. What this precisely means and how it will be implemented is still being decided, but Gus Muench has been working toward it; he's said that d3 and plotly type plots will be on the list of things to include, and of course there as the Vogt paper from last year about X3D plots in AAS journals. -Matt _______________________________________________ yt-dev mailing list yt-dev(a)lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

2 1

Future of the install script
by Nathan Goldbaum 15 Jan '16

15 Jan '16

I've changed the subject line to avoid derailing the other thread. On Friday, January 15, 2016, Matthew Turk <matthewturk(a)gmail.com> wrote: > Hi Nathan, > > (I'll reply to Andrew a bit later once I've thought it over.) > > I'd strongly campaign against unifying the two scripts right now, if > ever. I don't like that we have two either, but I don't think we > should make this part of the 3.3 release cycle, just because it's yet > another major potential disruption. It would be nice to work out a > way to migrate nicely to conda, but maybe we should hold off until we > have infrastructure in place for our own conda package builds? What do we do about people who want to install on the latest versions of OSX? What about clusters that have older SSL installs? Right now our solution is to tell people about get_yt.sh when they complain on the mailing list, but I wouldn't be surprised if we're missing people who give up after getting errors. Why do we need our own package builds? What about simply linking to get_yt.sh on the website? > > On Thu, Jan 14, 2016 at 5:20 PM, Nathan Goldbaum <nathan12343(a)gmail.com > <javascript:;>> wrote: > > > > > > On Thu, Jan 14, 2016 at 1:45 PM, Andrew Myers <atmyers2(a)gmail.com > <javascript:;>> wrote: > >> > >> Dear yt developers, > >> > >> yt version 3.2 was released back in July of 2014. Since then, there > have a > >> been a number of cool new features added (good work, everyone!), and it > >> would be nice to get them into a stable release. However, there are a > few > >> major things that need to be done before that can happen. First, there > are a > >> number of outstanding issues related to the volume render refactor that > need > >> to be addressed before 3.3 can be released. Additionally, version 3.3 > will > >> include unstructured mesh visualization support, and there is some more > work > >> Matt and I need to do before that is ready. Other than those things, > though, > >> is there anything I'm leaving out that people want to get in before > version > >> 3.3 is released? > > > > > > I would like to see the install script situation resolved. In > particular, I > > think get_yt.sh and install_script.sh should be merged, and users > > should be able to choose at install time whether or not they want a > > source-based install or a miniconda-based install. > > > >> > >> > >> Thanks for your time, > >> Andrew > >> > >> _______________________________________________ > >> yt-dev mailing list > >> yt-dev(a)lists.spacepope.org <javascript:;> > >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > >> > > > > > > _______________________________________________ > > yt-dev mailing list > > yt-dev(a)lists.spacepope.org <javascript:;> > > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > > > _______________________________________________ > yt-dev mailing list > yt-dev(a)lists.spacepope.org <javascript:;> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > _______________________________________________ yt-dev mailing list yt-dev(a)lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

4 6

jetbrains licenses
by Matthew Turk 15 Jan '16

15 Jan '16

Hi folks, we finally got the JetBrains licenses. Ping me off list to get one. We have 10. _______________________________________________ yt-dev mailing list yt-dev(a)lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

1 0

What needs to be done for a 3.3 release?
by Andrew Myers 15 Jan '16

15 Jan '16

Dear yt developers, yt version 3.2 was released back in July of 2014. Since then, there have a been a number of cool new features added (good work, everyone!), and it would be nice to get them into a stable release. However, there are a few major things that need to be done before that can happen. First, there are a number of outstanding issues <https://bitbucket.org/yt_analysis/yt/issues?q=%5Bexperimental%5D> related to the volume render refactor that need to be addressed before 3.3 can be released. Additionally, version 3.3 will include unstructured mesh visualization support, and there is some more work Matt and I need to do before that is ready. Other than those things, though, is there anything I'm leaving out that people want to get in before version 3.3 is released? Thanks for your time, Andrew _______________________________________________ yt-dev mailing list yt-dev(a)lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

5 6

Testing infra update
by Kacper Kowalik 14 Jan '16

14 Jan '16

Hi, I've revamped the way we handle PR testing. We no longer poll Bitbucket repository every 'n' minutes, instead we're utilizing webhooks [1]. It also means that testing and docs building should happen almost immediately. Whole thing is implemented as a simple web server [2] that runs on fido and listens for POST messages coming from Bitbucket. It allows for fine grained control over code executed upon different events i.e. pr creation, update, merge can be treated separately. As result we can gradually expand its capabilities. Please be advised that I'm still testing it. If you notice any odd behaviour (PRs not being tested, PRs being tested too many times) please let me know. Cheers, Kacper [1] https://blog.bitbucket.org/2015/06/24/the-new-bitbucket-webhooks/ [2] https://bitbucket.org/yt_analysis/fido-prhandler _______________________________________________ yt-dev mailing list yt-dev(a)lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

2 1

IPython dependency in the install script
by Nathan Goldbaum 14 Jan '16

14 Jan '16

Hi all, With the release of Jupyter, the number of dependencies necessary for the IPython notebook has exploded somewhat. I just created a new virtualenv and did "pip install jupyter". The output of "pip freeze" for this virtualenv is pasted here: http://paste.yt-project.org/show/6141/ As you can see, jupyter brings in a large number of python packages, and it would be a real pain to manually install all of these in the install script. This is coming up because I'm in the middle of updating the notebooks in our docs to use the latest notebook format. To make it so users can *read* these notebooks, I'd also like to update the version of IPython/Jupyter being installed. I can see three ways forward, in order of my preference: 1. Use pip to install jupyter, which will automatically bring in IPython and all its dependencies. I'd probably pin it at Jupyter 1.x / IPython 4.x to avoid having it update to a possible incompatible notebook version in the future. 2. Manually install Jupyter's dependencies in the install script, as we've done for IPython in the past. 3. Punt and just keep on installing IPython 2.4.1. What do people think about this? Would anyone have objections to relying on pip to install Jupyter and its dependencies? Thanks for your advice, -Nathan _______________________________________________ yt-dev mailing list yt-dev(a)lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

3 3

"Overdensity" in yt 2.x and 3 and the Enzo Dark_Matter_Density field
by Josh Moloney 13 Jan '16

13 Jan '16

For the past couple of days I've been trying to figure out halo profiles and virial radius calculations in yt, which so far has mostly consisted of trying to understand the differences in the "Overdensity" field between yt versions. The biggest difference is due to yt-2.x using an incorrect redshift scaling for the overdensity calculation. The field is defined as Matter_Density / (rho_crit_now * data.pf.hubble_constant**2 * (1 + data.pf.current_redshift)**3) which scales the critical density by (1+z)^3 instead of only the matter component. This error is fixed in yt 3, but I'm not sure if it's corrected for or known by people still using legacy versions of yt. After accounting for this, there is still a ~1.5% difference in the mean overdensity in my simulation between yt 2.x and 3 (the yt 3 value is lower). This difference comes from the particle_density component of the matter_density. The yt 2.x version uses the particle masses from Enzo and yt's CICDeposit_3. The yt 3 version uses the Dark_Matter_Density field from Enzo, which uses Enzo's build in cic method. As far as I understand, differences in cic methods could lead to different values over subdomains of a simulation, but shouldn't lead to different total masses over the entire simulation box. I went through each grid of my simulation individually, and in every one of them the sum of the Dark_Matter_Density values is less than the sum of the particle_mass values. Differences range from 0.4% to 3.5% across individual grids. My guess is that this means the Dark_Matter_Density field is losing mass that is deposited in the ghost zones outside of the grid boundaries. I'm not familiar enough with the internal workings of Enzo to know if this has any impact on the actual simulations, or if it is only an issue with the data outputs. Either way, it might be a good idea to have yt return to calculating the particle_density field from particle masses and do the cic deposition in yt, at least for Enzo data. - Josh _______________________________________________ yt-dev mailing list yt-dev(a)lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

3 3

Fwd: Imgur API v1 and v2 Deprecation Notice
by Matthew Turk 13 Jan '16

13 Jan '16

Hi folks, What fortuitous timing! Kacper has recently deployed a cool new image pastebin, which we can switch "yt upload_image" to use. But, if anyone wants to update the code to work with v3 of the imgur API, that would also work to keep yt up to date. ---------- Forwarded message ---------- From: Imgur API <api+deprecate(a)imgur.com> Date: Mon, Jan 11, 2016 at 5:40 PM Subject: Imgur API v1 and v2 Deprecation Notice To: matthewturk(a)gmail.com Hi Imgur API user! It looks like you’re using version 1 or 2 of the Imgur API. We’re reaching out now to let you know that, starting on March 28, 2016, these versions will no longer be supported. We encourage you to migrate your application to Imgur API version 3 before this date. If you need some assistance with that, feel free to check out api.imgur.com for documentation. If your application uses authorization, you will also need to upgrade to oauth 2.0. If you have any questions, we’d be happy to help at api+deprecate(a)imgur.com. Best, The Imgur API team _______________________________________________ yt-dev mailing list yt-dev(a)lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

2 1