When I read the title, I assumed immediately that the intent was to use the word, 'queue' in appropriate context: Line'em up. Sorry, you blew it.

Boy, ain't that the truth. Ad, having a GS-5 doing the keyword reviews doesn't work well either.

Beat me to it...

There's a tendency now to try to use more common components in new satellites, especially for meteorology birds, while there's always new science, adapting existing hardware to do the work means you might get a couple of instruments on different spaceframes, and not cost as much as the gee-whiz one-offs. Someone already mentioned that R&D, testing, SRM&QA and launch services cost a bunch. If we COULD accomplish this, then restoring capabilities on-orbit would be great.

NASA had a "Flight Telerobotic Servicer" project in the early 90's. Don't know where it went but it did get a fair bit of support and a lot of good engineering talent was pointed at it. From my interactions with DARPA projects in the past, there's a fair chance that something useful will come out of this, even if the whole program is over-ambitious.

If not the exact technology, the concept was first bandied about in the early days of Space Station Freedom design and development. Among other things, Space Station was supposed to lead to a Closed Environmental Life Support System that included reprocessing urine, atmospheric condensate and, well, yeah, fecal water into water of sufficient quality for drinking and even medical uses. A lot of work, by quality scientists and engineers went into this. In 1992, an experiment flew in SpaceLab on STS-47 that demonstrated taking Kennedy Space Center tap water, storing it in a closed container for 90 days, and running it through a process/apparatus called SWIS (Sterile Water for Injection System) to create water that was demonstrably "ultra-pure water for injection" per the US Pharmacopaea. Oh, and it worked, too. Making waste water into something drinkable is considerably simpler.

A poster commented on the potential for cross-transfer of large molecular weight compounds across the ultrafiltration membrane... Unlikely unless it's got holes, and they'd become obvious by the "filtration" rate.

A lot of the monte carlo schemes, and especially the nuclear physics ones I've encountered recently, need a LOT of memory. Most of the cloud options are sort of memory-lite. And, map-reduce (Hadoop) isn't the answer to everything, even if my boss thought so at one time.

Yes. Next question?

As pointed out earlier in the thread, you're not defining requirements well.

I think you're going to want to consider setting up a cluster front-end. You generally do not want to run X on all the nodes: Let them run the monte carlo sims and don't waste memory or resources allowing users to hammer each node. Or, allow it now, and regret it later when performance plummets.

Consider GPGPU (nVidia Tesla, realizing that AMD/ATI have GPGPU options, but I am not versed in them yet) for improved performance in calculations.

Have you looked around your university? Is there anyone else running clusters with whom you could partner? My group does exactly that: We run a cluster and while I also am a numerical modeler, we provision and operate a cluster that serves users in agriculture, nuclear engineering, petroleum engineering, atmospheric sciences, HEP, chemistry and the social sciences. Your questions suggest, to me, that your time is better spent as a researcher and not as a system administrator.

And while we're here... One of my pet peeves is when a professor takes a grad student who came into a program to get their degree in, say, nuclear physics, and turns them into a system administrator and user support girl for the group. Either instead of, or in addition to, their scientific career, they have to manage the computing resources and learn how all the software works. In my experience, if they're good graduate students and conscientious, they will do a great job, but will not get the education they came for. They may get the degree, but they are likely doomed to supporting other users who got a better education. They're still good, in fact, indispensible, to a research program, but they were sacrificed with little input to their future. Better, if that's what you need, to actively recruit for someone who wants to learn the field to better become a computational expert with a discipline track in your field, nurture them, and if they are deserving, provide said terminal degree. I really don't like sacrificing an unsuspecting graduate student to the HPC gods for a faulty member's benefit.

Generally, your head node will need an X client, but NOT the compute nodes. You won't have to log into them per se, but the head node, where you submit your jobs, does have to get to them. In general, the compute nodes in an HPC environment are hidden away on a private network, and don't see the outside world, And, for that matter, shouldn't (let's not talk about OSG requirements, or things that ATLAS and CMS are promulgating).

Another consideration is cluster-local visualization: As datasets grow, it becomes less practical to bring whole datasets back to your desk, and then process them for a quick-look at results. Instead, initial, and perhaps all analysis should be considered on the cluster. This argues in favor of an X installation, and GPU accelleration hardware on at least the head node, a dedicated graphics/analysis node(s), or perhaps the whole cluster.

And, so far, no one has spoken of favorite compilers. gcc's not bad but not stellar for a lot of HPC uses. Portland Group and Intel have done good things, IMNSHO, in the compiler world, and PGI is starting to incorporate nVidia GPU compatibility in their stuff.

There is also the occasional need for something like VNC when you absolutely, positivily have to have that remote desktop look for your visualization software.

A lot of the Russian experience, at least when I was active in Space Station stuff and the Russians were still flying Mir, had small populations, n=1-5. You cannot draw significant conclusions very easily from samples that small.

Electrophoresis is a reasonable drug delivery system for SOME agents, but not all.

While I can't speak to Kirk's problems, the Shuttle isn't a sterile environment. It is kept as clean as possible, mainly because they don't want any more particulate contamination to fly, and get circulated in microgravity than necessary, but you can't get rid of all of it, Historically, on Shuttle, they set up a fan between Middeck and Flight Deck, in the starboard access area, and used a filter on the inlet side. It captured fine particulate matter... and pens, etc., that were dropped or otherwise lost by the crew on-orbit. It all ended up, eventually, in the filter.

Also, while there's a 2-week quarantine period preflight, there are SOME diseases where the incubation period is longer than that. In those cases, isolating the crew for 2 weeks wouldn't catch the problem.

Yes. Some bacteria become mor virulent when incubated in a microgravity environment.

Um... but such changes CAN occur. One of the developments for the Crew Healthcare System included the ability to use available water supplies from stored, or recycled water, to make intravenous solutions, using fluid concentrates (we tried, but the powdered chemicals just don't disolve well and have to be manipulated). The system used a multiple-component water pass-through purification system to prodce at least 50 Mohm water that had also been subjected to ultrafiltration, to assure cellular contaminents such as endotoxins were removed. The system did not use high pressure or heat sterilization, and was demonstrated to meet US FDA and USP standards for ultrapure water for injection, and intravenous fluids.

Water reuse for long-duration spaceflight missions is already achievable, with only the stigma of using recycled water for drinking and medical uses remaining as a potential problem. The processed water is considerably cleaner than anything you'll drink in a conventional water supply, and certainly better than the tap water at Cape Kennedy.

The ability to white-noise (or pink-noise) jam GPS has been around and employed for, literally, years. And, most of the first of these I saw came from China, too. GPS is a relatively fragile system, at least n the L1-C/A world: GPS satellites have limited power budgets so signal levels are low on the ground. Receivers have high gain. Multipath in urban environments can confuse receivers. Emitting a random noise signal over the range of L1 frequencies isn't that hard, and doesn't take much power... or antenna height... to cause problems.

The article makes all of these points. Read it and take note of the fragility of the system. That's its downfall, not a $30 device.

Slack has some benefits if only because you end up having to compile from scratch in most cases, which can be instructional. However, Hook 'em and reel 'em in, then teach 'em what the tricks are for deciding on a distro, and help them do more complex things.