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
Hi all,
One of the things that came out of the yt strategy meeting last week was a
discussion of reorganizing how the YTEPs are listed. Currently, it looks
like this:
http://ytep.readthedocs.org/en/latest/
There are essentially two problems with this. First, once a YTEP is
accepted, it is difficult to tell the status of the actual enhancement that
was proposed. Is it being implemented? Is it done? Second, because we
are doing revisions in PRs, there is no listing of unaccepted YTEPs.
For comparison, here is the enhancement proposal index for python:
http://www.python.org/dev/peps/
They have categories for types (standards, information, and process) and
status (accepted, rejected, withdrawn, draft, etc.). This may be slightly
overkill for us since we are only on YTEP 14 and they have hundreds. I
still think some organization would be helpful. I will have a go at that
and issue a PR.
The question I have for people is with regard to process. In order to have
statuses for the unaccepted proposals, they have to exist in some fashion
in the main repo. How do we want to do that? Or do we want to do that?
One way would be to issue a PR that would include adding it to the index as
Draft status and have it be accepted quickly. People can still leave
comments on a merged PR and the author can then issue a new one which moves
the listing to the accepted status.
I'd really like to hear people's thoughts about this. Even if we don't
adopt the above strategy, I'd still like to organize the accepted YTEPs as
implemented and not implemented so people can get a better idea of where
they might get involved.
Britton
Hi all,
Casey Stark and I are planning on sprinting on the yt-3.0 units refactor next Thursday and Friday in Berkeley. If anyone is interested in joining (even remotely), let us know so we can keep you in the loop.
-Nathan
New issue 557: Hardcoded values are used in several places in the code
https://bitbucket.org/yt_analysis/yt/issue/557/hardcoded-values-are-used-in…
Kacper Kowalik:
Several physical constants are defined across multiple places in the code. As an example:
```
#!bash
$ grep '1\.98' -r
analysis_modules/halo_finding/halo_objects.py: #Jc = 1.98892e33/pf['mpchcm']*1e5
analysis_modules/halo_profiler/multi_halo_profiler.py: Msun2g = 1.989e33
utilities/units.py: "Msun": (1.98892e33, mass),
utilities/tests/test_units.py: msun_cgs = 1.98892e33
utilities/tests/test_units.py: Msun_cgs = 1.98892e33
utilities/physical_constants.py:mass_sun_cgs = 1.98841586e33 # g
frontends/nyx/fields.py: return (1/1.989e33)
frontends/nyx/data_structures.py: self.units["particle_mass"] = 1.989e33
frontends/flash/fields.py: return 1.0/1.989e33
frontends/art/data_structures.py: cf["Mass"] = aM0 * 1.98892e33
frontends/castro/fields.py: return 1.0 / 1.989e33
frontends/castro/data_structures.py: self.units['particle_mass'] = 1.989e33 ### TODO: Make a global solar mass def
frontends/enzo/fields.py: return data.convert("Density")*((data.convert("cm")**3.0)/1.989e33)
frontends/ramses/fields.py: return data.convert("Density")*((data.convert("cm")**3.0)/1.989e33)
data_objects/universal_fields.py: (3/(4*3.1415926535897931))**(0.5) / 1.989e33
data_objects/derived_quantities.py: spin = J * E / (M*1.989e33*G)
```
Instead constants should be imported from `yt.physical_constants` everywhere for the sake of consistency.
Responsible: xarthisius
New issue 556: Volume Rendering in curvilinear coordinates
https://bitbucket.org/yt_analysis/yt/issue/556/volume-rendering-in-curvilin…
Kacper Kowalik:
Initial work for supporting curvilinear coordinates has been done in yt-3.0 branch. Currently working single-ray tracer could be extended into full VR support
Hi all,
Inspired by Kacper in IRC, I've added the "Project Ideas" milestone to
the issue tracker. I think this is a good place to collect ideas for
"bite sized" things that can be done, or things for new contributors,
and so on. During the meeting last week we came up with this as a
place to lower the barrier to entry for new contributors. So if you
have an idea for something that would be good for a new contributor,
assign it to the milestone "Project Ideas". I'm also kind of -1 on
removing the non-versioned, non-ProjectIdeas milestones that are in
there like "GDF Support" and so on.
Also, once I get a few more roundtuits, I'm going to be working on
making the website be a bit easier to navigate, consolidating some
stuff. I recognize that it's gotten out of control with too many
places to go, decide on, etc etc.
-Matt
Hi folks,
Over at YTEP-0013<https://bitbucket.org/yt_analysis/ytep/pull-request/15/ytep-0013-first-clas…>
we've been having vigorous discussion over particle deposition. Concrete
suggestions have given way to more freeform brainstorming (something I'm
quite guilty of too) and it's too much to synthesize at once. Matt has
suggested, and I agree, that we would be better off hashing this out in a
google hangout.
If you're interested, please respond on the doodle poll for WThF of next
week. Ideally, I would like to see at least the people who've reviewed
YTEP-0013 to participate; if these times don't work out for y'all, we can
move around the times. I'll prepare some use cases and material that we can
go over.
http://www.doodle.com/nc8p92zy469t63te
Many thanks,
chris
Hi all,
Here're the notes from the meeting:
https://docs.google.com/document/d/1qlcJp5tzx3ha-frQvOU2VEyWhGlYnBO9V-Uq_0T…
Other people can chime in, but there are action items at the bottom.
I think this was extremely useful. We did discuss that we should try
to aim for these roughly every three months or so. I would like to
suggest we have the next one around the middle of July, maybe the 18th
or so, but I'll be in touch closer to the date to set that up.
We also discussed that these should be held "on air" which will record
them and then upload them to YouTube, since at this one we had at
least four more people that *wanted* to attend than *could* attend.
Having them on air also means people can watch without being directly
on camera.
A few big takeaways: the YTEPs are mostly moving forward nicely, and
we're looking at ways of fixing up our online presence somewhat that
include spreading out into other media and consolidating a few places
as well.
Any other feedback would be welcomed.
-Matt
