python source distro for HPC

[Chris Kees]

Hi,

We have an ongoing group discussion within my organization about how
to unify the various python distributions we're using for the
supercomputers. Are most mpi4py users building their own python
interpreters and installing mpi4py into it on production HPC systems
or is their some consensus forming on a scientific python distribution
appropriate for HPC?

Thanks,
Chris

[Matthew Turk]

Hi Chris,

For what it's worth, our code (astrophysics analysis) provides an
installation script which builds the entire stack of dependencies,
which is how most users get it -- and we include notes about which
modules to load on different common SC centers. Recently, a few SC
centers have been building modules for it, but that's still in
process. We are still working on integrating mpi4py into the build
script, but that's part of a harder-than-just-mpi4py problem.

-Matt

> --
> You received this message because you are subscribed to the Google Groups "mpi4py" group.
> To post to this group, send email to mpi...@googlegroups.com.
> To unsubscribe from this group, send email to mpi4py+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/mpi4py?hl=en.
>
>

[Aron Ahmadia]

Chris,

I have not seen a lot of Python momentum at the supercomputer level.  The chief BlueGene/P applications are split 50%, GPAW uses their own embedded application within a Python interpreter and PyClaw uses the vanilla Python interpreter provided by IBM (effectively a cross-compiled 2.6).

A

[Chris Kees]

Hi Matt and Aron,

We do a variant of what Matt described, and I only just started to see some demand for this at a recent DoD HPC conference where we inserted a Python BOF at the last minute.  In thinking this over and talking with Ondrej Certik (who has his own Qsnake distro), I decided to go ahead an post something to the sage list to see if there is interest among a subset of sage users. Here is the post in case not many mpi4py users follow sage-support:

posted to sage-support:

---------------------------------

Hi,

Apologies in advance for the long post. It boils down to this: Is there any interest from the sage community in participating in the development of a python distribution for large-scale distributed memory parallel machines?  I'm posting this on behalf of (but not representing) a group of government scientists  who are trying to work toward a common python distribution on the government systems we use.   The reasons we're doing this are 1) we can't trust the system python on many HPC systems if it even exists; 2) Due to 1. almost all of us spend too much time building and maintaining our own python "stack" based on some mixture of make, cmake, autoconf, and/or the sage spkg system; and 3)  our community suffers from the fact that we can't always share python modules and scripts on these systems because we're not  working from equivalent python environments.

Here's what I think we need:

1) A standard, which specifies a python version, and a list of python packages and their dependent packages. This allows for-profit vendors to build to our standard.

2) A build system that allows extensive configuration of the entire system but with enough granularity that the format of a package is standardized and relatively straightforward. On the other hand, the whole system must be designed such that it can be built repeatedly from scratch without any interactive steps.

3) A testing system that is simple enough that the community can easily contribute tests to ensure that the community python is reliable for their needs

4) A framework for making this environment extensible without requiring forking it and creating yet more distributions

Here's a straw man:

1) Standard:

Python 2.7.2  PLUS:

numpy *
scipy
matplotlib *
vtk (python wrappers + C++ libs) *
elementtree *
ctypes *
readline (i.e. a functional readline extension module) *
swig
mpi4py *
petsc4py *
pympi
nose *
pytables *
basemap
cython *
sympy *
pycuda
pyopencl
IPython *
wxpython
PyQt  *
pygtk
PyTrilinos
virtualenv *
• Pandas
• numexpr *
• pygrib

Note:

*Our group has these in the python stack we build for our PDE solver framework (http://proteus.usace.army.mil), which we build on a range of machines at 4 major supercomputing centers. 

The main issue I see with 1) is that this is somewhat different from the sage package list. We would need many optional sage packages but wouldn't need some of the standard sage packages.

2) Build System: 

a. Use cmake* for the top level configuration, storing the part relevant for each package in a subdirectory for each package (call it package_name_Config e.g. numpyConfig, petsc4pyConfig, ...)

b. store each package as an spkg** that meets sage community standards except that spkg-install will rely on information from package_name_Config (maybe it would be OK to edit files in package_name_Config located INSIDE package_name_version.spkg during the interactive configuration step?)  

c. each package will still get built with it's native built system***

Notes:

*Our group simply uses make instead of cmake, with a top level Makefile containing 'editConfig' and 'newConfig' targets that allows you to edit and copy existing configurations

**Our group only produces a top level spkg, but I think we could easily generate a finer grained set of spkg's for ones that don't already exist

***Our group does this (i.e. we don't rewrite upstream build systems).  I think spkg's also use the native build system in most cases, right?

The main issue  with 2. (the build system) is that building on HPC systems requires extensive configuration of individual packages: numpy needs to get built with the right vendor blas/lapack and potentially the correct, non-gcc, optimizing compilers (maybe even a mixture of gcc and some vendor fortran). Likewise petsc4py might need to use PETSc libraries installed as part of the HPC baseline configuration rather than building the source included with this distribution. My impression is that sage very reasonably opted to focus on the web notebook and a gnu-based linux environment so the spkg system alone doesn't fully meet the needs of the HPC community. We need the ability to specify different compilers for different packages and to do a range of things from building every dependency to building only python wrappers for many dependencies.

3) buildbot + nose and a package_nameTest directory for community supplied tests of each package in addition to the packages' own tests. This way users only have to add test_NAME.py files to 

4) virtualenv + pip should allow users to extend the python installation into a their private environment where they can update and add new packages as necessary.  An issue here is that it wouldn't allow a per-user sage environment so I'm not sure whether users could also install spkg's or even use their modified python environment from sage.

Anyway, I'd be grateful for any input, regardless of whether this project seems like a good fit for more formal participation from the sage community.

Thanks,

Chris

[Aron Ahmadia]

Hi Chris,

This is an interesting, ambitious proposal.  I am cc'ing the PyClaw developer's list (PyClaw developers, if you wish to respond, please reply to the mpi4py mailing list, though perhaps we need an hpc-p...@googlegroups.com mailing list to discuss these umbrella issues?)

I have to admit that I am new to the Python HPC community, so although I have a lot of ideas, I'm sure you've heard or seen most of them before.  I list them here mostly for completion in my own mind, but I'm happy to hear feedback on what has already been done or tried:

[1/2/4] I agree that that maintaining a common build system or requiring a specific Python version will be a headache on all but the most generic of systems: Linux + x86_64+gfortran.  I like to think that SiCortex was doomed when a series of clients pestered them to get SciPy ported to their MIPS processors :)

I love virtualenv/pip, and I think that HPC centers should move more towards a 'toolchain' approach rather than the current 'module' system, which makes the fundamentally bad assumption that it is easy to mix and match various libraries and build settings.  

One thing that the Python community fundamentally gets wrong is the lack of support for building complicated extension modules.  f2py/numpy do their best to unify this process, but just about every tool has their own slightly wonky way of getting packages/extensions built.  We might be able to do the most good for the community by providing and enforcing a robust BuildSystem that deeply understands compiling and linking in a cross-platform way.  Failing that, I would support the idea of a community maintained set of CMake configuration files for building Python packages, but we should make a strong effort encourage the package maintainers to support the CMake build.

[3] I really like the idea of a testing framework, and a community standard for tests that we write that must pass on a machine for it to be considered 'working'.  We have a set of 20 application tests (using nose) in the PyClaw framework specifically for verifying that we have a working environment.  

It is more important to settle on a standard/goal for how to incorporate a package and verify it than it is to come up with a definitive list of must-supported packages.  PyCUDA and PyOpenCL, for example, only make sense in environments where the two frameworks are supported.  Similarly, there is a subset of interactive visualization-oriented packages that would only make sense to deploy on interactive/visualization nodes.  I would suggest then that we come up with a standard for listing packages that are of potential interest to a Python HPC center accompanied by a series of tests that must pass for us to consider the package working.  

In the ideal case, the package already has a testing framework, and we work with the package maintainers to coordinate a common testing strategy.  Perhaps we can require (or provide) a nose interface to all packages, and a specific attribute to define the core 'HPC Python tests'.  

Similar to the regression tests, we might also want to eventually specify rules for performance benchmarks in Python, similar to the SPEC HPC2002 benchmark.  A unified scoring scheme for the usual targets from Python (memory bandwidth, floating-point and integer performance, disk/network i/o) is probably beyond the scope of a first proposal, but we should leave room for it later.

Thanks for kicking this off Chris.

Warm Regards,

Aron

--

You received this message because you are subscribed to the Google Groups "mpi4py" group.

To view this discussion on the web visit https://groups.google.com/d/msg/mpi4py/-/liLLZcu8dzAJ.

[Dag Sverre Seljebotn]

Great discussion.

I think Nix (http://nixos.org) is *perfect* for clusters, but need some
work and customization to become easy enough to use.

My own thoughts on this are at

https://github.com/dagss/scidist/blob/master/ideas.rst

Since there seems like there's a lot of interest for this, how about a
BoF/Skype session/etc.?

On 09/19/2011 07:51 AM, Aron Ahmadia wrote:
> Hi Chris,
>
> This is an interesting, ambitious proposal. I am cc'ing the PyClaw
> developer's list (PyClaw developers, if you wish to respond, please
> reply to the mpi4py mailing list, though perhaps we need an

> hpc-p...@googlegroups.com <mailto:hpc-p...@googlegroups.com> mailing

> list to discuss these umbrella issues?)
>
> I have to admit that I am new to the Python HPC community, so although I
> have a lot of ideas, I'm sure you've heard or seen most of them before.
> I list them here mostly for completion in my own mind, but I'm happy
> to hear feedback on what has already been done or tried:
>
> [1/2/4] I agree that that maintaining a common build system or requiring
> a specific Python version will be a headache on all but the most generic
> of systems: Linux + x86_64+gfortran. I like to think that SiCortex was
> doomed when a series of clients pestered them to get SciPy ported to
> their MIPS processors :)
>
> I love virtualenv/pip, and I think that HPC centers should move more
> towards a 'toolchain' approach rather than the current 'module' system,
> which makes the fundamentally bad assumption that it is easy to mix and
> match various libraries and build settings.
>
> One thing that the Python community fundamentally gets wrong is the lack
> of support for building complicated extension modules. f2py/numpy do
> their best to unify this process, but just about every tool has their
> own slightly wonky way of getting packages/extensions built. We might
> be able to do the most good for the community by providing and enforcing
> a robust BuildSystem that deeply understands compiling and linking in a
> cross-platform way. Failing that, I would support the idea of a
> community maintained set of CMake configuration files for building
> Python packages, but we should make a strong effort encourage the
> package maintainers to support the CMake build.

There's also waf. I now use waf for building all my Cython + C + Fortran
projects. And David Cournapeau has put a lot of work into Bento, which
is intended to "fix" the packaging situation so that you can have a
proper Python egg package but doing the build using waf (or, in time,
CMake).

Dag Sverre

[Aron Ahmadia]

Dag,

Since there seems like there's a lot of interest for this, how about a BoF/Skype session/etc.?

Please count me in.  Perhaps a first step would be start a new Google group for discussing Python+HPC related issues in general, instead of piggybacking off of the mpi4py mailing list?

Aron 

On Mon, Sep 19, 2011 at 12:57 PM, Dag Sverre Seljebotn <d.s.se...@astro.uio.no> wrote:

Great discussion.

I think Nix (http://nixos.org) is *perfect* for clusters, but need some work and customization to become easy enough to use.

My own thoughts on this are at

https://github.com/dagss/scidist/blob/master/ideas.rst

Since there seems like there's a lot of interest for this, how about a BoF/Skype session/etc.?

On 09/19/2011 07:51 AM, Aron Ahmadia wrote:

Hi Chris,

This is an interesting, ambitious proposal.  I am cc'ing the PyClaw
developer's list (PyClaw developers, if you wish to respond, please
reply to the mpi4py mailing list, though perhaps we need an

hpc-p...@googlegroups.com <mailto:hpc-python@googlegroups.com> mailing

--
You received this message because you are subscribed to the Google Groups "mpi4py" group.

To post to this group, send email to mpi...@googlegroups.com.

To unsubscribe from this group, send email to mpi4py+unsubscribe@googlegroups.com.

[Matthew Turk]

There is python-hpc:

http://mail.python.org/mailman/listinfo/python-hpc

-Matt

On Mon, Sep 19, 2011 at 6:50 AM, Aron Ahmadia <ar...@ahmadia.net> wrote:
> Dag,
> Since there seems like there's a lot of interest for this, how about a
> BoF/Skype session/etc.?
> Please count me in.  Perhaps a first step would be start a new Google group
> for discussing Python+HPC related issues in general, instead of piggybacking
> off of the mpi4py mailing list?
> Aron
> On Mon, Sep 19, 2011 at 12:57 PM, Dag Sverre Seljebotn
> <d.s.se...@astro.uio.no> wrote:
>>
>> Great discussion.
>>
>> I think Nix (http://nixos.org) is *perfect* for clusters, but need some
>> work and customization to become easy enough to use.
>>
>> My own thoughts on this are at
>>
>> https://github.com/dagss/scidist/blob/master/ideas.rst
>>
>> Since there seems like there's a lot of interest for this, how about a
>> BoF/Skype session/etc.?
>>
>> On 09/19/2011 07:51 AM, Aron Ahmadia wrote:
>>>
>>> Hi Chris,
>>>
>>> This is an interesting, ambitious proposal.  I am cc'ing the PyClaw
>>> developer's list (PyClaw developers, if you wish to respond, please
>>> reply to the mpi4py mailing list, though perhaps we need an

>>> hpc-p...@googlegroups.com <mailto:hpc-p...@googlegroups.com> mailing

>> mpi4py+un...@googlegroups.com.

>> For more options, visit this group at
>> http://groups.google.com/group/mpi4py?hl=en.
>>
>

> --
> You received this message because you are subscribed to the Google Groups
> "mpi4py" group.
> To post to this group, send email to mpi...@googlegroups.com.
> To unsubscribe from this group, send email to

> mpi4py+un...@googlegroups.com.

[Chris Kees]

Count me in for the skype session! I can probably get some other guys
who build their own python distribution to join the call.

I'm also fine with switching this to the python-hpc mailing list as
well. I need to join it and am not sure it is really being used all
that much. Does anybody know Andreas Schreiber (the python-phc list
maintainer)?

Chris

[Dag Sverre Seljebotn]

Hmm. There's actually a lot to synchronize here for a good discussion.
I've participated in numerous similar discussions in the past
(sage-devel etc.). I wonder if things are a bit too much in flux for a
Skype session -- there's many parties/people who are interested in
having this problem solved, there's been *a lot* of prior discussion
without any obvious full solutions.

How about trying to have something like a "structured discussion"?
Otherwise we derail into a 500-post long thread that leads nowhere?

Blogs are great for this as they create an asymmetry between blog posts
and comments, and allows editing posts after the fact.

So here's my proposal:

a) scientificcodedistribution.blogspot.com is created

b) We announce to others (numpy-discussion, sage-devel) that we're
going to have a "roundtable" (is that what it is called?) about "Finally
solving the scientific Python software building & distribution issues".

c) Each participant writes one blog post containing:

- Introduce yourself

- What kind of hardware are you using? What kind of computations do
you perform?

- What one has tried; what approaches have you used and are you using,
and what are their weaknesses

- What way do you see forward? How much time and other resources do
you have to spare to make things happen?

If more people than me promise to follow up with such a blog post I'm
happy to start the ball. Tell me what you think :-)

I believe *really* getting forward demands a workshop in the end. But we
just had another baby, so unless we can do it in Oslo, I may well not be
able to attend such a thing...

Dag Sverre

[Aron Ahmadia]

Dag,

You have my support.  I can definitely introduce our challenges at the KAUST Supercomputing Laboratory in a contribution to the blog/github repository/newsletter :)

A

PS - I am happy to visit Norway :)

hpc-p...@googlegroups.com<mailto:hpc-python@googlegroups.com>  mailing

mpi4py+unsubscribe@googlegroups.com.

For more options, visit this group at
http://groups.google.com/group/mpi4py?hl=en.

--
You received this message because you are subscribed to the Google Groups
"mpi4py" group.
To post to this group, send email to mpi...@googlegroups.com.
To unsubscribe from this group, send email to

mpi4py+unsubscribe@googlegroups.com.

For more options, visit this group at
http://groups.google.com/group/mpi4py?hl=en.

--
You received this message because you are subscribed to the Google Groups "mpi4py" group.
To post to this group, send email to mpi...@googlegroups.com.

To unsubscribe from this group, send email to mpi4py+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/mpi4py?hl=en.

--
You received this message because you are subscribed to the Google Groups "mpi4py" group.
To post to this group, send email to mpi...@googlegroups.com.

To unsubscribe from this group, send email to mpi4py+unsubscribe@googlegroups.com.

[Matthew Turk]

On Mon, Sep 19, 2011 at 3:40 PM, Aron Ahmadia <ar...@ahmadia.net> wrote:
> Dag,

> You have my support.  I can definitely introduce our challenges at the KAUST
> Supercomputing Laboratory in a contribution to the blog/github
> repository/newsletter :)
> A
> PS - I am happy to visit Norway :)

I'd be interested in sharing as well.

For what it's worth, several members of our group will be attending
the PyHPC session at SC11, and I could likely organize a small
workshop in NYC. I don't think [m]any of us could manage a trip to
Oslo.

-Matt

>>>>>>> hpc-p...@googlegroups.com<mailto:hpc-p...@googlegroups.com>

>>>>>> mpi4py+un...@googlegroups.com.

>>>>>> For more options, visit this group at
>>>>>> http://groups.google.com/group/mpi4py?hl=en.
>>>>>>
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups
>>>>> "mpi4py" group.
>>>>> To post to this group, send email to mpi...@googlegroups.com.
>>>>> To unsubscribe from this group, send email to

>>>>> mpi4py+un...@googlegroups.com.

>>>>> For more options, visit this group at
>>>>> http://groups.google.com/group/mpi4py?hl=en.
>>>>>
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "mpi4py" group.
>>>> To post to this group, send email to mpi...@googlegroups.com.
>>>> To unsubscribe from this group, send email to

>>>> mpi4py+un...@googlegroups.com.

>>>> For more options, visit this group at
>>>> http://groups.google.com/group/mpi4py?hl=en.
>>>>
>>>>
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "mpi4py" group.
>> To post to this group, send email to mpi...@googlegroups.com.
>> To unsubscribe from this group, send email to

>> mpi4py+un...@googlegroups.com.

>> For more options, visit this group at
>> http://groups.google.com/group/mpi4py?hl=en.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "mpi4py" group.
> To post to this group, send email to mpi...@googlegroups.com.
> To unsubscribe from this group, send email to

> mpi4py+un...@googlegroups.com.

[Dag Sverre Seljebotn]

On 09/19/2011 09:43 PM, Matthew Turk wrote:
> On Mon, Sep 19, 2011 at 3:40 PM, Aron Ahmadia<ar...@ahmadia.net> wrote:
>> Dag,
>> You have my support. I can definitely introduce our challenges at the KAUST
>> Supercomputing Laboratory in a contribution to the blog/github
>> repository/newsletter :)
>> A
>> PS - I am happy to visit Norway :)
>
> I'd be interested in sharing as well.
>
> For what it's worth, several members of our group will be attending
> the PyHPC session at SC11, and I could likely organize a small
> workshop in NYC. I don't think [m]any of us could manage a trip to
> Oslo.

I think PyHPC (or in conjunction) sounds like a great idea. Also it's
close to a lot of Sage people.

I'll try to kick off the blog tomorrow and post some invitations.

Dag Sverre

>
> -Matt
>
>>
>> On Mon, Sep 19, 2011 at 9:53 PM, Dag Sverre Seljebotn
>> <d.s.se...@astro.uio.no> wrote:
>>>
>>> Hmm. There's actually a lot to synchronize here for a good discussion.
>>> I've participated in numerous similar discussions in the past (sage-devel
>>> etc.). I wonder if things are a bit too much in flux for a Skype session --
>>> there's many parties/people who are interested in having this problem
>>> solved, there's been *a lot* of prior discussion without any obvious full
>>> solutions.
>>>
>>> How about trying to have something like a "structured discussion"?
>>> Otherwise we derail into a 500-post long thread that leads nowhere?
>>>
>>> Blogs are great for this as they create an asymmetry between blog posts
>>> and comments, and allows editing posts after the fact.
>>>
>>> So here's my proposal:
>>>
>>> a) scientificcodedistribution.blogspot.com is created
>>>
>>> b) We announce to others (numpy-discussion, sage-devel) that we're going
>>> to have a "roundtable" (is that what it is called?) about "Finally solving

>>> the scientific Python software building& distribution issues".

[Chris Kees]

Sounds good. I will contribute to the blog and try to get to PyHPC,
thought I haven't submitted anything at this point.

Also, I like the looks of Nix, and I agree with a lot of the points
you and Aron have mentioned. Thanks for kicking off the blog.

-Chris
On Mon, Sep 19, 2011 at 3:10 PM, Dag Sverre Seljebotn

[Yung-Yu Chen]

On Tue, Sep 20, 2011 at 04:10, Dag Sverre Seljebotn <d.s.se...@astro.uio.no> wrote:

On 09/19/2011 09:43 PM, Matthew Turk wrote:

On Mon, Sep 19, 2011 at 3:40 PM, Aron Ahmadia<ar...@ahmadia.net>  wrote:

Dag,
You have my support.  I can definitely introduce our challenges at the KAUST
Supercomputing Laboratory in a contribution to the blog/github
repository/newsletter :)
A
PS - I am happy to visit Norway :)

I'd be interested in sharing as well.

For what it's worth, several members of our group will be attending
the PyHPC session at SC11, and I could likely organize a small
workshop in NYC.  I don't think [m]any of us could manage a trip to
Oslo.

I think PyHPC (or in conjunction) sounds like a great idea. Also it's close to a lot of Sage people.

I'll try to kick off the blog tomorrow and post some invitations.

Dag Sverre

I will be interested in this too.  I am building conservation-law solvers and running them on clusters.  It is not unusual that I have to build gcc for compilation.  I made a simple Makefile-based building system for my own use.  It will be great to share it with others and learn a better approach.

Unfortunately I can't make it to PyHPC, but I would definitely like to join the blog.

with regards,

Yung-Yu Chen

 

-Matt

hpc-p...@googlegroups.com<mailto:hpc-python@googlegroups.com>

mpi4py+unsubscribe@googlegroups.com.

For more options, visit this group at
http://groups.google.com/group/mpi4py?hl=en.

--
You received this message because you are subscribed to the Google
Groups
"mpi4py" group.
To post to this group, send email to mpi...@googlegroups.com.
To unsubscribe from this group, send email to

mpi4py+unsubscribe@googlegroups.com.

For more options, visit this group at
http://groups.google.com/group/mpi4py?hl=en.

--
You received this message because you are subscribed to the Google
Groups "mpi4py" group.
To post to this group, send email to mpi...@googlegroups.com.
To unsubscribe from this group, send email to

mpi4py+unsubscribe@googlegroups.com.

For more options, visit this group at
http://groups.google.com/group/mpi4py?hl=en.

--
You received this message because you are subscribed to the Google Groups
"mpi4py" group.
To post to this group, send email to mpi...@googlegroups.com.
To unsubscribe from this group, send email to

mpi4py+unsubscribe@googlegroups.com.

For more options, visit this group at
http://groups.google.com/group/mpi4py?hl=en.

--
You received this message because you are subscribed to the Google Groups
"mpi4py" group.
To post to this group, send email to mpi...@googlegroups.com.
To unsubscribe from this group, send email to

mpi4py+unsubscribe@googlegroups.com.

For more options, visit this group at
http://groups.google.com/group/mpi4py?hl=en.

--
You received this message because you are subscribed to the Google Groups "mpi4py" group.
To post to this group, send email to mpi...@googlegroups.com.

To unsubscribe from this group, send email to mpi4py+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/mpi4py?hl=en.

--
Yung-Yu Chen
http://solvcon.net/yyc/

+1 (614) 859 2436

[Dag Sverre Seljebotn]

On 09/19/2011 10:10 PM, Dag Sverre Seljebotn wrote:
> On 09/19/2011 09:43 PM, Matthew Turk wrote:
>> On Mon, Sep 19, 2011 at 3:40 PM, Aron Ahmadia<ar...@ahmadia.net> wrote:
>>> Dag,
>>> You have my support. I can definitely introduce our challenges at the
>>> KAUST
>>> Supercomputing Laboratory in a contribution to the blog/github
>>> repository/newsletter :)
>>> A
>>> PS - I am happy to visit Norway :)
>>
>> I'd be interested in sharing as well.
>>
>> For what it's worth, several members of our group will be attending
>> the PyHPC session at SC11, and I could likely organize a small
>> workshop in NYC. I don't think [m]any of us could manage a trip to
>> Oslo.
>
> I think PyHPC (or in conjunction) sounds like a great idea. Also it's
> close to a lot of Sage people.

Just to clarify: I hope that something will happen there, it sounds like
a great place to discuss this. But I don't think I'll be able to come
myself.

Dag Sverre

[Dag Sverre Seljebotn]

OK all, welcome to

http://fixingscientificsoftwaredistribution.blogspot.com/

Send me an email in private to be invited as an author. Once there's one
more blog post than mine (for balance...) I'll announce it on
numpy-discuss, sage-devel and so on.

Dag Sverre