[yt-dev] RFC: Staggered deprecation through 3.1 and 3.2

Cameron Hummels chummels at gmail.com
Wed Jun 25 13:20:50 PDT 2014


Awesome!!  This is great news!  I've poked around at some of them, but
there are many dark corners of the code that I don't necessarily
understand, so having you take a shot will help immensely.  Thanks, Matt!

Cameron


On Wed, Jun 25, 2014 at 12:18 PM, Matthew Turk <matthewturk at gmail.com>
wrote:

> Hi Cameron,
>
> On Tue, Jun 24, 2014 at 8:35 PM, Cameron Hummels <chummels at gmail.com>
> wrote:
> > I will continue to work on these, but you're right, we need more people
> > working on these little issues or this will continue to be a big blocker
> and
> > not get done.  I can assign specific bugs to the specialists on those
> > issues, if it is helpful (see below).
> >
> > For all issues, see this page:
> > https://trello.com/c/NJMfoXdl/22-be-able-to-run-the-cookbook .  Reading
> the
> > description can give you some clues as to the source of the error, but
> the
> > best way to diagnose it is simply to go into the doc cookbook directory
> and
> > try to run the python script:
> >
> > e.g.
> > $ cd $YT_DEST/doc/source/cookbook
> > $ python script.py
> >
> >
> >
> > * VR - KDTree issues (Sam Skillman? Matt Turk?)
> > ----amrkdtree_downsampling.py
> > ----camera_movement.py -- something going on with statusbar in brick
> > counting!
> > ----opaque_rendering.py -- same as camera_movement.py
> > ----render_with_box_and_grids.py
>
> Sam and I will work out which goes to which of us, but I will probably
> take these on.
>
> >
> > * Light Rays and Light Cones (Britton Smith, John Zuhone, Devin Silvia)
> > ----make_light_ray.py
> > ----unique_light_cone_projections.py
> > ----light_cone_projection.py
> > ----light_cone_with_halo_mask.py
> >
> > * Profiles (Matt Turk, Nathan Goldbaum, other?)
> > ----global_phase_plots.py
> > ----profile_with_variance.py
> > ----rad_velocity.py
> > ----radial_profile_styles.py?
> > ----simple_profile.py
> > ----time_series_profiles.py
> > ----save_profiles.py
>
> I will take all of these.
>
> >
> > * Units working with everything in yt (Nathan Goldbaum, Matt Turk, John
> > Zuhone)
> > ----hse_field.py
> > ----simple_off_axis_projection.py
> >
>
> I think either Nathan or John, if they have time, might be good for
> these.  Failing that, I will.
>
> > * Miscellany
> > ----aligned_cutting_plane.py -- something is wrong with the derived
> quantity
> > AngularMomentumVector() in that it doesn't work fully for gas, but seems
> to
> > work OK for particles.
> > ----free_free_field.py--creating a new derived field (Matt Turk, Nathan
> > Goldbaum)
> > ----simple_slice_with_multiple_fields.py -- vorticity_squared fails as a
> > field.
>
> I'll do these.
>
> To summarize, here are the recipes I have committed to fixing:
>
> global_phase_plots.py
> profile_with_variance.py
> rad_velocity.py
> radial_profile_styles.py?
> simple_profile.py
> time_series_profiles.py
> save_profiles.py
> aligned_cutting_plane.py
> free_free_field.py
> simple_slice_with_multiple_fields.py
>
> and probably also:
>
> amrkdtree_downsampling.py
> camera_movement.py
> opaque_rendering.py
> render_with_box_and_grids.py
>
> -Matt
>
> >
> >
> > This is by no means a requirement to work on this, but it would help to
> take
> > a look at it to see if you can help correct a small bug here and there if
> > your name is listed here (or even if it isn't!)
> >
> > Cameron
> >
> >
> >
> > On Tue, Jun 24, 2014 at 6:09 PM, Nathan Goldbaum <nathan12343 at gmail.com>
> > wrote:
> >>
> >> Ah - I see that now.
> >>
> >> Yes, I agree that fixing the cookbook should be a blocker.  FWIW that
> card
> >> is marked as such.  As I said the other day, the blockers are on the
> yt-3.0
> >> and the documentation board.  We won't do the yt-3.0 release until all
> the
> >> cards marked as blockers are cleared.
> >>
> >> This is a big task - any help we can get on this from anyone following
> >> along would be much appreciated.  There are a lot of little tasks or
> tasks
> >> that can be completed in a couple hours by anyone that has a little with
> >> yt-3.0.
> >>
> >>
> >> On Tue, Jun 24, 2014 at 6:04 PM, Cameron Hummels <chummels at gmail.com>
> >> wrote:
> >>>
> >>> I think all of the cookbook items are blockers to be honest, because
> the
> >>> cookbook recipes should be tests that are seen as failing.
> >>>
> >>> https://trello.com/c/NJMfoXdl/22-be-able-to-run-the-cookbook
> >>>
> >>>
> >>> On Tue, Jun 24, 2014 at 5:32 PM, Nathan Goldbaum <
> nathan12343 at gmail.com>
> >>> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On Tuesday, June 24, 2014, Cameron Hummels <chummels at gmail.com>
> wrote:
> >>>>>
> >>>>> I think there remain some issues in the VR working in 3.0, which I
> >>>>> identified on the cookbook post on the trello board for yt-3.0.  For
> >>>>> example, I know the overlaying grids and overlaying boundaries does
> not
> >>>>> currently work.
> >>>>
> >>>>
> >>>> I don't see this on trello.  Can you make a card and mark it as a
> >>>> blocker?
> >>>>
> >>>>>
> >>>>>  That may be an easy fix, but it's something to keep in mind.  I was
> >>>>> going to work on it last week as I was doing the cookbook update,
> but I
> >>>>> figured it was just going to get replaced with the scene interface,
> so it
> >>>>> wasn't worth the time.
> >>>>>
> >>>>> I guess I'd still like to have all of the API breakage occur in the
> big
> >>>>> jump from 2.x to 3.0, but if people really want to get 3.0 out the
> door
> >>>>> asap, then perhaps that isn't compatible. Personally, I'm +1 on
> waiting to
> >>>>> have all the halo+VR stuff in 3.0 instead of 3.1, but if everyone
> else wants
> >>>>> a 3.0 out sooner, I will not block it.  I think having a super fancy
> VR and
> >>>>> awesome halo interface is one of the big pulls to getting people who
> have
> >>>>> not yet switched to join 3.0 (from both 2.x as well as non-users)
> even if it
> >>>>> takes a few more months, but I may be the minority here.
> >>>>>
> >>>>> Cameron
> >>>>>
> >>>>>
> >>>>> On Tue, Jun 24, 2014 at 10:08 AM, Nathan Goldbaum
> >>>>> <nathan12343 at gmail.com> wrote:
> >>>>>>
> >>>>>> Ok - I think the script in the issue description is sufficient.  Let
> >>>>>> me know if you need something more detailed.
> >>>>>>
> >>>>>>
> >>>>>> On Tue, Jun 24, 2014 at 10:07 AM, Matthew Turk <
> matthewturk at gmail.com>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> That's the one -- you mentioned it in a blockers email a few days
> >>>>>>> ago.
> >>>>>>>
> >>>>>>> On Tue, Jun 24, 2014 at 12:06 PM, Nathan Goldbaum
> >>>>>>> <nathan12343 at gmail.com> wrote:
> >>>>>>> > Sorry - not sure which issue you're talking about - this one
> maybe?
> >>>>>>> >
> >>>>>>> >
> >>>>>>> >
> https://bitbucket.org/yt_analysis/yt/issue/827/enzo-particle-fields-work-differently-than
> >>>>>>> >
> >>>>>>> >
> >>>>>>> >
> >>>>>>> >
> >>>>>>> > On Tue, Jun 24, 2014 at 10:02 AM, Matthew Turk
> >>>>>>> > <matthewturk at gmail.com>
> >>>>>>> > wrote:
> >>>>>>> >>
> >>>>>>> >> Related to that, do you have a reproducible script for the
> >>>>>>> >> particle
> >>>>>>> >> issue you reported?  If so, could you add that to either an
> issue
> >>>>>>> >> or a
> >>>>>>> >> trello card so I can work on it?
> >>>>>>> >>
> >>>>>>> >> On Tue, Jun 24, 2014 at 11:58 AM, Nathan Goldbaum
> >>>>>>> >> <nathan12343 at gmail.com>
> >>>>>>> >> wrote:
> >>>>>>> >> > I'd be +1 on this plan, although we should note that this is
> the
> >>>>>>> >> > plan in
> >>>>>>> >> > the
> >>>>>>> >> > release announcement.  We may also want to note that there are
> >>>>>>> >> > some
> >>>>>>> >> > issues
> >>>>>>> >> > with volume rendering of oct and particle data at the moment
> (I
> >>>>>>> >> > believe
> >>>>>>> >> > that's the case - let me know if I'm wrong there).
> >>>>>>> >> >
> >>>>>>> >> > I think that leaves analysis modules and documentation as the
> >>>>>>> >> > main
> >>>>>>> >> > blockers
> >>>>>>> >> > for a 3.0 release.
> >>>>>>> >> >
> >>>>>>> >> > -Nathan
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> > On Tue, Jun 24, 2014 at 9:53 AM, John ZuHone <
> jzuhone at gmail.com>
> >>>>>>> >> > wrote:
> >>>>>>> >> >>
> >>>>>>> >> >> +1 on Matt's proposal. -1 on a beta.
> >>>>>>> >> >>
> >>>>>>> >> >> My worry about a beta release is that it will slow adoption,
> >>>>>>> >> >> whether
> >>>>>>> >> >> rightly or wrongly. I think we agree that we're ready to
> >>>>>>> >> >> encourage
> >>>>>>> >> >> adoption
> >>>>>>> >> >> of 3.0.
> >>>>>>> >> >>
> >>>>>>> >> >> John ZuHone
> >>>>>>> >> >> Laboratory for High-Energy Astrophysics
> >>>>>>> >> >> NASA/Goddard Space Flight Center
> >>>>>>> >> >> 8800 Greenbelt Rd., Mail Code 662
> >>>>>>> >> >> Greenbelt, MD 20771
> >>>>>>> >> >> (w) 301-286-2531
> >>>>>>> >> >> (m) 781-708-5004
> >>>>>>> >> >> john.zuhone at nasa.gov
> >>>>>>> >> >> jzuhone at gmail.com
> >>>>>>> >> >>
> >>>>>>> >> >> > On Jun 24, 2014, at 12:38 PM, Matthew Turk
> >>>>>>> >> >> > <matthewturk at gmail.com>
> >>>>>>> >> >> > wrote:
> >>>>>>> >> >> >
> >>>>>>> >> >> > I think Britton covered the halos, but the VR works as-is.
> >>>>>>> >> >> > As far as
> >>>>>>> >> >> > 3.0beta, I'm a bit nervous about that as we want to avoid
> the
> >>>>>>> >> >> > situation where we are in beta for 1+ years... I am worried
> >>>>>>> >> >> > about the
> >>>>>>> >> >> > perception of a "beta" tag.  Is that overblown?  Would
> >>>>>>> >> >> > calling it
> >>>>>>> >> >> > "yt-3.0-2014" work?
> >>>>>>> >> >> >
> >>>>>>> >> >> >> On Tue, Jun 24, 2014 at 10:32 AM, Nathan Goldbaum
> >>>>>>> >> >> >> <nathan12343 at gmail.com> wrote:
> >>>>>>> >> >> >> Do the old VR and halo interfaces work?  Not much effort
> has
> >>>>>>> >> >> >> gone
> >>>>>>> >> >> >> into
> >>>>>>> >> >> >> porting them, I think.
> >>>>>>> >> >> >>
> >>>>>>> >> >> >>
> >>>>>>> >> >> >>> On Tuesday, June 24, 2014, Sam Skillman
> >>>>>>> >> >> >>> <samskillman at gmail.com>
> >>>>>>> >> >> >>> wrote:
> >>>>>>> >> >> >>>
> >>>>>>> >> >> >>> I'm +1 on this, particularly since I'm at fault for not
> >>>>>>> >> >> >>> pushing on
> >>>>>>> >> >> >>> the
> >>>>>>> >> >> >>> VR
> >>>>>>> >> >> >>> as much as I'd like to.
> >>>>>>> >> >> >>>
> >>>>>>> >> >> >>>
> >>>>>>> >> >> >>> On Tue, Jun 24, 2014 at 7:44 AM, Matthew Turk
> >>>>>>> >> >> >>> <matthewturk at gmail.com>
> >>>>>>> >> >> >>> wrote:
> >>>>>>> >> >> >>>>
> >>>>>>> >> >> >>>> Hi all,
> >>>>>>> >> >> >>>>
> >>>>>>> >> >> >>>> One thing we really tried to do with 3.0 was break all
> the
> >>>>>>> >> >> >>>> APIs we
> >>>>>>> >> >> >>>> thought we'd need to before release.  This included
> things
> >>>>>>> >> >> >>>> like
> >>>>>>> >> >> >>>> ds/pf,
> >>>>>>> >> >> >>>> index/hierarchy, the way data selections were made, etc.
> >>>>>>> >> >> >>>>
> >>>>>>> >> >> >>>> It's starting to become clear that we are approaching
> >>>>>>> >> >> >>>> maturity at
> >>>>>>> >> >> >>>> different rates in these initiatives.  I am wondering if
> >>>>>>> >> >> >>>> perhaps
> >>>>>>> >> >> >>>> we
> >>>>>>> >> >> >>>> should de-couple the release from all of the API
> >>>>>>> >> >> >>>> breakages, and
> >>>>>>> >> >> >>>> instead note which interfaces we know are going to
> change
> >>>>>>> >> >> >>>> in the
> >>>>>>> >> >> >>>> future.
> >>>>>>> >> >> >>>>
> >>>>>>> >> >> >>>> Pragmatically, what this would mean is:
> >>>>>>> >> >> >>>>
> >>>>>>> >> >> >>>> * Release a 3.0 with the old VR and halo finding
> >>>>>>> >> >> >>>> interfaces
> >>>>>>> >> >> >>>> * Release a 3.1 with either the new VR or the new halo
> >>>>>>> >> >> >>>> finding (or
> >>>>>>> >> >> >>>> both)
> >>>>>>> >> >> >>>> * Do the same for 3.2
> >>>>>>> >> >> >>>>
> >>>>>>> >> >> >>>> This doesn't fit with the usual "major numbers are where
> >>>>>>> >> >> >>>> APIs
> >>>>>>> >> >> >>>> break"
> >>>>>>> >> >> >>>> philosophy that comes from semantic versioning, but I
> >>>>>>> >> >> >>>> think from
> >>>>>>> >> >> >>>> the
> >>>>>>> >> >> >>>> perspective of pragmatism, if we identify those sections
> >>>>>>> >> >> >>>> of the
> >>>>>>> >> >> >>>> code
> >>>>>>> >> >> >>>> that are *going* to change, and we pitch 3.0 as the
> first
> >>>>>>> >> >> >>>> part of
> >>>>>>> >> >> >>>> a
> >>>>>>> >> >> >>>> staged release of totally rewritten infrastructure, we
> can
> >>>>>>> >> >> >>>> likely
> >>>>>>> >> >> >>>> come
> >>>>>>> >> >> >>>> out okay.
> >>>>>>> >> >> >>>>
> >>>>>>> >> >> >>>> I'd like to put this out there for discussion.
> >>>>>>> >> >> >>>>
> >>>>>>> >> >> >>>> -Matt
> >>>>>>> >> >> >>>> _______________________________________________
> >>>>>>> >> >> >>>> yt-dev mailing list
> >>>>>>> >> >> >>>> yt-dev at lists.spacepope.org
> >>>>>>> >> >> >>>>
> >>>>>>> >> >> >>>>
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> >>>>>>> >> >> >>
> >>>>>>> >> >> >> _______________________________________________
> >>>>>>> >> >> >> yt-dev mailing list
> >>>>>>> >> >> >> yt-dev at lists.spacepope.org
> >>>>>>> >> >> >>
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> >>>>>>> >> >> > _______________________________________________
> >>>>>>> >> >> > yt-dev mailing list
> >>>>>>> >> >> > yt-dev at lists.spacepope.org
> >>>>>>> >> >> >
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> >>>>>>> >> >> _______________________________________________
> >>>>>>> >> >> yt-dev mailing list
> >>>>>>> >> >> yt-dev at lists.spacepope.org
> >>>>>>> >> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> > _______________________________________________
> >>>>>>> >> > yt-dev mailing list
> >>>>>>> >> > yt-dev at lists.spacepope.org
> >>>>>>> >> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> >>>>>>> >> >
> >>>>>>> >> _______________________________________________
> >>>>>>> >> yt-dev mailing list
> >>>>>>> >> yt-dev at lists.spacepope.org
> >>>>>>> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> >>>>>>> >
> >>>>>>> >
> >>>>>>> >
> >>>>>>> > _______________________________________________
> >>>>>>> > yt-dev mailing list
> >>>>>>> > yt-dev at lists.spacepope.org
> >>>>>>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> >>>>>>> >
> >>>>>>> _______________________________________________
> >>>>>>> yt-dev mailing list
> >>>>>>> yt-dev at lists.spacepope.org
> >>>>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> yt-dev mailing list
> >>>>>> yt-dev at lists.spacepope.org
> >>>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Cameron Hummels
> >>>>> Postdoctoral Researcher
> >>>>> Steward Observatory
> >>>>> University of Arizona
> >>>>> http://chummels.org
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> yt-dev mailing list
> >>>> yt-dev at lists.spacepope.org
> >>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Cameron Hummels
> >>> Postdoctoral Researcher
> >>> Steward Observatory
> >>> University of Arizona
> >>> http://chummels.org
> >>>
> >>> _______________________________________________
> >>> yt-dev mailing list
> >>> yt-dev at lists.spacepope.org
> >>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> >>>
> >>
> >>
> >> _______________________________________________
> >> yt-dev mailing list
> >> yt-dev at lists.spacepope.org
> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> >>
> >
> >
> >
> > --
> > Cameron Hummels
> > Postdoctoral Researcher
> > Steward Observatory
> > University of Arizona
> > http://chummels.org
> >
> > _______________________________________________
> > yt-dev mailing list
> > yt-dev at lists.spacepope.org
> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> >
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>



-- 
Cameron Hummels
Postdoctoral Researcher
Steward Observatory
University of Arizona
http://chummels.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20140625/9f6bd93d/attachment.htm>


More information about the yt-dev mailing list