
Python-Based Tools for the Space Science Community - neokya
http://spacepy.lanl.gov/
======
mtct
Fortunately Python is becoming the new programming language for science and
engineering, replacing FORTRAN and Matlab. Unfortunately I do not see many
opportunities for growth in other sectors

~~~
leephillips
This is only partly true, and in a limited way. Fortran is still king for
simulations or anything that needs to be fast. Other possibilities are C and
assembler, and that's about it. Python + numpy has become very popular very
fast for exploring data and the results of simulations, and it's a great
environment for this. Note that when you use numpy you're calling fortran (and
C?) routines. The fortran languages and compilers continue to evolve, and
fortran will probably remain the language of choice for large-scale
computation for some time. Other languages, such as Java and lisps, are
sometimes used for big simulations, but Python is just too slow to be used for
anything but prototyping.

~~~
yummyfajitas
This depends very strongly on the nature of the simulation. Lots of
simulations are handled just perfectly by modelling your system as arrays.
Consider, for example, nonlinear waves. Your simulation typically consists of
FFT -> k-domain operator -> IFFT -> x-domain operator (repeat for i=0...T/dt).

No reason whatsoever not to do this in python, though of course the FFT is
just fftw/fftpack and the x/k domain operators are numpy ufuncs (all written
in C/Fortran).

On the other hand, for particle simulations, you need more complicated
logic/data structures to handle multipole methods, so the python array model
might not work so well.

~~~
leephillips
Yes, it seems that there are some types of simulations that could be
structured as numpy operations steered by a little Python code. But can this
kind of code be run effectively on large multi-processor machines?

~~~
yummyfajitas
Array operations tend to be highly parallelizable by nature. Numpy operations
can certainly be parallelized, and even distributed. Take a look at blaze.

[https://github.com/ContinuumIO/blaze](https://github.com/ContinuumIO/blaze)

~~~
leephillips
That looks interesting. I know that numpy calculations should be
straightforwardly parallelizable; my question, out of curiosity, was whether
they were in practice.

------
siddboots
Somewhat related, I just discovered PyEphem, and have been using it to pin
down a time and location from the stars that appear in XKCD #1190

[http://forums.xkcd.com/viewtopic.php?f=7&t=101043&p=3395021#...](http://forums.xkcd.com/viewtopic.php?f=7&t=101043&p=3395021#p3394991)

[http://rhodesmill.org/pyephem/](http://rhodesmill.org/pyephem/)

~~~
maxerickson
I wonder if Randall Munroe also used it to calculate the positions of those
stars? He has mentioned it in some other places.

(I did not wade into that 970 page thread to see if someone had already made a
similar suggestion)

~~~
siddboots
If you save down one of the images and up the gamma a little, you can see a
tremendous amount of detail. Far more than could practically be done by hand,
and afaict, more than PyEphem has in its catalogue of "bright stars".

I suspect he used something like Stellarium and then ran the images though
some filters.

------
celias
This is one of the few (only?) python packages that can read and write files
in NASA's CDF format - [http://cdf.gsfc.nasa.gov](http://cdf.gsfc.nasa.gov)
Installing under OS X is fairly straightforward following the directions in
the documentation.

------
dfc
I cant think of another discipline where the first example from the time
section will use a Julian Day:

    
    
      >>> x=Ticktock([2452331.0142361112, 2452332.0142361112], 'JD')

------
gshubert17
The documentation mentions that "OSX install has become a challenge. With the
Enthought transition to Canopy we cannot figure out clean install directions
for 3rd party packages and therefore can no longer recommend using EPD for
SpacePy." They have other directions including some using MacPorts.

Installation directions for Linux and Windows seem straight-forward.

~~~
Fomite
Enthought going to Canopy as some weird hybrid of a distribution, and IDE and
a package manager may have something to do with it.

I'm had many fewer issues with Anaconda, and have found that OS X behaves just
as well as Scientific Linux or Mint for stuff like this.

------
pwang
"OSX install has become a challenge. With the Enthought transition to Canopy
we cannot figure out clean install directions for 3rd party packages and
therefore can no longer recommend using EPD for SpacePy."

Um... use Anaconda?
[http://continuum.io/anaconda](http://continuum.io/anaconda)

~~~
westurner
The Python installation tool utilized to install different versions of
Anaconda and component packages is called
[conda]([http://docs.continuum.io/conda/intro.html](http://docs.continuum.io/conda/intro.html)).
[pythonbrew](
[https://github.com/utahta/pythonbrew](https://github.com/utahta/pythonbrew))
in combination with
[virtualenvwrapper]([http://virtualenvwrapper.readthedocs.org/en/latest/](http://virtualenvwrapper.readthedocs.org/en/latest/))
is also great.

------
neokya
Can anyone clarify what does this means: 'License Agreement based on Python
Software Foundation License'?

~~~
maaku
[http://lmgtfy.com/?q=Python+Software+Foundation+License](http://lmgtfy.com/?q=Python+Software+Foundation+License)

~~~
neokya
haha, thanks ;)

