Hi all,
I'd like to call a brief, approximately one hour, strategy meeting on
Monday, April 22nd at 3PM Eastern. This will cover where yt is at,
where we can go, and how things are progressing. Some of this will be
dedicated to progress updates (from me and others) as well as
soliciting feedback on a number of things. Many other projects --
notably Cactus -- do these on a fixed schedule, so based on the
success/failure of this one we can consider having them
semi-regularly.
The agenda I would like to cover will include:
* yt 3.0 status, including near/long term plans for development and
support for non-grid codes
* Rundown of all YTEPs accepted and outstanding
* yt's "presence" on the web
* 3.0 paper
I will also be soliciting feedback in roundtable style on:
* How are we doing?
* How is the procedure for code contributions working?
* How is the yt "infrastructure" meeting people's needs? (Mailing
lists, Bitbucket, etc)
* Where are energies being spent that could be better spent elsewhere?
If you have either agenda items or discussion items, please reply to
this email and suggest them.
I think having a large presence at this meeting would be very useful,
so if you are able to make it, please try to do so. It'll be held as
a google hangout, and I'll send details here when it starts up. If
there's a pressing need to reschedule, please write in reply to this
email.
Thanks, and looking forward to seeing you there,
Matt

Hi all,
Mark Richardson wrote to the yt_analysis project with a problem with
clumps on FLASH datasets. Here's his email:
"Below includes my script and the output (it wouldn't let me attach
two files). I get some output in the clump file up until I'd expect to
see the Jeans Mass dumped. The output makes me think that it can't
calculate this point because Gamma is unknown, or some other essential
variable needed to get the number density. I've attempted to change
the data_structure.py frontend for Flash to alias Gamma to gamc and
game but I still get the 'cannot find Gamma' when loading my dataset."
The issue from the traceback is that JeansMassMsun requires
MeanMolecularWeight which needs NumberDensity. This can't be
generated for his data.
I am not an expert on FLASH, but it seems that this should be
straightforward to fix, I just don't know how. Anybody from the FLASH
or Clump side have any ideas?
-Matt

Hi all,
I'd like to turn off serialization by default. This includes:
1) Projections
2) Grid hierarchy
3) Field lists
and maybe other things. In general, I think it's a bad idea to just
litter directories with new files, and specifically I think it's a bad
idea to store 2&3 since they are a huge source of errors for new and
existing users.
My preference would be to disable all auto-serialization of anything
and make that not possible, mandating explicit, manual saves of data
instead. However I recognize that is likely unpopular, as even though
my simulations have a lot of data on disk, I know that they also take
a relatively short time to project.
So when can we make it disabled-by-default? 2.6? 3.0? Now?
-Matt

New issue 582: HaloMassFunction uses Enzo ComovingBoxSize
https://bitbucket.org/yt_analysis/yt/issue/582/halomassfunction-uses-enzo...
Matthew Turk:
(reported by @mepa )
Inside `yt/analysis_modules/halo_mass_function/halo_mass_function.py` on line 215, there's a reference to `self.pf["ComovingBoxSize"]`. I believe this is then converted into actual Mpc, not Mpc/h, and is then cubed to get the volume of the domain.
I am not entirely certain, but I believe this could be replaced either by:
`(self.pf.domain_width * self.pf["mpccm"]).prod()`
or:
`(self.pf.domain_width * self.pf["mpc"]).prod()`
depending on whether the mass function is supposed to be proper or comoving; the comments in the code suggest to me very strongly it's the first of the two, not the second.
@brittonsmith I am tagging you in the ticket, but if you aren't able to take a look at this feel free to re-assign to me.
Responsible: brittonsmith

Hi all,
It looks like redefinition of the TotalMass field has caused a couple of answer tests to change for the galaxy0030 dataset. See the test reports on Piernik:
http://piernik.astri.umk.pl:8080/job/py2.7-yt-2.x_testing/http://piernik.astri.umk.pl:8080/view/yt-2.x/job/py2.7-yt-2.x_answer.enzo...
I don't think this is particularly surprising given that the TotalMass field now properly includes star particles. However, given the number of enzo/yt users out there, it might be worthwhile to make a somewhat bigger deal about this change.
I'm happy to upload a new set of answer test results and issue a pull request for the update. I'll try to get that done tonight.
-Nathan

New issue 579: Plot window modifying functions need to be documented better.
https://bitbucket.org/yt_analysis/yt/issue/579/plot-window-modifying-func...
Nathan Goldbaum:
We should add narrative docs for the plot window modifying functions (e.g. `set_zlim`, `set_log`, `zoom`, `pan`) to the page that covers the plot callbacks.
Since `PlotCollection` is still usable but deprecated for image plotting, we could also give the full names for the callbacks (`annotate_<callback>`) rather than the shortened name.
Responsible: ngoldbaum

Hi all,
Just a reminder that next Saturday we're scheduled to put out bugfix
for 2.X, which will be 2.5.3, and a second alpha of yt 3.0. I'll
probably roll these up either Friday night or the following Monday
morning. So if you have any changes you'd like to get in, let's aim
to have them PR'd by Wednesday or so, and I think we should freeze
non-critical fixes after that.
2.5.3 will have a number of minor improvements, but I think we'll
probably wait until after it goes out to merge in the Boxlib
consolidation, even if that gets finished.
The 3.0 alpha will include a ton of improvements to Octree stuff, as
well as preliminary particle deposition. This means Tipsy & Gadget
will have the most basic of support. RAMSES has had a number of
improvements to its IO and units. For the third alpha (July 15) I'd
like to target units, the "global mesh" issue, and perhaps SPH
smoothing kernels.
-Matt