HN user
Astrophysicist.
You may be interested to know that both Maxwell's and the Einstein Field Equations can be derived by minimizing an action, cf.
https://en.wikipedia.org/wiki/Einstein%E2%80%93Hilbert_actio...
https://en.wikipedia.org/wiki/Electromagnetic_tensor#Lagrang...
Enjoy!
There's a way of setting up a bare-metal (or VMs) cluster using Ansible. It may be the sort of 'easy in' you may be looking for:
https://kubernetes.io/docs/getting-started-guides/fedora/fed...
If you manage to automate deployment of the VMs or physical nodes (e.g., PXE), you've got a cherry on top.
There's a nice CUDA tutorial on DrDobb's. It may be slightly outdated by now, but it was a great help to get me started.
http://www.drdobbs.com/parallel/cuda-supercomputing-for-the-...
Despite its name, it is in fact not a pension fund.
If you are interested in some of the details:
The Navier-Stokes equations can be derived from the Boltzmann equation by applying a slight perturbation, expanding the result as a series, and taking the moments.
Taking the moments is essentially an integration, which comes with the implicit assumption that the system you're describing has sufficiently many particles. When running low on particles, this integration does not make sense. This is why the resulting equations do not apply at low densities.
The Navier-Stokes equations are the second order expansion of this procedure. The result of the first order expansion are the Euler equations.
This is called the Chapman-Enskog procedure. It's really quite illuminating when you see it for the first time. There's a great derivation in [1] if you can get your hand on it.
I'd like to point out that space is an extremely large and harsh environment. The three main issues:
1) Distances are huge. Light needs ~5 hours to travel from Pluto to Earth. This means high-gain (=large), directional antennas, and low data-rates to make sure you actually receive the same data that the craft transmits to you (and vice versa).
2) Electronics need to be shielded from radiation and cosmic rays. On Earth, the atmosphere does a this for us (and we still get hit by cosmic rays, leading to things like randomly flipped bits). If you have a space-craft that cannot be directly controlled from Earth (because, 5 hours one-way communication time), you need it to be somewhat autonomous. Random bit-flips can spell disaster, so you need to either bring a ton of shielding, redundant (and well-tested, aka "outdated") systems, or both.
3) All these things add mass to your vehicle. Mass is the single largest cost driver in launch operations.
In summary, space is difficult and expensive to get to and operate in. This costs money. Money is finite, especially in a world where many people would like to see space exploration funding cut because it provides no immediate tangible return.
There's an additional caveat that may be of interest.
If you execute code in parallel, you may pick up different round-off errors unless you take care to combine the results from parallel tasks in the same order every time.
This can be a problem when simulating non-linear dynamical systems (such as the Solar System).
For people wanting to go see a Buran, there's a prototype on display in a museum in (SW) Germany.
I'd like to point out that large-memory/many-core multi-user machines are very much alive in Computational Science (Computational Physics, Computational Chemistry, etc). Usually as test-beds (before deploying on clusters), visualisation system, or simply front-end nodes for clusters.
Simulations may run for weeks or months on large computing clusters. People wanting the resulting data may not have suitable access and/or resource allocations to repeat the runs.
If Earth was travelling a bit slower, it would just be on different orbit. Either more eccentric or just further away from the sun. This is encapsulated in Kepler's laws [1], which describe the motion of a single planet around a single star.
If you have other planets in the system (like our solar system does), things are more complicated. Orbital stability then depends on the arrangement of other planets. You are right in pointing out that the Earth's orbit is (possibly) unstable [2] over a timescale of billions of years.
[1] http://www.physicsclassroom.com/class/circles/Lesson-4/Keple...
[2] Unstable in the sense that Earth's orbit may become eccentric enough to smash into another planet, get ejected from the solar system, or dive into the sun.
It would not.
If you start out with a velocity slightly slower than the Earth's, you end up with an elliptical orbit (instead of Earth's almost circular orbit). Barring some sort of drag (to further loose energy), there's no reason it would decay into the sun.
I'm not in the business of space mission engineering, so I don't know details. Sorry.
But in general, you can control the error and make a trade-off between computing time and accuracy. You would select a timescale over which you want the error to be below some value, and then only consider the simulation valid until then.
It is a shortcoming of the integrator (Euler), not in the calculation of the force (as you suspected).
See [1]. Especially slides 11 and 12 may be of interest.
[1] http://www.astro.sunysb.edu/phy277/lect30.pdf
As a sidenote, there are better integration schemes, but all of them will have some error because we discretize the system.
Only tangentially relevant, but he may be referencing this tweet:
This is great, thanks!
Fyi, there's also screen-sharing (hover the mouse over your own window for the option), which works nicely (Chrome).
(Not Webdev, but Scientific Computing. Hope that's OK.)
Another vote for the OSX + VirtualBox/Linux combo on a MacbookAir here. Gives all the shininess of OSX, battery time of MBA, with the (package managed) flexibility of a Linux system. It's also seamless and transpartent when you mount your project folders, and run it headless with local port forwaring (ssh/http/...).
Also, if you need to do something crazy, you can just clone the VM, muck about, and then throw it away again.