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

Matthew Turk matthewturk at gmail.com
Wed Jun 25 12:18:08 PDT 2014 

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
>

More information about the yt-dev mailing list