That the Earth's core is not molten sodium, nor is it made of stainless steel, this is a pretty poor experimental model, but, hey, I'll bet the grant money was pretty good.
Considering that magnetic field generation depends only on the pattern of fluid flow and the fact that the fluid is conducting, I'd say this is actually a pretty good experimental model. See my previous post about why it's really handy to have a dynamo you can change the parameters of.
That theory is treated with serious skepticism for a reason. (Well, lots of reasons, really.) I can recall having this discussion here before and I forget the details of the theory, but I recall that the author showed an accute lack of understanding of planetary science among other things. (Jupiter is unlikely to have much more of a given metal than the Earth, oddly enough. The core is only at most about 10 Earth masses, and that's mostly ices. Also, the reactor theory doesn't explain field reversals or why the Sun has a field while dynamo theory explains both fairly naturally.
Actually, while the original poster's linked model is indeed bunk, it turns out that many of these objections aren't entirely accurate.
For one, the model doesn't dispute that the field arises from a dynamo. All it disputes is the nature of the heat source driving it (near-critical ball of uranium vs. a mixture of radioactives in far subcritical spontaneous decay mode). The mechanism for setting up the field is the same.
For another, if the model's tenets are accepted, field reversals aren't mysterious. The dynamo is shut down and restarted; there's no reason for it to restart with the same field orientation as before. All of the core material is far past the Curie point for holding a residual field, so I'd expect the restarted orientation to be random (constrained only by how the earth's rotation axis affects dynamo flow patterns).
What I find dubious about the model are the claims that a) lithophyllic elements like uranium would be concentrated in the core material, and b) material would diffuse preferentially towards the core strongly enough to result in fractioning, as opposed to just slightly increased concentrations. kT is big, and gravitational potential energy change with location is small down there, so I'd expect material to diffuse anywhere it pleased.
As far as Jupiter is concerned, I can't find references that say that the "icy" chemicals are in the core. As jupiter is expected to be molten throughout (as far as I can find), I'd expect them to diffuse out. Most sources say that carbon and nitrogen are mostly bound as methane and ammonia above the layers of liquid hydrogen. Some of the oxygen is bound as water in the atmosphere, and some of it as silicates in the "rocky" part of the core (which is presumably fractioned into silicates on top of a [molten] iron inner core, as in Earth).
Moot point re. the original article, of course, as you are definitely correct about the rocky core's mass.
Just in your post, I can say that it's unlikely that the field would stop because of build-up of wastes. For one thing, the wastes would either build up or they'd continually be lost. If they *did* build up, they'd slow the reactor down which would cool the system, leading to more sluggish convection and less mobile atoms. That would tend to freeze the wastes in place, not remove them.
My understanding was that the model proposed that they built up, shut down the core, froze in place, kept the core shut down until they decayed enough for the core to be near-critical again, and then dispersed as the hotter core allowed for faster diffusion away from the reactor area. Still pretty dubious, but I'd want to see a fairly detailed model of temperature, reaction rate, and mobility changes before writing that aspect off as outright impossible.
I don't see how measuring the effects on a 10-foot diameter sphere (filled with Na) can be equivalent to the effects on the central core of a 6400km-radius ball of rock (filled with many different elements). If they want to figure out more about the Earth's magnetic field, I suggest they take measurements, etc... on the EARTH.
The nice thing about building our own sphere of molten metal is that we a) know its structure and composition in detail, b) can put sensors inside, and c) can alter parameters (temperature gradient, rate of spin) and see what happens. None of these are practical for Earth, though we do have a reasonably good idea of what its composition and large-scale internal structure are.
The patterns of motion they're setting up are common to a very wide range of fluid systems - you don't need something as big as Earth to generate them. It's very hard to measure fluid flows and magnetic fields deep within the earth (all that's easy is density change boundaries), and the Earth's field isn't likely to flip within our lifetimes (or the next several centuries, minimum, even if the wierdness we're seeing _does_ represent the start of a flip). A small-scale mock-up run in the same turbulence modes that the core has will flip many times during the course of observation, and tell us a _lot_ about how the flipping occurs.
In short, we'll learn a lot more about the geomagnetic field from this experiment than we would from more studies of the Earth itself.
I dont think its a "technical issue aka sorry we cant do it", but a willingful decision of delay to not let "critical material" of any kind spread as fast over the number one info-pool as it otherwise really could
Stop and think about this for a minute.
Do you have any idea how _huge_ an amount of effort it would take to screen images indexed and search terms and tweak them so that no images "harmful to the administration" came up?
When it takes this much effort, and there's nobody holding a gun to their head, and they have competitors gaining mindshare, why the _hell_ would Google bother with this? Their primary purpose is to make money, not please Republicans, and they're going to be around a lot longer than Bush will be in power!
The line is that their "news" images cycle out of the index quickly, and I can certainly believe this - after all, if I'm searching for newsfeed images, chances are I'm asking about something that happened recently.
Trying to stage a cover-up of the type suggested would be very expensive and not a good business strategy.
There was a time when different computers ran on different processors, and supported different OSes. Now what's happening? Itanic and Opteron running Linux seem to be the only growth players in the market; and the supercomputer world is completely dominated by throwing more processors together. Is there no room for substantial architectural changes? Have we hit the merging point of different designs?
At the high level, things will always look similar. You can write Fortran and have it compile regardless of whether you're working on a RISC machine or a CISC machine, a register-rich machine, a register-poor machine, a three-operand R-R machine or a memory-based stack machine. The only thing you _might_ notice is changes in the communications topology, because it changes how you'd split up the problem, but that's not a processor issue (it's a network/interconnect issue).
That having been said, there does seem to be a convergence within processors themselves. Much of this stems from very fundamental design constraints. It's easier to pipeline instructions if they only do one thing, so instruction sets either get RISCian or get translated into something RISCian. It's easier to access local storage instead of non-local, so everything has a register file and a cache hierarchy. There's demand for parallel execution of SIMD-style computations, so most things support that. Everything works better if you have an unbroken stream of independent instructions, so processors try their hardest to mask latency of things like branches and memory accesses through speculation, and re-order instructions to mask dependencies. The only technology that wasn't really used much for this was symmetric multithreading (SMT), which gets you a stream of independent instructions by pulling them from multiple threads, but this has finally trickled down into the mainstream. So, processor cores contain the same kind of fundamental feature sets by necessity. We're going to continue to see this, for example with the emergence of so many chip multiprocessing (CMP) offerings, where putting multiple copies of a core on die is a better use of space and power than trying to build (and feed!) a more complex single core or adding more cache.
The devil is in the details, though. The instruction set architecture of x86 offerings is a very large mess with several inconvenient anachronisms, which takes working around. The PPC ISA is a bit cleaner in that regard, but I'm sure it has its own quirks. Itanium (1, at least) struck me as an experimental test bed for every bizzare instruction set feature they could think of, some of which may even pan out. If there's a chip that's pushing architectural boundaries, that's probably it (pity that it didn't help it much).
However, unless the nature of the tasks being asked of a microprocessor changes drastically, or unless someone comes up with a really fundamentally different way of structuring data flow for problems, processors will continue to look more or less the same, even if the underlying fabrication technology ends up changing drastically (which I doubt it will in the next decade, at least).
I'm less excited by a supercomputer with 10k processors than I would be by one containing as few as 64.
The problem is that if you can build a supercomputer with 64 processors, you can build an even better supercomputer by wiring a bunch of 64-processor nodes together. Yes, you're increasingly communications-bound, but there are enough (useful!) problems with relatively low communications overhead for this option to still be attractive.
Interestingly, this is increasingly the case for single processor machines as well. They're getting multiple cores on-die, because both increasing the complexity of a superscalar core and devoting added real estate to cache have reached diminishing returns. This trend will only continue.
As far as I know I don't think anyone has been able to demonstrate lasing in silicon nanocrystals. Gain has been demonstrated but too many issues arise that prevent lasing. Also, electrical pumping is pretty much impossible at since the nanocrystals are embedded in an insulator (SiO2). Anything based on optical pumping will never be cheap and scalable.
This wasn't silicon nanocrystals - this was microstructures (though "micro" is a misnomer at scales this fine) in bulk silicon. Electrically driven silicon LED-type structures (being used for illumination for an image sensor chip, for the particular demo I'm thinking of; I'd have to dig for the citation [Japanese university, a year or two ago]).
The problem with using III-V's or any other 'exotic' material system is how do you package it with silicon based technologies.
You wouldn't. You'd fab the whole chip, logic and all, in a GaAs technology. You'd only do this if you wanted optical communication badly enough to take the cost hit for doing this. I can see it for niche applications; before SiGe and plain old Si caught up, some of them had GaAs components.
You can also do GaAs epitaxial layers on a Si-process chip, but that's almost as ugly cost-wise as doing a GaAs chip.
A laser on silicon essentially solves the wiring problem of traditional digital integrated circuits (ICs). Modern digital ICs consist mostly of wires; a small percentage of the silicon area is the transistors that perform the computation.
Not true last I checked, and I am presently doing IC design. Yes, you need plenty of space for your routing channels, but especially with the number of metal layers we have now, there's plenty of space _above_ the active circuitry even after you take out the layers used for routing within the gates.
Two problems arise. Driving a signal from one end of the chip to the other end is very slow because the wires present a high RC load to the puny transistor. The other problem is simply routing the wires.
The RC load problem is only _severely_ nasty if you lay out the bus as one long wire. If you segment it and put repeaters, time scales as length, not as length squared. You can also pack adjacent data stages more closely together as linewidth decreases, so chip shrinks continue speeding things up.
Routing is only a crippling problem if you're trying to do an anywhere-to-anywhere communications mesh. Even then, there are well-known topologies that minimize pain. This is part of why the movement to multi-core chips is happening - a massively superscalar chip _does_ have to route results from any part of the chip to functional units at any other part. Smaller cores in parallel are a win/win scenario (simpler design, easier communications).
See above re. routing. Routing is actually _easier_ now than it was a decade ago, because we have six or more metal layers to do it in rather than two or three. For a pipelined data flow, the routing complexity between stages doesn't really _increase_ with chip size. It's aggressively superscalar designs that do that, and those reached their peak complexity a few years back (with emphasis shifting to multi-core now).
The laser solves the first problem because we can simply transmit a bit (0 or 1) by modulating the laser light. The bit will travel at the speed of light.
Electrical signals travel somewhere between 10% and 50% C, usually. The real problem is capacitive loads, and an electro-optic system has to deal with those too, believe me. Electro-optic systems will actually have it _worse_, because you need large photosensitive structures to pick up the light (more capacitance), and have relatively small photocurrents to charge or discharge them with. You no longer have electric networks with huge fan-out (and large capacitance), but if you build a segmented hierarchical scheme, you don't with an electrical implementation either. And you get an _optical_ fan-out in return - you're only producing so much light, and it has to be split among N potential receivers.
Light is very far from being a magic bullet for intra-chip communication.
The laser also solves the second problem because there is no need to route the optical paths. The light from one laser can cross the path of light emanating from a second laser and can continue, unimpeded, to the detector intended for the first laser.
This turns out not to be the case. Your emitters are small enough that diffraction will spread out the beams quite a bit. So, you're either using a broadcast system (which reduces your communications bandwidth drastically - you only have one channel shared among all components), or you build waveguides. Waveguides have to be routed, and have the same kind of crossover problems wires have. They're actually a bit worse, as they have more constraints on geometry than a low-current signal wire does.
In summary, I don't think that optical communication works as well as you think it does, and the problems you note with electrical communication are largely solved.
And at this point there is no other easy way to make a silicon laser using anything other than the raman effect. Any other method would require the use of exotic materials (i.e. erbium, heterojunctions, etc.). It's been tried and the results aren't all that promising.
Actually, it turns out that if you can produce structures small enough, you can get silicon acting like something closer to a direct-bandgap material (you no longer have a crystal of near-infinite extent, so energy level analysis changes).
The best I've heard of is efficiencies in the single-digit percent range, though.
I think anyone actually building an optically-communicating chip would just use gallium arsenide (there's enough of an infrastructure for it to be practical).
Modern electronic computers are getting closer to being optical in any case (gigahertz range).
Could someone explain this to me? I don't get it.
It refers to a couple of things.
One is that people have been talking about using optics to route signals on motherboards for a long time, as high-frequency electrical signals are a pain to keep clean over the relatively long distances invovled. I'm skeptical of this happening any time soon, for the same reason I'm skeptical of CMOS-on-silicon dying any time soon: the technologies are still scalable, a vast amount of study has produced a very good understanding of them, and we already have all of the tools we need to produce devices using them. An optical scheme would involve considerable retooling and a considerable learning curve. One of the important pieces of an optical communications scheme for electrical chips is good, fast, and cheap electro-optic transcievers. Cheap means implemented on silicon, on the same die as the logic elements. Receivers are no problem, as photodiodes work fine in an indirect bandgap material, but transmitters are very difficult (you want a direct bandgap if you're trying to produce an LED or a semiconductor laser). This paper shows a way of producing a semiconductor laser on something resembling a conventional silicon CMOS process (though I'd have to read the paper carefully to see if they did any tweaking). The catch is that I'm not sure if they're producing light in a band that can be picked up by a silicon photojunction (I _think_ they are, but would have to read the paper in detail).
The second thing the line could be referring to is that the distinction between an electrical signal on a bus and a microwave signal in a waveguide gets a bit blurry as frequency goes up. However, that's definitely overstating the case for the time being. If you were designing motherboards to use waveguide style signal transmission, they'd be set up quite differently. Right now, microwave emission is an unwanted side effect, and is for the most part minimal (it causes crosstalk and illegal RF/microwave interference).
I've spent a bit of time in a third-party graphics driver house, and I now do chip design, so I can speak knowledgeably about some of this. The problems are:
There will be next to no market, so funding is a problem.
You won't compete performance-wise with high-end consumer 3D cards. You won't compete budget-wise with low-end consumer 3D cards. You're going to have crappy Windows drivers unless you wave money in front of your developers to work on that uninteresting part and _maintain_ it, _and_ shell out for the Microsoft developer packages for this sort of thing.
Your revenue? Linux geeks who are patriotic enough to pay for a product with less bang for the buck than a standard commercial card, and who will take the promise of eventually-less-buggy drivers some time in the future as being more valuable than a buggy but adequate and fast 3D driver now.
People cost money. This is a problem.
The thread makes mention of hardware cost control, though they're having serious trouble making that competitive (hard to beat quantity-millions for bulk rates). However, Alan Cox's message highlights a serious problem - you have a lack of programmers for cards that specs are already known for.
The only realistic solution I can think of is to pay coders to produce a minimum adequate driver implementation for the new card (or heck, even one of the old ones). Making a decent accelerated 2D driverfor an experimental card is a few person-months of work, if memory serves. Making a decent accelerated 3D driver is a few person-years of work. The budget for this is within reason, but still has to come from somewhere. As there isn't a deeply pressing need for this being felt by most people (see previous point), the pace of volunteer development will be slow (as is shown by Alan Cox's comments about current driver projects).
I'm not suggesting taking this outside the open source community. I'm suggesting paying open source people enough that they can do this as their day job, and have _incentive_ to do this as opposed to some other interesting project.
Graphics cards are in a patent minefield.
This is the Big Problem. I can't stress it enough. Any easy way of implementing _anything_ to do with 2D graphics cards was patented a decade ago or more. Any easy way of implementing any basic 3D was patented more recently, but is still patented. Even crawling through the patent database to look for implementations that were missed will take a lot of time, and cost a significant amount of money (you need experts on graphics algorithms and VLSI design to do this, and patent lawyers to back them up; see previous point about volunteer time vs. needed schedule).
Big graphics companies solve this by doing the requisite grunt work, and aggressively patenting everything they can think of as a defensive measure. The standard way of solving patent conflicts is bitter litigation followed by cross-licensing relevant patent portfolios from each other (we've seen this in other parts of the hardware world often enough too). A low-budget open source card project won't be able to afford either of these, and both will eventually become necesary (someone will claim you're infringing no matter how clear it is you aren't, because it's in their best interests to make the claim).
In summary, the only way that I can see an open source graphics architecture being developed is if the community and donors scrape together several hundred thousand to a few million in startup capital to fund hardware and software development, and to deploy lawyers. A side benefit is that you might even be able to afford chip spins if you're on the high side of the funding scale, though it'd probably be more wise to divert the funds to multi-platform driver support and patent portfolio instead.
Variant options that come to mind:
License existing patents instead of trying to work around them.
A very useful tool for cheat checking of programs is MOSS. It is free, sorts out the cheating candidates, and provides a useable interface. Of course, one must check by hand for true cheating vs. false positives.
This was alluded to by my "heuristic checker" comment, above. Downsides:
It won't check things like the MS Excel assignments the profs have decided should be in the course this year (insert "how is this CS?" grousing here).
I seem to recall there being controversy at some point with MOSS keeping a digest of statistics from all submitted assignments (or maybe even keeping them on file).
The good cheaters, however many of them there are, still won't be caught.
It does, however, help a lot catching the bad cheaters who _didn't_ hand in their assignments on top of each other.
The fact that I've seen so many bad cheaters, and that most of these assignments are easy enough that anyone with two brain cells to scrape together wouldn't need to cheat, leads me to suspect that the correct assignments are mostly legitimate.
I'm sure there are people who have cheated with a correct assignment that I haven't caught, but think - if you have a correct assignment, and will get full marks, why would you risk your own mark sharing it with some loser who can't do the assignment? And why _would_ you, as another poster pointed out, spend twice as much time reshuffling your assignment to look original as you could just doing the thing following the steps in the book?
I know that cheaters aren't rational (otherwise they wouldn't be wasting a course's mark cheating on an assignment they could outright blow off without substantial impact on their grade). However, the source of a correct assignment would be someone who can think, one hopes.
The surrogate I see among people who do hand in correct assignments is in-lab collaboration. They ask each other how to do X or Y thing that's troubling them (or they ask me, but I'm only there a couple hours a week). This results in assignments that are stylistically similar, but not close enough to be outright plagarism. I've watched people do this, so I'm reasonably sure that most of the "stylistically similar" reports are the result of conversation and not modification of "borrowed" assignments.
I'm told that cheating is endemic at some places. Thankfully, this doesn't seem to be one, yet.
I was hoping for something educational and instead I found a collection of jokes that I don't find very amusing.
This is intended to be educational. Rather, it is intended (at least in part) to be yet another thing to point first-year (and later!) students to, in the hopes that they decide to absorb it for a change. Give the advice in enough forms, and maybe one of them will take.
That, and it reads a bit like it was written to vent frustration. I know I can sympathize with a lot of what was expressed there (I've had to TA programming courses many times).
This really depends on how well the professor defines the assignment. If every aspect of the programming assignment is spec'd out to the point that there would only be one correct answer, it would be easy to get away with cheating since all of the good submissions would look the same.
There are a few things that you can still look for, here:
Nearly identical style. This includes names, indenting, order of functions, spacing conventions, and so forth. Some similarity could be coincidence. Nearly identical style is very suspicious, especially if any of the other flags come up too.
Nearly identical discussion. Many assignments (like the ones I'm currently marking, for instance) require a short write-up explaining what they did. This may only be a few sentences, but people who cheat tend to either copy it word for word, or do a broken copy of it taking key words and trying to paraphrase the rest. Usually badly. This leads into the next point.
Identical mistakes. Two assignments. Both would fail on their own lack of merits, but curiously, they both made exactly the same set of errors, in addition to having very similar style. Not likely to be concidence, that. Especially since they were...
Handed in on top of each other. These assignments are put in a drop box. Electronically submitted assignments are usually datestamped. Cheaters, once they finish cheating, tend to submit at the same time (at least in this course). Finding two matching assignments in a stack of a hundred would take a good memory (or a heuristic checker). Finding two matching assignments that are right on top of each other, or within a few entries of each other, is much easier.
Despite the fact that it's _possible_ to cheat without detection, a large number of people don't. Remember, the people who are cheating are the ones who can't hack a first-year CS course. While there will be exceptions, the kind of person who can't figure out how to make "hello, world" or set up a very simple Excel spreadsheet, with the instructions in front of them, is probably not going to be very good at cheating either.
If, however, the professor assigned a creative problem solving exercise and a proper solution could take many different paths, 2 or more identical submissions would be a dead giveaway of cheating.
The problem is that it's very hard to do this in a way that's easy to mark. In an ideal world, that wouldn't matter, but in practice, some poor TA is going to have to try to mark 200 assignments in 3 hours. That's hard enough when they _are_ written to be easy to mark (I still wince at the memory of one marking assignment that involved digesting a 5-page report and then visually determining whether another 5 pages of non-trivial code worked or not).
In summary, despite the fact that we're stuck giving cookie-cutter assignments for practical reasons, the cheaters (that I see, at least) seem to be as bad at cheating as they are at doing the work.
>What's the point? They can already endure the vertical-launch G forces just fine.
you've just said it yourself, 'They' - as in they the astronaut/kosmonaut.
Put Joe Armchair in a flight suit on an acceleration couch, and he'll endure a few minutes of 3-4 G just fine too. The only people who can't are those with heart conditions or certain other specific disorders.
A 2nd point that can be derived from my 1st (from the above) - is greater forces that come into play, greater endurance and sturdier things have to be built - So there is a balancing-act between spend more/less on 'take-off costs' vs 'building costs'.
What I've been trying to get through to you is that the penalty for punching through more atmosphere is more than enough to offset this. You have to carry more fuel to give you the extra delta-v. This is in a regime (total delta-v greater than exhaust velocity) where adding extra fuel is very difficult and in fact requires that a _smaller_ fraction of the craft be structure, requiring multiple stages or very expensive materials.
So you can build a lighter craft if you launch straight up, unless you have something else (like a space plane's scramjet) that gives you an overwhelming benefit from being in the atmosphere. Even then, you get out of the _dense_ atmosphere ASAP.
Em', NO *again* - What I did is try to summarize the BASIC theories of BOTH methods (without trying to 'pick a favorite'...).
Now I'm pretty sure you're just trolling.
I've been _analyzing_ the merits and drawbacks of the various approaches since very early on, and have shown that the drawbacks of horizontal takeoff far outweigh the merits for any kind of conventional rocket (and have pointed out non-conventional types of rocket that would benefit).
Are you proposing some alternate approach to reaching orbit? Are you disputing any of the statements I've made? If the answer to these is "no", you can stop wasting breath. The "basic theories" have been summarized long since, and the "positives and negatives" have already been discussed.
In a vertical lift-off, the person(s) would have to endure a greatter amount of G-force due to the amount of force unleashed in a fraction of a second to achive the inertia needed to start lifting and contiune accelerating toward achiving proper amount of velocity(ies)...etc
The difference is at most 1 G. When you're boosting at 3-4 G, the delta-v loss from earth's pull while in vertical climb mode is small enough to ignore.
So, survivable astronaut acceleration is not much of a problem. These are trained pilots with flight suits to protect them, here.
In a horizontal lift-off, the person(s) wouldn't have to endure the same amount of G-forces, as in a 1st stage one would only have to achive the inertia to overwin the air/frition-resistance, and sure at a 2nd stage one would still have to overwin the Gravity-force that's keeping us so firmly on the ground to achive orbitit - but the main difference in this take-off method is that one can/could adjust the amount in inclination and therefor be able to control the amount of G-force the person(s) would feel/endure.
What's the point? They can already endure the vertical-launch G forces just fine.
What you don't seem to be realizing is that _any_ substantial angle from the vertical results in a _considerably_ longer path through the atmosphere, which costs you a _lot_ to plow through at high speed. Unless you have a very good reason to stay in the atmosphere - i.e., a space plane's scramjet engine - you're going to take off as close to vertical as possible until you're out of most of the atmosphere. This is exactly what the shuttle does.
In summary, you seem to be claiming a positive benefit that offsets a problem that isn't a problem, and to be overlooking a very large negative to taking off at an angle at low altitude.
Re. radiation, I'd worry more about synchrotron radiation than Bremsstrahlung. Bremstrahlung is only important when you're imposing a very strong acceleration on the charge (i.e. smacking it into a solid target).
I thought that's what was implied with a change in the field strength?
The accelerations involved in any kind of macro-scale displacement or compression of the fuel are far too low for bremsstrahlung to be significant. The minimum threshold above which you generally worry about x-ray emission from devices is around 10 kV, according to the electrical safety codes I've seen (though this is admittedly a pretty arbitrary value). This corresponds to a particle going from hundreds of km per second to zero in less than a microsecond. This kind of thing happens when particle beams or high-energy plasmas interact with stationary matter, and pretty much nowhere else.
As for heating the reaction, couldn't you hold a core of hot plasma and flow the colder stuff around it? Or actually burn some of the colder stuff to maintain a tightly wound magnetic field (via the currents generated by the burned fuel)?
The problem is this: You want to heat the plasma you're using as exhaust (you actually want it to be self-heating), but you want any plasma being stored for later to stay _cold_. The hotter it is, the lower its storage density and the faster it drifts out of your containment fields.
Hot plasma doesn't help your containment field, either. When you heat plasma in a magnetic field, it _expands_ and takes some of your field lines with it. This makes containment in the hot plasma bubble worse.
So, we either have a simple field where we react all of the plasma at once and let containment fail, for one big burn, or we have a complex field that lets us keep the plasma we don't want to burn just yet well away from the stuff that we do.
A secondary problem is that this plasma is _bad_ at self-heating. Electron/ion recombination releases its energy as light (EUV up to x-rays). You need to turn this light into usable energy, either as heat or as electrical energy. Plasma is reasonably opaque to UV if it's dense enough, so you may get it thermalizing, but it'll be iffy. X rays have a low enough interaction cross-section that you pretty much have to just use them to heat a solid containment vessel and get power for an electric drive off the resulting heat gradient.
A D-D reaction would work just fine there... of course you'd need some tritium to start it, but as long as you kept feeding dueterium into the thing, you'd sustain your reaction and be able to control the temperature better.
Fusion is a completely different problem than the ion recombination drive. For one, D+D fusion gives you mostly charged byproducts, so you have no problems making the plasma self-heating. For another, the plasma is insanely hot, so density is far lower and magnetic field strength has to be quite high if you don't want drift to kill it. Lastly, to get the reaction rate to anything useful for propulsion requires fields strong enough that you need magical materials for your field coils, and they _still_ end up being heavy enough that you're restricted to very, very low accelerations (at least in "use the fusion products as a high-Isp exhaust jet" mode - an electric drive would trade Isp off against acceleration more reasonably).
So, apples and oranges.
It seems to me that the geometry that you'd want for this would more closely resemble a spheromak than a tube. Unless you're talking about a pulsed FRC, that may do it, but the tearing of the field lines to get the FRC conditions would seem to be too energy intensive.
I'm using what's pretty close to an ordinary dipole, so none of the above. More exotic field geometries are needed when you're going for long-term confinement of a very hot plasma (spheromak, tokamak, etc), or when you're trying to use switchback currents to do plasma heating (schemes that involve field line
It comes from the myth of "escape velocity". People figure, hey, why not just fly horizontally until you hit escape velocity, and then up you go, instead of trying to reach escape velocity vertically.
Actually, thrusting horizontally is the perfect way to reach orbit (and this is largely what the shuttle does now). Orbital velocity is tangential; an escape trajectory is a very different beast (can be thought of as the limiting case of a parabola or a hyperbola as perigee (backtracked along the course) approaches the centre of the earth).
What puzzles me is people who think flying horizontally is free, or lets you climb for free, or magically reduces by some large fraction the delta-v required to reach orbital velocity.
If you are climbing as a plane does, you get to use the air to help you, rather then against you...
No, you don't.
An airplane turns horizontal motion into lift when it climbs. You need to keep thrusting in order to keep climbing.
As mentioned elsewhere, there are factors that can give you an efficiency benefit if you play your cards right, but you seem to fundamentally misunderstand the nature of flight, as far as I can tell from your posts.
Also, your quote about "orbital velocity is 8km/s" depends on how far out from the earth you are orbiting. You can orbit at theoretically any elevation as long as outside gravital forces aren't effecting you with any sort of substantiality.
To _get_ to that height, you end up needing more delta-v than you'd need to orbit lower.
The actual relation is that to make an altitude change, you need to have kinetic energy equal to the difference in gravitational potential energy between the two altitudes, and to hold a circular orbit at any given altitude, you need kinetic energy equal to the binding energy, which is _half_ the difference between your GPE at that altitude and your GPE at infinity (defined to be zero).
So while something in geosync is orbiting at only a few km/sec, getting to geosync takes somewhere in the ballpark of 10 km/sec delta-v. That's why payload ratings to geosync for commercial boosters are lower than the payload ratings for LEO (check the various launch companies' web pages some time; they love to talk about what their rockets can do).
One of the major energy wastes of the shuttle are the first 10 km of its ascent. Here, the atmosphere is thick enough that it faces a large amount of drag - and this is the part of the atmosphere it goes supersonic in. Comparing the concept behind X-15 and more recently SpaceShipOne, a subsonic transport lifts the craft to a higher altitude, taking it out of the thick part of the atmosphere up to an altitude where acceleration and altitude give it a much better drag configuration. This, in turn, allows the craft to fly off using a much smaller energy expenditure on the first part of its acceleration.
My understanding was that the initial part of the launch path appears wasteful because, as an early part of the launch course, the craft spends so much more time there (it's still moving slowly, because it takes time to reach mach-bignum even when you're accelerating at 3 gravities). A more useful efficiency metric would be average acceleration (delta v achieved across a given time interval, not distance interval).
I'd think that drag losses would be minimal at the beginning of the ascent, as the craft isn't moving very quickly. There's another argument based on the mass per unit cross-sectional area of the shuttle and of the atmosphere column it punches through that places an upper bound on the amount of extra impulse needed to get through it at higher speeds.
As an aside, the space shuttle is a shoddy old piece of gear, designed and built in an unsafe manner, and thus, as a result, unsafe. It is an over-engineered boondoggle, capable of much more than it needs, and as a result, much less reliable than it should be.
The shuttle is an experimental prototype. In the traditional manner of management, once NASA produced something that could fly after a fashion and demonstrated that the technology was fundamentally sound, the government decided that building the real version wasn't really that high a priority after all (at least not high enough to commit to finishing any of the next-generation spacecraft projects).
That would be true if it wasn't for gravity and aerodynamics adding to F. Imagine a spaceplane with wings and with engines that can indefinitely deliver 1G of acceleration: If it tried to launch straight up, it would never make it off a launch pad, but taking off from a runway it could reach orbit
This was touched on in my "aerodynamics" statement near the end of my original post. What actually happens is that a winged craft gets a lift that's a multiple of their thrust instead of just equal to their thrust. In theory you can make this as large a multiple as you like, but in practice craft geometry limits it. In theory you can use a space plane to take off in a sprial trajectory with low thrust the whole time, but in practice you spend most of the trip in a regime where engines are very difficult to build and atmospheric heating is a huge problem. So, we build high-thrust rockets instead, and ignore the atmosphere.
Building a rocket engine with enough thrust is a challenge, but it's largely a solved problem. The big engineering problem is the craft's fuel:dry weight ratio (and by extension fuel:cargo ratio), which isn't really a flight-path concern. Space planes are attractive not because they have a lower thrust requirement, but because getting your oxidizer for free gives you a far, far better specific impulse for carried reaction mass than carrying fuel+oxidizer does, which addresses the fuel:dry weight ratio.
In summary, your comments don't really affect the point of my original post much.
This is where you are confused.... If a shuttle takes off like a plane it doesn't have to fight against gravity to gain velocity.
If it's _climbing_, it sure does.
If it's flying level, it has to overcome atmospheric drag, which is rather substantial even below the speed of sound, and is ludicrously high at near-orbital speeds. There's a reason a 747 has to carry jet fuel.
Once it has a solid velocity it can work just like a plane and take off while starting to go at an angle and ultimately straight up. There would be a tremendous amount of energy savings doing it this way
Virtually all of the delta-v for the shuttle is that needed to accelerate the rocket tangentially (horizontally). Orbital velocity is 8 km/sec. Delta-v required to climb to orbital _altitude_ is far lower (look at the X prize for an example, though anything orbiting at 100 km would still have enough atmospheric drag to de-orbit very quickly).
In summary - what takes the fuel is horizontal acceleration, mostly outside the atmosphere. All other parts of the course are optimized to burn as little fuel as possible _getting_ to a place where the orbital burn can be done.
Can anyone give a quick calculation of how much material from space can be brought back to Earth before adversely affecting our orbit? "An unfathomable amount" doesn't count.
If the rockets bringing the material to us match Earth's velocity before dropping the material off, an infinite amount (or at least, up to 10-20% the mass of the _Sun_, before the center of mass of the Earth-Sun system changes enough to affect our orbit).
You could pile on at least the current mass of the Earth before gravity increased enough to be a serious problem.
If you're asking "how big an object could smack into earth before its orbit is affected", the answer is "more than big enough that far smaller objects would reduce the surface of the earth to a magma field and maybe give us a new moon or two in the bargain". Motion induced by Earth's gravity doesn't count, because the centre of mass of the system is still pretty much the same - this refers to something plowing into Earth from an asteroid belt transfer orbit without being slowed down first. Nobody's going to do that, because we don't want to reduce the planet's surface to a magma field. The actual amount of mass you'd need depends on the impact velocity, but is at minimum comparable to the mass of the moon (about 1% Earth's mass).
In summary, for any reasonable asteroid-recovery scheme, there is zero effect on Earth's orbit.
I've never understood why a shuttle takes off from a completely vertical position. I mean, doesn't it take the greatest amount of force to set an object in motion, rather than keep it going?
I'm not sure where this idea comes from.
Any given acceleration requires the same amount of force no matter how fast you're going. F = ma.
When you're moving in an atmosphere, you have to add force to counter air resistance as well, which goes up roughly as the square of airspeed.
The shuttle boosts upwards to get out of most of the atmosphere as fast as it can. Then it thrusts sideways, because it's sideways velocity that puts you in orbit. Taking off at an angle would just mean there'd be that much more atmosphere to plow through.
Aerodynamic craft with air-breathing engines _might_ be able to derive benefit from being in the atmosphere, but the shuttle's a brick strapped on to a bigarsed rocket booster, so it doesn't.
But when increasing the magnetic field strength or decreasing it, you'd run into problems with ions and electrons hopping field lines or effects such as Bremstrahlung radiation from changing the angular momentum as your ions and electrons orbit a field line of varying strength.
This limits the number of burns you can do (due to limiting the number of field changes), but I don't anticipate this being a huge problem.
Drift within the field would occur from scattering no matter what, limiting the containment lifetime you can achieve. This places a design constraint on the field - time for reaction has to be less than time for escape, for any given ion. This turns out to be fairly easy to satisfy.
The big problem is that you only really want to heat up the plasma you'll be expelling from the field; the stuff you want to hold onto is most easily held when cold (and heating the plasma gives you density problems, inhibiting reaction). It'll probably turn out that a more complicated field geometry that involves pinching a small fraction of the plasma is best (unless you want to blow through all of the fuel in one burn).
Re. radiation, I'd worry more about synchrotron radiation than Bremsstrahlung. Bremstrahlung is only important when you're imposing a very strong acceleration on the charge (i.e. smacking it into a solid target).
This may not ever be a practical drive (or a competitive one, compared to electric), but it's definitely an _interesting_ one.
Slashdot Mirror
That the Earth's core is not molten sodium, nor is it made of stainless steel, this is a pretty poor experimental model, but, hey, I'll bet the grant money was pretty good.
Considering that magnetic field generation depends only on the pattern of fluid flow and the fact that the fluid is conducting, I'd say this is actually a pretty good experimental model. See my previous post about why it's really handy to have a dynamo you can change the parameters of.
That theory is treated with serious skepticism for a reason. (Well, lots of reasons, really.) I can recall having this discussion here before and I forget the details of the theory, but I recall that the author showed an accute lack of understanding of planetary science among other things. (Jupiter is unlikely to have much more of a given metal than the Earth, oddly enough. The core is only at most about 10 Earth masses, and that's mostly ices. Also, the reactor theory doesn't explain field reversals or why the Sun has a field while dynamo theory explains both fairly naturally.
Actually, while the original poster's linked model is indeed bunk, it turns out that many of these objections aren't entirely accurate.
For one, the model doesn't dispute that the field arises from a dynamo. All it disputes is the nature of the heat source driving it (near-critical ball of uranium vs. a mixture of radioactives in far subcritical spontaneous decay mode). The mechanism for setting up the field is the same.
For another, if the model's tenets are accepted, field reversals aren't mysterious. The dynamo is shut down and restarted; there's no reason for it to restart with the same field orientation as before. All of the core material is far past the Curie point for holding a residual field, so I'd expect the restarted orientation to be random (constrained only by how the earth's rotation axis affects dynamo flow patterns).
What I find dubious about the model are the claims that a) lithophyllic elements like uranium would be concentrated in the core material, and b) material would diffuse preferentially towards the core strongly enough to result in fractioning, as opposed to just slightly increased concentrations. kT is big, and gravitational potential energy change with location is small down there, so I'd expect material to diffuse anywhere it pleased.
As far as Jupiter is concerned, I can't find references that say that the "icy" chemicals are in the core. As jupiter is expected to be molten throughout (as far as I can find), I'd expect them to diffuse out. Most sources say that carbon and nitrogen are mostly bound as methane and ammonia above the layers of liquid hydrogen. Some of the oxygen is bound as water in the atmosphere, and some of it as silicates in the "rocky" part of the core (which is presumably fractioned into silicates on top of a [molten] iron inner core, as in Earth).
Moot point re. the original article, of course, as you are definitely correct about the rocky core's mass.
Just in your post, I can say that it's unlikely that the field would stop because of build-up of wastes. For one thing, the wastes would either build up or they'd continually be lost. If they *did* build up, they'd slow the reactor down which would cool the system, leading to more sluggish convection and less mobile atoms. That would tend to freeze the wastes in place, not remove them.
My understanding was that the model proposed that they built up, shut down the core, froze in place, kept the core shut down until they decayed enough for the core to be near-critical again, and then dispersed as the hotter core allowed for faster diffusion away from the reactor area. Still pretty dubious, but I'd want to see a fairly detailed model of temperature, reaction rate, and mobility changes before writing that aspect off as outright impossible.
I don't see how measuring the effects on a 10-foot diameter sphere (filled with Na) can be equivalent to the effects on the central core of a 6400km-radius ball of rock (filled with many different elements). If they want to figure out more about the Earth's magnetic field, I suggest they take measurements, etc... on the EARTH.
The nice thing about building our own sphere of molten metal is that we a) know its structure and composition in detail, b) can put sensors inside, and c) can alter parameters (temperature gradient, rate of spin) and see what happens. None of these are practical for Earth, though we do have a reasonably good idea of what its composition and large-scale internal structure are.
The patterns of motion they're setting up are common to a very wide range of fluid systems - you don't need something as big as Earth to generate them. It's very hard to measure fluid flows and magnetic fields deep within the earth (all that's easy is density change boundaries), and the Earth's field isn't likely to flip within our lifetimes (or the next several centuries, minimum, even if the wierdness we're seeing _does_ represent the start of a flip). A small-scale mock-up run in the same turbulence modes that the core has will flip many times during the course of observation, and tell us a _lot_ about how the flipping occurs.
In short, we'll learn a lot more about the geomagnetic field from this experiment than we would from more studies of the Earth itself.
I dont think its a "technical issue aka sorry we cant do it", but a willingful decision of delay to not let "critical material" of any kind spread as fast over the number one info-pool as it otherwise really could
Stop and think about this for a minute.
Do you have any idea how _huge_ an amount of effort it would take to screen images indexed and search terms and tweak them so that no images "harmful to the administration" came up?
When it takes this much effort, and there's nobody holding a gun to their head, and they have competitors gaining mindshare, why the _hell_ would Google bother with this? Their primary purpose is to make money, not please Republicans, and they're going to be around a lot longer than Bush will be in power!
The line is that their "news" images cycle out of the index quickly, and I can certainly believe this - after all, if I'm searching for newsfeed images, chances are I'm asking about something that happened recently.
Trying to stage a cover-up of the type suggested would be very expensive and not a good business strategy.
There was a time when different computers ran on different processors, and supported different OSes. Now what's happening? Itanic and Opteron running Linux seem to be the only growth players in the market; and the supercomputer world is completely dominated by throwing more processors together. Is there no room for substantial architectural changes? Have we hit the merging point of different designs?
At the high level, things will always look similar. You can write Fortran and have it compile regardless of whether you're working on a RISC machine or a CISC machine, a register-rich machine, a register-poor machine, a three-operand R-R machine or a memory-based stack machine. The only thing you _might_ notice is changes in the communications topology, because it changes how you'd split up the problem, but that's not a processor issue (it's a network/interconnect issue).
That having been said, there does seem to be a convergence within processors themselves. Much of this stems from very fundamental design constraints. It's easier to pipeline instructions if they only do one thing, so instruction sets either get RISCian or get translated into something RISCian. It's easier to access local storage instead of non-local, so everything has a register file and a cache hierarchy. There's demand for parallel execution of SIMD-style computations, so most things support that. Everything works better if you have an unbroken stream of independent instructions, so processors try their hardest to mask latency of things like branches and memory accesses through speculation, and re-order instructions to mask dependencies. The only technology that wasn't really used much for this was symmetric multithreading (SMT), which gets you a stream of independent instructions by pulling them from multiple threads, but this has finally trickled down into the mainstream. So, processor cores contain the same kind of fundamental feature sets by necessity. We're going to continue to see this, for example with the emergence of so many chip multiprocessing (CMP) offerings, where putting multiple copies of a core on die is a better use of space and power than trying to build (and feed!) a more complex single core or adding more cache.
The devil is in the details, though. The instruction set architecture of x86 offerings is a very large mess with several inconvenient anachronisms, which takes working around. The PPC ISA is a bit cleaner in that regard, but I'm sure it has its own quirks. Itanium (1, at least) struck me as an experimental test bed for every bizzare instruction set feature they could think of, some of which may even pan out. If there's a chip that's pushing architectural boundaries, that's probably it (pity that it didn't help it much).
However, unless the nature of the tasks being asked of a microprocessor changes drastically, or unless someone comes up with a really fundamentally different way of structuring data flow for problems, processors will continue to look more or less the same, even if the underlying fabrication technology ends up changing drastically (which I doubt it will in the next decade, at least).
I'm less excited by a supercomputer with 10k processors than I would be by one containing as few as 64.
The problem is that if you can build a supercomputer with 64 processors, you can build an even better supercomputer by wiring a bunch of 64-processor nodes together. Yes, you're increasingly communications-bound, but there are enough (useful!) problems with relatively low communications overhead for this option to still be attractive.
Interestingly, this is increasingly the case for single processor machines as well. They're getting multiple cores on-die, because both increasing the complexity of a superscalar core and devoting added real estate to cache have reached diminishing returns. This trend will only continue.
As far as I know I don't think anyone has been able to demonstrate lasing in silicon nanocrystals. Gain has been demonstrated but too many issues arise that prevent lasing. Also, electrical pumping is pretty much impossible at since the nanocrystals are embedded in an insulator (SiO2). Anything based on optical pumping will never be cheap and scalable.
This wasn't silicon nanocrystals - this was microstructures (though "micro" is a misnomer at scales this fine) in bulk silicon. Electrically driven silicon LED-type structures (being used for illumination for an image sensor chip, for the particular demo I'm thinking of; I'd have to dig for the citation [Japanese university, a year or two ago]).
The problem with using III-V's or any other 'exotic' material system is how do you package it with silicon based technologies.
You wouldn't. You'd fab the whole chip, logic and all, in a GaAs technology. You'd only do this if you wanted optical communication badly enough to take the cost hit for doing this. I can see it for niche applications; before SiGe and plain old Si caught up, some of them had GaAs components.
You can also do GaAs epitaxial layers on a Si-process chip, but that's almost as ugly cost-wise as doing a GaAs chip.
A laser on silicon essentially solves the wiring problem of traditional digital integrated circuits (ICs). Modern digital ICs consist mostly of wires; a small percentage of the silicon area is the transistors that perform the computation.
Not true last I checked, and I am presently doing IC design. Yes, you need plenty of space for your routing channels, but especially with the number of metal layers we have now, there's plenty of space _above_ the active circuitry even after you take out the layers used for routing within the gates.
Two problems arise. Driving a signal from one end of the chip to the other end is very slow because the wires present a high RC load to the puny transistor. The other problem is simply routing the wires.
The RC load problem is only _severely_ nasty if you lay out the bus as one long wire. If you segment it and put repeaters, time scales as length, not as length squared. You can also pack adjacent data stages more closely together as linewidth decreases, so chip shrinks continue speeding things up.
Routing is only a crippling problem if you're trying to do an anywhere-to-anywhere communications mesh. Even then, there are well-known topologies that minimize pain. This is part of why the movement to multi-core chips is happening - a massively superscalar chip _does_ have to route results from any part of the chip to functional units at any other part. Smaller cores in parallel are a win/win scenario (simpler design, easier communications).
See above re. routing. Routing is actually _easier_ now than it was a decade ago, because we have six or more metal layers to do it in rather than two or three. For a pipelined data flow, the routing complexity between stages doesn't really _increase_ with chip size. It's aggressively superscalar designs that do that, and those reached their peak complexity a few years back (with emphasis shifting to multi-core now).
The laser solves the first problem because we can simply transmit a bit (0 or 1) by modulating the laser light. The bit will travel at the speed of light.
Electrical signals travel somewhere between 10% and 50% C, usually. The real problem is capacitive loads, and an electro-optic system has to deal with those too, believe me. Electro-optic systems will actually have it _worse_, because you need large photosensitive structures to pick up the light (more capacitance), and have relatively small photocurrents to charge or discharge them with. You no longer have electric networks with huge fan-out (and large capacitance), but if you build a segmented hierarchical scheme, you don't with an electrical implementation either. And you get an _optical_ fan-out in return - you're only producing so much light, and it has to be split among N potential receivers.
Light is very far from being a magic bullet for intra-chip communication.
The laser also solves the second problem because there is no need to route the optical paths. The light from one laser can cross the path of light emanating from a second laser and can continue, unimpeded, to the detector intended for the first laser.
This turns out not to be the case. Your emitters are small enough that diffraction will spread out the beams quite a bit. So, you're either using a broadcast system (which reduces your communications bandwidth drastically - you only have one channel shared among all components), or you build waveguides. Waveguides have to be routed, and have the same kind of crossover problems wires have. They're actually a bit worse, as they have more constraints on geometry than a low-current signal wire does.
In summary, I don't think that optical communication works as well as you think it does, and the problems you note with electrical communication are largely solved.
And at this point there is no other easy way to make a silicon laser using anything other than the raman effect. Any other method would require the use of exotic materials (i.e. erbium, heterojunctions, etc.). It's been tried and the results aren't all that promising.
Actually, it turns out that if you can produce structures small enough, you can get silicon acting like something closer to a direct-bandgap material (you no longer have a crystal of near-infinite extent, so energy level analysis changes).
The best I've heard of is efficiencies in the single-digit percent range, though.
I think anyone actually building an optically-communicating chip would just use gallium arsenide (there's enough of an infrastructure for it to be practical).
Modern electronic computers are getting closer to being optical in any case (gigahertz range).
Could someone explain this to me? I don't get it.
It refers to a couple of things.
One is that people have been talking about using optics to route signals on motherboards for a long time, as high-frequency electrical signals are a pain to keep clean over the relatively long distances invovled. I'm skeptical of this happening any time soon, for the same reason I'm skeptical of CMOS-on-silicon dying any time soon: the technologies are still scalable, a vast amount of study has produced a very good understanding of them, and we already have all of the tools we need to produce devices using them. An optical scheme would involve considerable retooling and a considerable learning curve. One of the important pieces of an optical communications scheme for electrical chips is good, fast, and cheap electro-optic transcievers. Cheap means implemented on silicon, on the same die as the logic elements. Receivers are no problem, as photodiodes work fine in an indirect bandgap material, but transmitters are very difficult (you want a direct bandgap if you're trying to produce an LED or a semiconductor laser). This paper shows a way of producing a semiconductor laser on something resembling a conventional silicon CMOS process (though I'd have to read the paper carefully to see if they did any tweaking). The catch is that I'm not sure if they're producing light in a band that can be picked up by a silicon photojunction (I _think_ they are, but would have to read the paper in detail).
The second thing the line could be referring to is that the distinction between an electrical signal on a bus and a microwave signal in a waveguide gets a bit blurry as frequency goes up. However, that's definitely overstating the case for the time being. If you were designing motherboards to use waveguide style signal transmission, they'd be set up quite differently. Right now, microwave emission is an unwanted side effect, and is for the most part minimal (it causes crosstalk and illegal RF/microwave interference).
You won't compete performance-wise with high-end consumer 3D cards. You won't compete budget-wise with low-end consumer 3D cards. You're going to have crappy Windows drivers unless you wave money in front of your developers to work on that uninteresting part and _maintain_ it, _and_ shell out for the Microsoft developer packages for this sort of thing.
Your revenue? Linux geeks who are patriotic enough to pay for a product with less bang for the buck than a standard commercial card, and who will take the promise of eventually-less-buggy drivers some time in the future as being more valuable than a buggy but adequate and fast 3D driver now.
The thread makes mention of hardware cost control, though they're having serious trouble making that competitive (hard to beat quantity-millions for bulk rates). However, Alan Cox's message highlights a serious problem - you have a lack of programmers for cards that specs are already known for.
The only realistic solution I can think of is to pay coders to produce a minimum adequate driver implementation for the new card (or heck, even one of the old ones). Making a decent accelerated 2D driverfor an experimental card is a few person-months of work, if memory serves. Making a decent accelerated 3D driver is a few person-years of work. The budget for this is within reason, but still has to come from somewhere. As there isn't a deeply pressing need for this being felt by most people (see previous point), the pace of volunteer development will be slow (as is shown by Alan Cox's comments about current driver projects).
I'm not suggesting taking this outside the open source community. I'm suggesting paying open source people enough that they can do this as their day job, and have _incentive_ to do this as opposed to some other interesting project.
This is the Big Problem. I can't stress it enough. Any easy way of implementing _anything_ to do with 2D graphics cards was patented a decade ago or more. Any easy way of implementing any basic 3D was patented more recently, but is still patented. Even crawling through the patent database to look for implementations that were missed will take a lot of time, and cost a significant amount of money (you need experts on graphics algorithms and VLSI design to do this, and patent lawyers to back them up; see previous point about volunteer time vs. needed schedule).
Big graphics companies solve this by doing the requisite grunt work, and aggressively patenting everything they can think of as a defensive measure. The standard way of solving patent conflicts is bitter litigation followed by cross-licensing relevant patent portfolios from each other (we've seen this in other parts of the hardware world often enough too). A low-budget open source card project won't be able to afford either of these, and both will eventually become necesary (someone will claim you're infringing no matter how clear it is you aren't, because it's in their best interests to make the claim).
In summary, the only way that I can see an open source graphics architecture being developed is if the community and donors scrape together several hundred thousand to a few million in startup capital to fund hardware and software development, and to deploy lawyers. A side benefit is that you might even be able to afford chip spins if you're on the high side of the funding scale, though it'd probably be more wise to divert the funds to multi-platform driver support and patent portfolio instead.
Variant options that come to mind:
The catch is th
This was alluded to by my "heuristic checker" comment, above. Downsides:
It does, however, help a lot catching the bad cheaters who _didn't_ hand in their assignments on top of each other.
You only catch bad cheaters, by definition.
The fact that I've seen so many bad cheaters, and that most of these assignments are easy enough that anyone with two brain cells to scrape together wouldn't need to cheat, leads me to suspect that the correct assignments are mostly legitimate.
I'm sure there are people who have cheated with a correct assignment that I haven't caught, but think - if you have a correct assignment, and will get full marks, why would you risk your own mark sharing it with some loser who can't do the assignment? And why _would_ you, as another poster pointed out, spend twice as much time reshuffling your assignment to look original as you could just doing the thing following the steps in the book?
I know that cheaters aren't rational (otherwise they wouldn't be wasting a course's mark cheating on an assignment they could outright blow off without substantial impact on their grade). However, the source of a correct assignment would be someone who can think, one hopes.
The surrogate I see among people who do hand in correct assignments is in-lab collaboration. They ask each other how to do X or Y thing that's troubling them (or they ask me, but I'm only there a couple hours a week). This results in assignments that are stylistically similar, but not close enough to be outright plagarism. I've watched people do this, so I'm reasonably sure that most of the "stylistically similar" reports are the result of conversation and not modification of "borrowed" assignments.
I'm told that cheating is endemic at some places. Thankfully, this doesn't seem to be one, yet.
I was hoping for something educational and instead I found a collection of jokes that I don't find very amusing.
This is intended to be educational. Rather, it is intended (at least in part) to be yet another thing to point first-year (and later!) students to, in the hopes that they decide to absorb it for a change. Give the advice in enough forms, and maybe one of them will take.
That, and it reads a bit like it was written to vent frustration. I know I can sympathize with a lot of what was expressed there (I've had to TA programming courses many times).
There are a few things that you can still look for, here:
This includes names, indenting, order of functions, spacing conventions, and so forth. Some similarity could be coincidence. Nearly identical style is very suspicious, especially if any of the other flags come up too.
Many assignments (like the ones I'm currently marking, for instance) require a short write-up explaining what they did. This may only be a few sentences, but people who cheat tend to either copy it word for word, or do a broken copy of it taking key words and trying to paraphrase the rest. Usually badly. This leads into the next point.
Two assignments. Both would fail on their own lack of merits, but curiously, they both made exactly the same set of errors, in addition to having very similar style. Not likely to be concidence, that. Especially since they were...
These assignments are put in a drop box. Electronically submitted assignments are usually datestamped. Cheaters, once they finish cheating, tend to submit at the same time (at least in this course). Finding two matching assignments in a stack of a hundred would take a good memory (or a heuristic checker). Finding two matching assignments that are right on top of each other, or within a few entries of each other, is much easier.
Despite the fact that it's _possible_ to cheat without detection, a large number of people don't. Remember, the people who are cheating are the ones who can't hack a first-year CS course. While there will be exceptions, the kind of person who can't figure out how to make "hello, world" or set up a very simple Excel spreadsheet, with the instructions in front of them, is probably not going to be very good at cheating either.
If, however, the professor assigned a creative problem solving exercise and a proper solution could take many different paths, 2 or more identical submissions would be a dead giveaway of cheating.
The problem is that it's very hard to do this in a way that's easy to mark. In an ideal world, that wouldn't matter, but in practice, some poor TA is going to have to try to mark 200 assignments in 3 hours. That's hard enough when they _are_ written to be easy to mark (I still wince at the memory of one marking assignment that involved digesting a 5-page report and then visually determining whether another 5 pages of non-trivial code worked or not).
In summary, despite the fact that we're stuck giving cookie-cutter assignments for practical reasons, the cheaters (that I see, at least) seem to be as bad at cheating as they are at doing the work.
>What's the point? They can already endure the vertical-launch G forces just fine.
you've just said it yourself, 'They' - as in they the astronaut/kosmonaut.
Put Joe Armchair in a flight suit on an acceleration couch, and he'll endure a few minutes of 3-4 G just fine too. The only people who can't are those with heart conditions or certain other specific disorders.
A 2nd point that can be derived from my 1st (from the above) - is greater forces that come into play, greater endurance and sturdier things have to be built - So there is a balancing-act between spend more/less on 'take-off costs' vs 'building costs'.
What I've been trying to get through to you is that the penalty for punching through more atmosphere is more than enough to offset this. You have to carry more fuel to give you the extra delta-v. This is in a regime (total delta-v greater than exhaust velocity) where adding extra fuel is very difficult and in fact requires that a _smaller_ fraction of the craft be structure, requiring multiple stages or very expensive materials.
So you can build a lighter craft if you launch straight up, unless you have something else (like a space plane's scramjet) that gives you an overwhelming benefit from being in the atmosphere. Even then, you get out of the _dense_ atmosphere ASAP.
Em', NO *again* - What I did is try to summarize the BASIC theories of BOTH methods (without trying to 'pick a favorite'...).
Now I'm pretty sure you're just trolling.
I've been _analyzing_ the merits and drawbacks of the various approaches since very early on, and have shown that the drawbacks of horizontal takeoff far outweigh the merits for any kind of conventional rocket (and have pointed out non-conventional types of rocket that would benefit).
Are you proposing some alternate approach to reaching orbit? Are you disputing any of the statements I've made? If the answer to these is "no", you can stop wasting breath. The "basic theories" have been summarized long since, and the "positives and negatives" have already been discussed.
In a vertical lift-off, the person(s) would have to endure a greatter amount of G-force due to the amount of force unleashed in a fraction of a second to achive the inertia needed to start lifting and contiune accelerating toward achiving proper amount of velocity(ies)...etc
The difference is at most 1 G. When you're boosting at 3-4 G, the delta-v loss from earth's pull while in vertical climb mode is small enough to ignore.
So, survivable astronaut acceleration is not much of a problem. These are trained pilots with flight suits to protect them, here.
In a horizontal lift-off, the person(s) wouldn't have to endure the same amount of G-forces, as in a 1st stage one would only have to achive the inertia to overwin the air/frition-resistance, and sure at a 2nd stage one would still have to overwin the Gravity-force that's keeping us so firmly on the ground to achive orbitit - but the main difference in this take-off method is that one can/could adjust the amount in inclination and therefor be able to control the amount of G-force the person(s) would feel/endure.
What's the point? They can already endure the vertical-launch G forces just fine.
What you don't seem to be realizing is that _any_ substantial angle from the vertical results in a _considerably_ longer path through the atmosphere, which costs you a _lot_ to plow through at high speed. Unless you have a very good reason to stay in the atmosphere - i.e., a space plane's scramjet engine - you're going to take off as close to vertical as possible until you're out of most of the atmosphere. This is exactly what the shuttle does.
In summary, you seem to be claiming a positive benefit that offsets a problem that isn't a problem, and to be overlooking a very large negative to taking off at an angle at low altitude.
Re. radiation, I'd worry more about synchrotron radiation than Bremsstrahlung. Bremstrahlung is only important when you're imposing a very strong acceleration on the charge (i.e. smacking it into a solid target).
I thought that's what was implied with a change in the field strength?
The accelerations involved in any kind of macro-scale displacement or compression of the fuel are far too low for bremsstrahlung to be significant. The minimum threshold above which you generally worry about x-ray emission from devices is around 10 kV, according to the electrical safety codes I've seen (though this is admittedly a pretty arbitrary value). This corresponds to a particle going from hundreds of km per second to zero in less than a microsecond. This kind of thing happens when particle beams or high-energy plasmas interact with stationary matter, and pretty much nowhere else.
As for heating the reaction, couldn't you hold a core of hot plasma and flow the colder stuff around it? Or actually burn some of the colder stuff to maintain a tightly wound magnetic field (via the currents generated by the burned fuel)?
The problem is this: You want to heat the plasma you're using as exhaust (you actually want it to be self-heating), but you want any plasma being stored for later to stay _cold_. The hotter it is, the lower its storage density and the faster it drifts out of your containment fields.
Hot plasma doesn't help your containment field, either. When you heat plasma in a magnetic field, it _expands_ and takes some of your field lines with it. This makes containment in the hot plasma bubble worse.
So, we either have a simple field where we react all of the plasma at once and let containment fail, for one big burn, or we have a complex field that lets us keep the plasma we don't want to burn just yet well away from the stuff that we do.
A secondary problem is that this plasma is _bad_ at self-heating. Electron/ion recombination releases its energy as light (EUV up to x-rays). You need to turn this light into usable energy, either as heat or as electrical energy. Plasma is reasonably opaque to UV if it's dense enough, so you may get it thermalizing, but it'll be iffy. X rays have a low enough interaction cross-section that you pretty much have to just use them to heat a solid containment vessel and get power for an electric drive off the resulting heat gradient.
A D-D reaction would work just fine there... of course you'd need some tritium to start it, but as long as you kept feeding dueterium into the thing, you'd sustain your reaction and be able to control the temperature better.
Fusion is a completely different problem than the ion recombination drive. For one, D+D fusion gives you mostly charged byproducts, so you have no problems making the plasma self-heating. For another, the plasma is insanely hot, so density is far lower and magnetic field strength has to be quite high if you don't want drift to kill it. Lastly, to get the reaction rate to anything useful for propulsion requires fields strong enough that you need magical materials for your field coils, and they _still_ end up being heavy enough that you're restricted to very, very low accelerations (at least in "use the fusion products as a high-Isp exhaust jet" mode - an electric drive would trade Isp off against acceleration more reasonably).
So, apples and oranges.
It seems to me that the geometry that you'd want for this would more closely resemble a spheromak than a tube. Unless you're talking about a pulsed FRC, that may do it, but the tearing of the field lines to get the FRC conditions would seem to be too energy intensive.
I'm using what's pretty close to an ordinary dipole, so none of the above. More exotic field geometries are needed when you're going for long-term confinement of a very hot plasma (spheromak, tokamak, etc), or when you're trying to use switchback currents to do plasma heating (schemes that involve field line
It comes from the myth of "escape velocity". People figure, hey, why not just fly horizontally until you hit escape velocity, and then up you go, instead of trying to reach escape velocity vertically.
Actually, thrusting horizontally is the perfect way to reach orbit (and this is largely what the shuttle does now). Orbital velocity is tangential; an escape trajectory is a very different beast (can be thought of as the limiting case of a parabola or a hyperbola as perigee (backtracked along the course) approaches the centre of the earth).
What puzzles me is people who think flying horizontally is free, or lets you climb for free, or magically reduces by some large fraction the delta-v required to reach orbital velocity.
If you are climbing as a plane does, you get to use the air to help you, rather then against you...
No, you don't.
An airplane turns horizontal motion into lift when it climbs. You need to keep thrusting in order to keep climbing.
As mentioned elsewhere, there are factors that can give you an efficiency benefit if you play your cards right, but you seem to fundamentally misunderstand the nature of flight, as far as I can tell from your posts.
Also, your quote about "orbital velocity is 8km/s" depends on how far out from the earth you are orbiting. You can orbit at theoretically any elevation as long as outside gravital forces aren't effecting you with any sort of substantiality.
To _get_ to that height, you end up needing more delta-v than you'd need to orbit lower.
The actual relation is that to make an altitude change, you need to have kinetic energy equal to the difference in gravitational potential energy between the two altitudes, and to hold a circular orbit at any given altitude, you need kinetic energy equal to the binding energy, which is _half_ the difference between your GPE at that altitude and your GPE at infinity (defined to be zero).
So while something in geosync is orbiting at only a few km/sec, getting to geosync takes somewhere in the ballpark of 10 km/sec delta-v. That's why payload ratings to geosync for commercial boosters are lower than the payload ratings for LEO (check the various launch companies' web pages some time; they love to talk about what their rockets can do).
One of the major energy wastes of the shuttle are the first 10 km of its ascent. Here, the atmosphere is thick enough that it faces a large amount of drag - and this is the part of the atmosphere it goes supersonic in. Comparing the concept behind X-15 and more recently SpaceShipOne, a subsonic transport lifts the craft to a higher altitude, taking it out of the thick part of the atmosphere up to an altitude where acceleration and altitude give it a much better drag configuration. This, in turn, allows the craft to fly off using a much smaller energy expenditure on the first part of its acceleration.
My understanding was that the initial part of the launch path appears wasteful because, as an early part of the launch course, the craft spends so much more time there (it's still moving slowly, because it takes time to reach mach-bignum even when you're accelerating at 3 gravities). A more useful efficiency metric would be average acceleration (delta v achieved across a given time interval, not distance interval).
I'd think that drag losses would be minimal at the beginning of the ascent, as the craft isn't moving very quickly. There's another argument based on the mass per unit cross-sectional area of the shuttle and of the atmosphere column it punches through that places an upper bound on the amount of extra impulse needed to get through it at higher speeds.
As an aside, the space shuttle is a shoddy old piece of gear, designed and built in an unsafe manner, and thus, as a result, unsafe. It is an over-engineered boondoggle, capable of much more than it needs, and as a result, much less reliable than it should be.
The shuttle is an experimental prototype. In the traditional manner of management, once NASA produced something that could fly after a fashion and demonstrated that the technology was fundamentally sound, the government decided that building the real version wasn't really that high a priority after all (at least not high enough to commit to finishing any of the next-generation spacecraft projects).
That would be true if it wasn't for gravity and aerodynamics adding to F. Imagine a spaceplane with wings and with engines that can indefinitely deliver 1G of acceleration: If it tried to launch straight up, it would never make it off a launch pad, but taking off from a runway it could reach orbit
This was touched on in my "aerodynamics" statement near the end of my original post. What actually happens is that a winged craft gets a lift that's a multiple of their thrust instead of just equal to their thrust. In theory you can make this as large a multiple as you like, but in practice craft geometry limits it. In theory you can use a space plane to take off in a sprial trajectory with low thrust the whole time, but in practice you spend most of the trip in a regime where engines are very difficult to build and atmospheric heating is a huge problem. So, we build high-thrust rockets instead, and ignore the atmosphere.
Building a rocket engine with enough thrust is a challenge, but it's largely a solved problem. The big engineering problem is the craft's fuel:dry weight ratio (and by extension fuel:cargo ratio), which isn't really a flight-path concern. Space planes are attractive not because they have a lower thrust requirement, but because getting your oxidizer for free gives you a far, far better specific impulse for carried reaction mass than carrying fuel+oxidizer does, which addresses the fuel:dry weight ratio.
In summary, your comments don't really affect the point of my original post much.
This is where you are confused....
If a shuttle takes off like a plane it doesn't have to fight against gravity to gain velocity.
If it's _climbing_, it sure does.
If it's flying level, it has to overcome atmospheric drag, which is rather substantial even below the speed of sound, and is ludicrously high at near-orbital speeds. There's a reason a 747 has to carry jet fuel.
Once it has a solid velocity it can work just like a plane and take off while starting to go at an angle and ultimately straight up. There would be a tremendous amount of energy savings doing it this way
Virtually all of the delta-v for the shuttle is that needed to accelerate the rocket tangentially (horizontally). Orbital velocity is 8 km/sec. Delta-v required to climb to orbital _altitude_ is far lower (look at the X prize for an example, though anything orbiting at 100 km would still have enough atmospheric drag to de-orbit very quickly).
In summary - what takes the fuel is horizontal acceleration, mostly outside the atmosphere. All other parts of the course are optimized to burn as little fuel as possible _getting_ to a place where the orbital burn can be done.
Can anyone give a quick calculation of how much material from space can be brought back to Earth before adversely affecting our orbit? "An unfathomable amount" doesn't count.
If the rockets bringing the material to us match Earth's velocity before dropping the material off, an infinite amount (or at least, up to 10-20% the mass of the _Sun_, before the center of mass of the Earth-Sun system changes enough to affect our orbit).
You could pile on at least the current mass of the Earth before gravity increased enough to be a serious problem.
If you're asking "how big an object could smack into earth before its orbit is affected", the answer is "more than big enough that far smaller objects would reduce the surface of the earth to a magma field and maybe give us a new moon or two in the bargain". Motion induced by Earth's gravity doesn't count, because the centre of mass of the system is still pretty much the same - this refers to something plowing into Earth from an asteroid belt transfer orbit without being slowed down first. Nobody's going to do that, because we don't want to reduce the planet's surface to a magma field. The actual amount of mass you'd need depends on the impact velocity, but is at minimum comparable to the mass of the moon (about 1% Earth's mass).
In summary, for any reasonable asteroid-recovery scheme, there is zero effect on Earth's orbit.
I've never understood why a shuttle takes off from a completely vertical position. I mean, doesn't it take the greatest amount of force to set an object in motion, rather than keep it going?
I'm not sure where this idea comes from.
Any given acceleration requires the same amount of force no matter how fast you're going. F = ma.
When you're moving in an atmosphere, you have to add force to counter air resistance as well, which goes up roughly as the square of airspeed.
The shuttle boosts upwards to get out of most of the atmosphere as fast as it can. Then it thrusts sideways, because it's sideways velocity that puts you in orbit. Taking off at an angle would just mean there'd be that much more atmosphere to plow through.
Aerodynamic craft with air-breathing engines _might_ be able to derive benefit from being in the atmosphere, but the shuttle's a brick strapped on to a bigarsed rocket booster, so it doesn't.
But when increasing the magnetic field strength or decreasing it, you'd run into problems with ions and electrons hopping field lines or effects such as Bremstrahlung radiation from changing the angular momentum as your ions and electrons orbit a field line of varying strength.
This limits the number of burns you can do (due to limiting the number of field changes), but I don't anticipate this being a huge problem.
Drift within the field would occur from scattering no matter what, limiting the containment lifetime you can achieve. This places a design constraint on the field - time for reaction has to be less than time for escape, for any given ion. This turns out to be fairly easy to satisfy.
The big problem is that you only really want to heat up the plasma you'll be expelling from the field; the stuff you want to hold onto is most easily held when cold (and heating the plasma gives you density problems, inhibiting reaction). It'll probably turn out that a more complicated field geometry that involves pinching a small fraction of the plasma is best (unless you want to blow through all of the fuel in one burn).
Re. radiation, I'd worry more about synchrotron radiation than Bremsstrahlung. Bremstrahlung is only important when you're imposing a very strong acceleration on the charge (i.e. smacking it into a solid target).
This may not ever be a practical drive (or a competitive one, compared to electric), but it's definitely an _interesting_ one.