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've just issued a big pull request that puts octrees (particle and
Eulerian) on a major diet. Comments, suggestions and test cases that
fail or pass would be welcomed!
https://bitbucket.org/yt_analysis/yt-3.0/pull-request/54/octree-diet/diff
I've laid out how things are now done, and I'd also be grateful to
hear about whether those ideas should be changed/improved/etc.
-Matt
Hello All,
At the yt sprint at SciPy 2013, I made a first attempt at building an *.h5m
(MOAB) file reader for yt using some data that Elliott Biondo sent me. You
can find the notebook here [1]. I think both the PyNE and yt folks would
be interested in this. I plan on turning this into a full-fledged yt
frontend.
Be Well
Anthony
1. https://hub.yt-project.org/nb/go5405
FYI: Since we import from the notebookapp, we will have to change
eventually, but we don't now since that construction is backwards
compatible.
---------- Forwarded message ----------
From: Paul Ivanov <pi(a)berkeley.edu>
Date: Fri, Jun 28, 2013 at 3:30 PM
Subject: [IPython-dev] frontend namespace flattened (major change)
To: IPython developers list <ipython-dev(a)scipy.org>
Hey everyone,
we've just landed PR #3450:
https://github.com/ipython/ipython/pull/3450
To quote Fernando:
> The basic idea is to move all the code we had in frontend and
> put it at the top, as recently discussed, and then to create
> a shim module capable of forwarding all `from
> IPython.frontend... import...` to their new locations.
Here's the rundown of name changes:
Old name -> New name
IPython.frontend.* -> IPython.*
IPython.frontend.html.notebook -> IPython.html
With only one exception, you do not have to make any immediate
changes to your code in order for it to continue working, but
will see deprecation warnings
The one exception is described by Min in a comment on the PR
which I am inlining here:
> The shim is a tiny bit more complicated now, since it's not
> just moving IPython.frontend.* to IPython.* anymore, as
> IPython.frontend.html.notebook became just IPython.html. A
> result of the extra shim is that there is one old import that
> doesn't work:
>
> from IPython.frontend.html import notebook
>
> but
>
> from IPython.frontend.html.notebook[.submod] import whatever
>
> works just fine.
One issue that we ran into that you should be sure to remove the
frontend/ directory, and clean up all .pyc files that may be
lying around. This command should do the trick:
rm -fr IPython/frontend; find -name \*.pyc -exec rm {} \;
best,
--
_
/ \
A* \^ -
,./ _.`\\ / \
/ ,--.S \/ \
/ `"~,_ \ \
__o ?
_ \<,_ /:\
--(_)/-(_)----.../ | \
--------------.......J
Paul Ivanov
http://pirsquared.org
_______________________________________________
IPython-dev mailing list
IPython-dev(a)scipy.org
http://mail.scipy.org/mailman/listinfo/ipython-dev
New issue 597: Autodetection of hdf5 library doesn't work on Linux
https://bitbucket.org/yt_analysis/yt/issue/597/autodetection-of-hdf5-librar…
Kacper Kowalik:
When `HDF5_DIR` is unset and `hdf5.cfg` doesn't exists, setup tries to autodetect hdf5 library by using `ctypes.util.find_library("hdf5")`. On Linux it returns only filename without leading path and thus rest of the code fails.
Responsible: xarthisius
New issue 596: yt command does not produce helpful output
https://bitbucket.org/yt_analysis/yt/issue/596/yt-command-does-not-produce-…
Matthew Turk:
Currently, simply running "yt" indicates that something has gone wrong. This is actually not the case, and we should default to having a help output. This may be tricky to implement with argparse but can likely be done.
Responsible: MatthewTurk
Hi all,
I've issued a pull request to change the release schedule of 2.6.
https://bitbucket.org/yt_analysis/ytep/pull-request/18/proposed-change-to-r…
There are two motivations for this -- the first is that I wanted to
get the Boxlib stuff and Cython kD-tree included by 2.6, but I don't
think we will have time between now and July 1 to finish, review and
test these changes. The other is that in the old release schedule I
was set to be the coordinator for 2.6.1 on August 1st, but I am
somewhat skeptical I'll be able to do so. So someone else will be set
up to be release coordinator for 2.6 and handle pushing it out on
August 1st.
This would give the entire month of July to finish up Boxlib / Cython
kD-tree, but still retain a 2.5.4 (new) release on July 1, to include
changes since 2.5.3.
Please feel free to click "Approve" on the PR if you are okay with
this, and if you're not, either reply here to leave a comment.
-Matt
New issue 595: Quad Projection assumes cubical domains
https://bitbucket.org/yt_analysis/yt/issue/595/quad-projection-assumes-cubi…
J.S. Oishi:
It looks like dx and dy are always set identical to each other. This should be an easy fix, we just need a dxs and a dys in the array creation
Responsible: jsoishi
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
