[yt-dev] yt-dev Digest, Vol 66, Issue 43

Hilary Egan hilaryye at gmail.com
Wed Jun 25 09:00:40 PDT 2014 

I can help fix the halo docs. I had started going through the old pages the
last time I was working on this but got waylaid by traveling. I've got a
bit of time now though!

-Hilary


>
> Message: 1
> Date: Wed, 25 Jun 2014 08:42:53 -0700
> From: Nathan Goldbaum <nathan12343 at gmail.com>
> To: "yt-dev at lists.spacepope.org" <yt-dev at lists.spacepope.org>
> Subject: Re: [yt-dev] RFC: Staggered deprecation through 3.1 and 3.2
> Message-ID:
>         <
> CAJXewOksXTNE349-+8wkBR56oMqK+viX60iMYwS18quVCcuTLw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> There are still some vestiges of the old halo machinery in the docs.
>  Britton, do you think you'd be up for looking over the halo analysis docs
> and updating it where necessary?  I'm specifically referring to some of the
> errors and warnings in the docs build, (see
> http://tests.yt-project.org/job/yt-docs-3.0/lastSuccessfulBuild/consoleFull
> ,
> search for "halo") but it probably also deserves a full proofread.
>
> I haven't felt comfortable touching the halo finding docs since I'm not
> familiar with any of the halo analysis code.
>
> On Wednesday, June 25, 2014, Britton Smith <brittonsmith at gmail.com> wrote:
>
> > Getting all the cookbook recipes working is absolutely a blocker for 3.0.
> >  I think we're all in agreement on that.  Someone should correct me if
> I'm
> > wrong, but all of the existing recipes can and will be made to work by
> > porting existing functionality to yt-3.0.  This mostly involves adopting
> > the various newisms, units, field names, etc.  We will not release yt-3.0
> > with broken functionality.  This is doable on a relatively short
> timescale
> > I think.  However, the new VR machinery will not be ready for a bit
> longer,
> > so I think it's ok for that to come in 3.1.
> >
> > As far as halos are concerned, here's the status there:
> > - halo_analysis completely replaces the HaloProfiler.  The halo_analysis
> > functionality is fully documented (Thanks Hilary!) and the HaloProfiler
> has
> > been removed from the source and the docs.
> > - all halo finders have been ported and are now compliant with
> > halo_analysis (Thanks again to Hilary).
> > - HaloCatalogTimeSeries is a ways off and will need to be pushed to 3.1
> or
> > 3.2.  This is functionality that never existed anywhere, so that's fine.
> > - the other cards on the halo_analysis board are minor enhancements, not
> > blockers
> > - the halo mass function is almost ready and has an open PR that just
> > needs a few things cleaned up and it's ready.
> > - the big thing we are missing is a merger tree as neither of the old
> ones
> > were ported.  The idea is for them to work with the halo_analysis and
> > HaloCatalogTimeSeries, which will probably require work akin to a
> redesign.
> >  For this reason, this will probably need to wait until 3.1.
> >
> > Britton
> >
> >
> > On Wed, Jun 25, 2014 at 2:35 AM, Cameron Hummels <chummels at gmail.com
> > <javascript:_e(%7B%7D,'cvml','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
> >>
> >> * 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
> >>
> >> * Units working with everything in yt (Nathan Goldbaum, Matt Turk, John
> >> Zuhone)
> >> ----hse_field.py
> >> ----simple_off_axis_projection.py
> >>
> >> * 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.
> >>
> >>
> >> 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
> >> <javascript:_e(%7B%7D,'cvml','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
> >>> <javascript:_e(%7B%7D,'cvml','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
> >>>> <javascript:_e(%7B%7D,'cvml','nathan12343 at gmail.com');>> wrote:
> >>>>
> >>>>>
> >>>>>
> >>>>> On Tuesday, June 24, 2014, Cameron Hummels <chummels at gmail.com
> >>>>> <javascript:_e(%7B%7D,'cvml','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
> >>>>> <javascript:_e(%7B%7D,'cvml','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
> >>>> <javascript:_e(%7B%7D,'cvml','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
> >>> <javascript:_e(%7B%7D,'cvml','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
> >> <javascript:_e(%7B%7D,'cvml','yt-dev at lists.spacepope.org');>
> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> >>
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20140625/fe91d694/attachment.htm>

More information about the yt-dev mailing list