However, a lot of articles have been popping up in New Scientist essentially calling Methanol a demon fuel. It takes more energy to produce than it generates. By the time you use fertilizers, transport the stuff to the processing plant, run the plant, transport it to the pumps you've used more of the stuff than you can produce!
This sounds like Oil industry propoganda, but its getting a lot of column inches! anyone know anything?
For generating methanol from biomass, that might even be true. However, you have a lot of spare biomass left over from growing grops for food and fodder, so you could get *some* fuel "for free".
If you're generating methanol by direct sythesis, a) you're much more efficient (far fewer steps, and far less waste material synthesized), and b) you're using it as a storage medium for some other energy source (like solar or nuclear), so you aren't having to expend methanol to produce methanol.
I understand that this says basically that it moves away from walls when it contacts them, but I can't figure out for the life of me what a "disc cam in cage" is, or how this would help it push off of the wall?
Pure speculation, as I haven't seen pictures of the thing either, but - if the "cam" is a heavy disc mounted on an off-center axis, turning it would change where the center of mass of the robot was. This would push the surrounding "cage" (and the rest of the robot) in the opposite direction. If you just want translation instead of rotation, you'd use two off-center cams and spin them in opposite directions (pure mass shift, no net application of torque).
If you had a setup like this, you could rig it to "jitter" (push the cage in one direction when the cams' center of mass goes in the other) whenever it touched a wall, to push off of the surface.
My father runs a small business, and had to rack a few systems. He just bolted together some Dexion angle-iron and put on plywood shelves.
Dexion ( http://www.dexion.com ) makes all kinds of shelving-related stuff. Their angle-iron looks like giant pieces from an erector set; sturdy L-cross-section steel beams with holes drilled in them. Bolt them together, and you can build just about anything you want. It's fairly cheap, and works very well for racking PCs or just about anything else.
These mirrors flip up and down mechanically, right? That can't be much faster than KHz, whereas electronics switch on the order of MHz, I thought...
You could move a macroscopic mirror at a few kHz. Mirrors fabricated to be a few microns across can be switched much, much more quickly.
Even if your packet rate still ends up being much faster than the speed at which you can switch the mirror, you could still use this to eliminate a lot of decoding during routing. Instead of a box with N network attachments that decodes incoming traffic and sends it to x, y, or z destination as appropriate, you have a MEMS box that has one connection pattern for the first millisecond, another connection pattern for the next millisecond, and so on. If the routers generating the traffic are intelligent, they can group packets for a given destination into bursts so that they're routed automatically through the optical MEMS router. Alternatively, you could group packets and put a duration and a destination-identifier tag on it at a lower data rate. Embedded electronics in the MEMS chip can read the destination and move the mirror to the correct position for the duration of the burst of packets.
This won't eliminate the need for all electronic processing, but it will make several aspects of routing at high data rates much easier.
but then they go and claim that mirrors are wavelength insensitive. Perhaps regular mirrors are, but aren't high reflectivity mirrors wavelength sensitive (using interference effects from thin film coatings)? If they didn't use high reflectivity mirrors, wouldn't there be a huge loss to this switch?
Not really. You can always put an optical repeater (read: erbium-doped fiber laser) on all outgoing ports to compensate for dimming. You have to do this on long fiber runs anyways.
Another explaination might be that the stars are young and therefore cool, but I couldn't say that for sure either.
It turns out that there are certain spectral features (element emission/absorption lines) that occur at the same frequency no matter what temperature the object producing them is at. If this pattern of lines is shifted, you know that the colour is due to a real redshift and not a temperature difference.
I suppose that if something like Planck's constant was different at the time and location of the stars, that would also produce an emission line shift, but it's far more likely that the light has just been redshifted.
In short, I'd take a very careful look at the benchmark code and methods of compiling before making conclusions about VectorC's performance. It might still be great; however, past benchmarks that have been floated have been questioned.
DISCLAIMER: I have not used VectorC, or directly examined the test code or assembly code generated for any of the tests. I have no direct assessment of the benchmarks - I'm pointing to others' assessments in response to another article about the compiler.
Re:Scaling problems. Very nasty scaling problems.
on
Peer-to-Peer Cellular
·
· Score: 2
You want a more rigorous illustration of why you get congestion? Fine:
That's no more rigorous than before. It's the same example and analysis that I already showed to be flawed, just worded a little differently.
Bushwa.
You're trying to make a call from phone A to phone B. The distance between the phones is an average of K times the range of phone-to-phone communication. How, pray tell, do you plan to do this in fewer than an average of K hops?
You have N phones, and O(N) calls. You have, therefore, O(KN) communications hops in total to service all calls. How, pray tell, do you plan to distribute O(KN) relays among O(N) phones without at least an average of O(K) relays being serviced per phone?
You have yet to provide a convincing argument (or any argument) against this. You seem hung up on me assuming a "rectilinear grid", which I did *not* do in my previous message.
I respond perfectly well to well-reasoned debate, and have admitted error many times in the past when presented with evidence or counterexamples. You have provided neither. Please do so.
Re:Scaling problems. Very nasty scaling problems.
on
Peer-to-Peer Cellular
·
· Score: 2
These assumptions all combine to paint a much uglier than necessary picture, as we'll see. To deal with the most obviously stupid assumption first, consider that connectivity is actually a product of range and node density. Sure, you won't find many neighbor nodes if you have a hundred devices spread across the entire state of Montana. However, if you have several hundred thousand units within the confines of New York City - our original example - you're likely to find hundreds of potential neighbor nodes even if your range is quite small.
This does not affect the order of the problem. It just affects the proportionality constant when translating O(sqrt(N)) into an actual hard number. Connectivity within a node isn't relevant to the problem. See below before trotting out your formula again.
This brings us to the grid assumption. You're assuming that nodes are incapable of "skipping" a row or column in your unnecessarily-rectilinear grid, but in reality that's not likely to be the case. If I have a couple of hundred potential neighbors, I'd have to be an idiot to route everything only through the ten nearest
I'm already assuming you're routing to the *farthest* possible cell phone. Which is in the adjacent *node*. A node, in my previous post, is a *group* of cell phones.
You want a more rigorous illustration of why you get congestion? Fine:
You have a large area containing cell phones, with very short communications range. You have random point-to-point communication requests within the large area.
Draw a stripe through the middle of the area, with a width equal to the phone-to-phone communication range. About half of the total phone traffic connects people on opposite sides of the stripe.
All of this communication must be routed through phones within the stripe - it's wide enough that you can't just skip over it.
The number of calls/message channels routed through the stripe is proportional to the number of phones, which is proportional to the area (we're in a city with phones uniformly distributed).
The number of phones within the stripe is proportional to a constant (the phone-to-phone range) times the *diameter* of the region - which is proportional to the square root of the area of the region (and hence the square root of the number of phones).
Thus, you end up with a number of communication channels proportional to the total number of phones being routed through a stripe containing a number of phones proportional to the square root of the total number of phones. Average number of channels being routed through any given phone on the stripe is proportional to the square root of the total number of phones.
This holds as a fundamental limit regardless of the number of phones that any given phone can contact, and regardless of the routing algorithm.
Now do you see where I'm coming from?
Lastly, let's consider the assumption that you'd always be routing exclusively through other mobile nodes? Why?
Because that was what the article was suggesting be done.
If I'm allowed to use fixed towers, I'll just make them have as large a range as bandwidth lets me (to widen the stripe that things have to be routed through), and use very high capacity links between towers (so that high load isn't as serious a problem), and force all phone traffic to be routed through them. And maybe use something other than a mesh-style topology for tower-to-tower routing, if I have high enough capacity data conduits, as there's no range limit for tower-to-tower communication if I'm running fiber instead of broadcasting. But all of this dispenses of the idea of a magical phone-based decentralized network, which the article's authour was so enamoured with.
Re:Scaling problems. Very nasty scaling problems.
on
Peer-to-Peer Cellular
·
· Score: 2
Wrong. Traffic per node in an N-node network is proportional to log(N) - the log base being the average connectivity - not sqrt(N). For a million-node network with average connectivity of four, that's the difference between your figure of 1000 and a correct figure of 10.
You are making flawed assumptions about the nature of the network.
A cell phone's range, when communicating with another cell phone instead of a tower, sucks. You can model the resulting network as a large grid of cells, with a cell's size being the communications range of a cell phone to another cell phone.
Assume you have a large grid. Assume that people are communicating between random points within this grid.
Traffic only flows to neighbouring cells - your range sucks, as mentioned.
Draw a partition down the center of this grid. Half of your traffic will cross this partition (given random sources and destinations).
If everyone is on the phone, and you have N cells, you have O(N) communications channels, half of which cross the partition, being routed through a region containin O(sqrt(N)) cells.
This gives O(sqrt(N)) communications lines being routed through each cell.
Arguing that that only applies to people near the center of the grid is a cop-out - you'll still have a large fraction of your cells with traffic comparable to what you have near the center, especially since you're spreading traffic routes out to avoid local congestion.
Find a way around that, with the assumptions that I described (array size much larger than cell size with random point-to-point communications requests), and you're a network god. Good luck.
Re:Scaling problems. Very nasty scaling problems.
on
Peer-to-Peer Cellular
·
· Score: 2
*sigh* -1, Redundant
Exactly the same point was already raised...and answered [slashdot.org].
*Sigh*.
I was pointing out that even with perfectly balanced, zero-overhead routing, this system doesn't scale well. Arguing that routing is easier than I'm claiming completely misses the point of my post.
Scaling problems. Very nasty scaling problems.
on
Peer-to-Peer Cellular
·
· Score: 4, Interesting
Even if every phone had a perfect routing table, you'd still have very severe scaling problems.
Even if almost all of the messages being routed are to phones in the same city, the density of messages at each relay node will be large (total traffic is proportional to the number of nodes talking, and for an even distribution, traffic per node is proportional to the square root of this). A city has a million phones or more. This means that each phone would be routing messages for hundreds or thousands of other phones on a *normal* day. *If* all of the load-balancing in the routing table works perfectly.
Fast forward to Sept. 11th. You have everyone in North America trying to call or message relatives in New York City. The traffic densities as you approach New York would be *HUGE*. Inside the city, you'd have phones trying to handle thousands of messages or *more* at *once*, instead of whenever phone users decided to send. This would melt down the message network in the city and for a little ways around it.
All of this assumes that each phone knows the best route for all messages. In practice, they don't. I'll let someone with more network expertise than I have describe how nasty things get when your phone can only fit a small routing table and you have a constantly-shifting pattern of connections that has to update itself in a decentralized manner (instead of being tracked by a central server that knows where everyone is). Short version: It's not going to be pretty.
In summary, I think that the authours of the article are overlooking a significant problem, especially given that they're proposing this as a way of overcoming system load problems in situations like the Sept. 11th attacks.
Geez, I'd hate to be one of the guys in the control room on this one. With a) variably dense atmosphere, and b) major guesswork on how the heat will affect the spacecraft, I wouldn't be all that surprised if c) the ship failed!
Actually, you have a very good idea of how the heat will affect the craft, because you've already tested any spacecraft over its entire rated temperature range here on Earth before sending it into space (if you have any sense, at least).
They know how much heating plowing through a given amount of atmosphere will provide. They just keep this low enough per pass that it doesn't take craft temperature outside its known-good range (with a healthy safety margin).
Similarly, dealing with a factor of two uncertainty in the amount of atmosphere you'll be blowing through is straightforward too - assume the wost-case, and plot your course to keep the craft within spec. If you were wrong, no harm is done; you just need a few more orbits before you've lost the amount of speed you need to.
The main impact, if I understand correctly, is on mission scheduling. Mission control *likes* to know within a millimetre or two where your craft will be the Tuesday after next, so that it can plan experiments for the Thursday following *that*. Extra uncertainty means a longer waiting period before you know you'll have settled into a circular orbit, cleaned up any irregularities, and be ready to start scientific measurements. This costs money and leaves the primary mission scientists biting their nails a bit longer.
I didn't see any real mention of the martian winds in this article, don't they get up to hundreds of miles per hour in the upper atmosphere?
Even at its slowest, the craft will be travelling at many thousands of miles per hour. If there's wind at all in the far reaches of the atmosphere where it will be braking, it won't make that big a difference compared to uncertainty about the thickness of the atmosphere at that height.
This definitely gives pause when considering the difficulty of landing manned craft on the surface. With so many variables, you're almost guaranteed that something is going to go wrong.
The good news is that, for aerobraking at least, nothing can go wrong that can't be compensated for over the next few orbits.
Landings are a lot trickier, because you need a much greater change in velocity in a far, far shorter time, and if you screw up, you lose the craft. All they're doing for this craft is moving it from one orbit to another by slowly bleeding off velocity, which is much easier.
The main advantage to hydrogen is that it would disperse if there was a leak.
The main disadvantage is that its density is horribly low, even when liquified.
Why not use propane instead? It too will disperse (though it'll drift down instead of up), and it can be stored at a density approaching that of gasoline.
If you want something that won't pool, ethane will work, though that's harder to liquify by pressure alone. It's about as dense as air, and so will just tend to spread out if released.
Methane would drift upwards, but you'd need a cryogenic tank to hold liquid methane. Much higher energy density per unit _volume_ than liquid hydrogen, though.
Hey...I read some something about with Muon catylised fuson that they were able to get hydrogen to fuse when it's cold...like frozen cold. I also wonder if it's possible to combine a fusor (electrostatic) type reactor and muons to up the reaction rate.
This wouldn't do anything, because muon catalyzation only works with molecular hydrogen. A fusor uses a hydrogen plasma (albeit a relatively cool one).
See my previous post for information on how muon-catalyzed fusion works, which should make clear why molecular hydrogen is required.
If you could find a magical way of producing a thermal neutron beam for less than, say, 100 keV per neutron, you could also get what amounts to catalyzed fusion just by firing the beam at a block of lead.
I don't want to sound like some trekkie fanboy, but that sounds like it could be used as a weapon
If you were using it as a weapon, you'd be better off just firing the neutron beam at your target and letting everyone inside die of radiation poisoning from activated materials, as opposed to trying to use fusion as the energy source.
In practice, generating a neutron beam is likely to remain difficult and energy-expensive. This means that even if we can make the energy cost low enough to make power generation practical, we're probably not going to get much more energy out than we put in. There would be no easy way to turn this into a weapon (energy output (as heat) from the lead block would max out as some low multiple of the power rating of your (big, expensive) neutron generator).
One thing many people seem to miss is the problem of waste heat. Since fusion power still obeys the laws of thermodynamics, waste heat will inevitably flow into the environment. This, along with heat caused by power transmission losses (very significant) will have a significant environmental impact if power use were to drastically rise.
It's straightforward enough to get rid of the excess heat - concentrate it and let it radiate out into space. The per unit power cost of this is fairly low, so by the time we'll need it, we'll be able to build it.
It would only be a big problem if a fairly large area (hundreds of miles on a side) were to use much more power than the same area receives from sunlight, though. That would require a very high population density over a very large area. In the near term, it'll only hold for very small, densely populated areas (like cities). While this causes a local environmental impact, the effect on the environment as a whole is quite small for the time being (I'd worry more about chemical waste and deforestation).
Nowhere in the article does it mention creating mini-black-holes. The purpose is to try to create Higgs bosons and to precisely measure their characteristics to get a better handle on how electroweak symmetry breaking works.
To create mini-black-holes, you'd need a Planck-energy accelerator. This is beyond our current ability to build, and will remain so for quite a while. Scientific American had an article many years ago about what you'd have to do to build a conventional linac that powerful; it ended up having to be constructed in space and taking 2% of the sun's power output to run.
On a more mundane scale, we have experimental evidence (from cosmic rays of the same energy) that nothing catastrophically bad happens in collisions at energies of up to about 1.0e30 eV. We're not going to produce energies this high for a very long time either (current accellerators get in the 1.0e13 range at most; that's 100,000,000,000,000,000 times too low to be a concern).
I don't get how the DOE could keep a straight face whilst pushing the cleanliness of fusion power talking about heavy water plants.
Maybe they know more about the half-life of the byproducts than you do?
The original poster is correct. Neutron activation of the reactor vessel occurs in exactly the same way as in a fission reactor, and with exactly the same results - the whole reactor becomes low-level radioactive waste. As you'll be swapping out parts every few years (and disposing of old parts), this is a problem.
Lifetime of a neutron isn't relevant, any more than it is for a fission reactor - within a few microseconds the neutron has been absorbed by a nucleus in the reactor housing.
Fusion reactors produce no _high-level_ waste - strongly radioactive spent fuel byproducts - but reactor materials activation is just as big a problem.
[FWIW, cost of shielding *isn't* a problem - it will be far cheaper than the rest of the reactor even if you need ten feet of lead.]
Cold fusion may or may not work, however there is more than magentic containment. Try electrostatic. You could build a small (very ineffcient) fusion reator in you garage. They do away with using 'hot' plamsa and just go for ionized hydrogen being accelerated towards the middle of the reator. It works like a champ. And depending on the design of the reactor you can directly convert the energy released by the fusion reactions to (high voltage) DC (electricity).
The problem is that with a scheme like this you end up with difficulties surprisingly similar to magnetic confinement fusion if you're operating in a regime that produces useful power.
If your particle streams are fairly tenuous, they pass through each other with few reactions, and you operate at very poor energy efficiency (most of your input energy is wasted).
If the particle streams are dense enough that most particles interact, then shortly after impact you have an ordinary cloud of hot plamsa. This will disperse very quickly, leaving only a very short time for interaction, which again results in very poor energy efficiency.
You can try to confine the resulting plasma with magnetic fields to get a longer interaction time... at which point you're dealing with magnetic confinement fusion with a novel injection and heating scheme. Still interesting to build, but not as completely different from magnetic confinement fusion as your post suggests.
No low temperature fusion has ever been verified, though occasionally you will see new proposals for how it might be possible.
Actually, muon-catalyzed fusion at low temperature has been verified and is well-understood. The problem is that we don't have an efficient enough way of making muons to make this give a net energy gain.
Muon catalyized fusion works by firing a beam of muons at a pellet of frozen hydrogen. Muons will displace electrons in the H2 molecule. As muons are far heavier than electrons, they have a much shorter wavelength, which means that their molecular orbitals are much smaller, which means that the resulting hydrogen molecule is much smaller.
This puts the hydrogen nuclei close enough to have a reasonably good chance of tunnelling through the Coulomb barrier and spontaneously fusing.
The problem is that muons decay after a little while. In order for muon-catalyzed fusion to be energy-efficient, a muon must catalyze enough reactions in its lifetime to produce more energy than it took to create it. With current experiment setups and current methods of producing muons, this isn't the case.
[In case anyone's confused, this is completely unrelated to the "cold fusion" that caused such a stir a few years back and was mostly debunked.]
If you could find a magical way of producing a thermal neutron beam for less than, say, 100 keV per neutron, you could also get what amounts to catalyzed fusion just by firing the beam at a block of lead. Four neutrons being absorbed by the same lead atom results in two beta decays and one alpha decay - emitting the components of a helium-4 atom. This isn't time-sensitive, so you don't need a terribly intense neutron beam or any other special conditions. Unfortunately, I know of no way to produce neutrons out of thin air (or thin hydrogen) at a cost lower than a few MeV per neutron.
This would be a good time to jump in and say "What about hemp?"
Last summer a group of young scientists drove an unmodified, diesel engine Mercedes Benz across country to promote hemp for fuel. They ran the car entirely on fuel created from hemp seeds. Although mileage was slightly impaired, the amount of pollution generated was greatly reduced because, unlike gasoline refining, which adds many noxious and dangerous chemicals, hemp fuels rely on natural methods.
This fuel "created from hemp seeds" was almost certainly just an alcohol. You can make alcohol by fermenting just about anything organic.
The problem is that both the growing of the plants and the fermenting are not terribly energy-efficient. Direct synthesis by burning CO2 in a hydrogen atmosphere would almost certainly be a better option.
The other thing that they might have produced from hemp is something vaguely resembling diesel fuel. This too can be produced fairly readily from many types of plant (think "low-grade vegetable oil").
The problem is that burning long-chain hydrocarbons cleanly is very difficult to do. This would probably not be a viable fuel source even if you weren't stuck with plants' energy efficiency.
The "...which adds many noxious and dangerous chemicals" line is mainly trolling on the part of whatever source gave you this information. The most dangerous things coming out of a gasoline engine are sulphur and nitrogen oxides. The sulphur came straight from the ground with the fuel, and the nitrogen oxides are a natural byproduct of burning any hydrocarbon under engine conditions. Hemp deisel would contain as much sulphur as the hemp did (all plant and animal matter contains some of it; at least one of the amino acids uses it). Hemp alcohol wouldn't... but I don't see any reason to use hemp alcohol over direct-synthesis alcohol.
In summary, I don't see any real advantage to using hemp as a fuel.
No matter how meaningful quantities hydrogen are generated, greenheads will hate the fact that mother earth will incur vast amounts of greenhouse gases. Shall we address the infrastructure problems associated with hydrogen? The costs of retooling fuel distribution channels to handle hydrogen?
The advantage to switching to hydrogen or another easily-synthesized fuel like methanol is that it centralizes the power generation, allowing you to switch to a different system (solar, nuclear, hamster wheels, or what-have-you) without requiring another upgrade to all of the cars and service stations on a continent. This is a very respectable accomplishment.
You can also generally install better scrubbers on a coal power plant than on a car, even before you start switching to alternate power sources.
Another issue conveniently ignored is the storage of hydrogen. Hydrogen, in its current form, is not particularly dense, requiring large tanks to store the equivalent energy stored in fossil fuels.
That's why I like the idea of using methanol as a fuel. You could handle it in existing service stations without too much refitting, and you could burn it in a conventional internal combustion engine (though you'd probably want a ceramic engine to avoid corrosion over time). Fuel cells can process it too, though with greater difficulty. Methanol's boiling point is low enough that you'd have to store it under pressure, like propane, but this isn't too difficult (we already have the infrastructure for it for propane).
Methanol can be produced by fermenting plants if you're desperate, or produced by direct synthesis if you have a source of power, hydrogen, and CO2 handy. Plunk a fuel plant next to a big city, and you have all three (water, exhaust, and the local power plant).
This gives us the advantages of a hydrocarbon fuel without having to short-circuit the carbon cycle or depend on exhaustible fossil fuel deposits.
Of course, we'll only really switch when fossil fuels become scarce enough to make this cost-effective.
So how would you go about building, say, a 120V inverter to run off this gizmo without wasting too much energy or winding up with voltage stability problems on the output? Switching power supply to generate a fixed DC from the unregulated DC?
The voltage output of a fuel cell is determined by electrochemical effects (like a battery), so it should be very stable.
Turning it into AC is easy ($5 worth of electronics from the local hobby store). Add another $5 and about a pound of iron for the inductors if you want it to be filtered into a nice smooth sine wave (otherwise it'll be a square wave, and many electronic devices object to this).
Why cant they just use Magnetic Resonance Imaging instead, then they doesnt even have to put stuff in the poor little rats head. Using nuclear magnetic resonance seems to me to be the only way to se things in 3D because you can scan out "slices" and put them together and so to speak get a 3D-picture of the stuff in the brain.
Actually, PET (Positron Emission Tomography) and CAT (Computed Axial Tomography [via x-ray absorption scanning]) and even old-fashioned ultrasound give you 3D pictures too.
None of these are anywhere close to the resolution you'd get looking through a microscope. Great for finding tumours or looking at large-scale brain activity, and useless for looking at function on the level of individual neurons.
Even if you're looking only at surface neurons, watching neurons while they're operating in a brain will teach you one heck of a lot (especially if you hook a spectrophotometer up to the microscope and get chemical composition readouts - neurochemistry is only partly understood).
However, on the Moon (on the surface that is) the 'night' is 2 weeks long! Not that many plants can survive 2 weeks without sunlight.
Good point.
The last reason for not using sunlight for growing crops in a space station is that spacecraft usually rotate in order to maintain a constant bearing and in order to equalize the heat recieved from the sun. In order to maintain sunshine through the small window you would have to have an elaborate mirror-arrangement outside to direct the sunlight through the window. Such things are expensive to make, and second they also weight something and have to be sent up. Electricity is not so sparce in space, as solar pannels produce electricity.
You could reduce the window size needed by using a curved mirror and focusing sunlight through a slit or an aperture. This should still be reasonably cheap, as a mirror doesn't have to be very strong in space.
Rotation is a trickier problem. If I was designing the station, I'd either make the greenhouse portions not rotate, or I'd put a nonrotating mirror above the axis of the craft and focus light through an aperture on the axis.
That, or use a nonrotating craft. Attitude control isn't a problem with modern spacecraft guidance systems, and the heating problem is manageable, albeit with a small amount of extra mass.
Academic, of course, since I'm not in a position to design spacecraft:).
Slashdot Mirror
However, a lot of articles have been popping up in New Scientist essentially calling Methanol a demon fuel. It takes more energy to produce than it generates. By the time you use fertilizers, transport the stuff to the processing plant, run the plant, transport it to the pumps you've used more of the stuff than you can produce!
This sounds like Oil industry propoganda, but its getting a lot of column inches! anyone know anything?
For generating methanol from biomass, that might even be true. However, you have a lot of spare biomass left over from growing grops for food and fodder, so you could get *some* fuel "for free".
If you're generating methanol by direct sythesis, a) you're much more efficient (far fewer steps, and far less waste material synthesized), and b) you're using it as a storage medium for some other energy source (like solar or nuclear), so you aren't having to expend methanol to produce methanol.
I understand that this says basically that it moves away from walls when it contacts them, but I can't figure out for the life of me what a "disc cam in cage" is, or how this would help it push off of the wall?
Pure speculation, as I haven't seen pictures of the thing either, but - if the "cam" is a heavy disc mounted on an off-center axis, turning it would change where the center of mass of the robot was. This would push the surrounding "cage" (and the rest of the robot) in the opposite direction. If you just want translation instead of rotation, you'd use two off-center cams and spin them in opposite directions (pure mass shift, no net application of torque).
If you had a setup like this, you could rig it to "jitter" (push the cage in one direction when the cams' center of mass goes in the other) whenever it touched a wall, to push off of the surface.
No idea if this is what they did, though.
My father runs a small business, and had to rack a few systems. He just bolted together some Dexion angle-iron and put on plywood shelves.
Dexion ( http://www.dexion.com ) makes all kinds of shelving-related stuff. Their angle-iron looks like giant pieces from an erector set; sturdy L-cross-section steel beams with holes drilled in them. Bolt them together, and you can build just about anything you want. It's fairly cheap, and works very well for racking PCs or just about anything else.
Various shelving offerings are listed on Dexion's shelving page, at http://www.dexion.co.uk/shelving/intro.html .
These mirrors flip up and down mechanically, right? That can't be much faster than KHz, whereas electronics switch on the order of MHz, I thought...
You could move a macroscopic mirror at a few kHz. Mirrors fabricated to be a few microns across can be switched much, much more quickly.
Even if your packet rate still ends up being much faster than the speed at which you can switch the mirror, you could still use this to eliminate a lot of decoding during routing. Instead of a box with N network attachments that decodes incoming traffic and sends it to x, y, or z destination as appropriate, you have a MEMS box that has one connection pattern for the first millisecond, another connection pattern for the next millisecond, and so on. If the routers generating the traffic are intelligent, they can group packets for a given destination into bursts so that they're routed automatically through the optical MEMS router. Alternatively, you could group packets and put a duration and a destination-identifier tag on it at a lower data rate. Embedded electronics in the MEMS chip can read the destination and move the mirror to the correct position for the duration of the burst of packets.
This won't eliminate the need for all electronic processing, but it will make several aspects of routing at high data rates much easier.
but then they go and claim that mirrors are wavelength insensitive. Perhaps regular mirrors are, but aren't high reflectivity mirrors wavelength sensitive (using interference effects from thin film coatings)? If they didn't use high reflectivity mirrors, wouldn't there be a huge loss to this switch?
Not really. You can always put an optical repeater (read: erbium-doped fiber laser) on all outgoing ports to compensate for dimming. You have to do this on long fiber runs anyways.
Good thought, though.
Another explaination might be that the stars are young and therefore cool, but I couldn't say that for sure either.
It turns out that there are certain spectral features (element emission/absorption lines) that occur at the same frequency no matter what temperature the object producing them is at. If this pattern of lines is shifted, you know that the colour is due to a real redshift and not a temperature difference.
I suppose that if something like Planck's constant was different at the time and location of the stars, that would also produce an emission line shift, but it's far more likely that the light has just been redshifted.
There was an article on VectorC on Ace's Hardware a while ago:
p ost_id=55000348&keyword_highlight=VectorC
p ?message_id=65013137
p ?message_id=65013223
http://www.aceshardware.com/Spades/read_news.php?
Very substantial performance gains were claimed. However, there was some concern about how well the benchmarks were set up:
http://www.aceshardware.com/board/general/read.ph
http://www.aceshardware.com/board/general/read.ph
In short, I'd take a very careful look at the benchmark code and methods of compiling before making conclusions about VectorC's performance. It might still be great; however, past benchmarks that have been floated have been questioned.
DISCLAIMER: I have not used VectorC, or directly examined the test code or assembly code generated for any of the tests. I have no direct assessment of the benchmarks - I'm pointing to others' assessments in response to another article about the compiler.
You want a more rigorous illustration of why you get congestion? Fine:
That's no more rigorous than before. It's the same example and analysis that I already showed to be flawed, just worded a little differently.
Bushwa.
You're trying to make a call from phone A to phone B. The distance between the phones is an average of K times the range of phone-to-phone communication. How, pray tell, do you plan to do this in fewer than an average of K hops?
You have N phones, and O(N) calls. You have, therefore, O(KN) communications hops in total to service all calls. How, pray tell, do you plan to distribute O(KN) relays among O(N) phones without at least an average of O(K) relays being serviced per phone?
You have yet to provide a convincing argument (or any argument) against this. You seem hung up on me assuming a "rectilinear grid", which I did *not* do in my previous message.
I respond perfectly well to well-reasoned debate, and have admitted error many times in the past when presented with evidence or counterexamples. You have provided neither. Please do so.
These assumptions all combine to paint a much uglier than necessary picture, as we'll see. To deal with the most obviously stupid assumption first, consider that connectivity is actually a product of range and node density. Sure, you won't find many neighbor nodes if you have a hundred devices spread across the entire state of Montana. However, if you have several hundred thousand units within the confines of New York City - our original example - you're likely to find hundreds of potential neighbor nodes even if your range is quite small.
This does not affect the order of the problem. It just affects the proportionality constant when translating O(sqrt(N)) into an actual hard number. Connectivity within a node isn't relevant to the problem. See below before trotting out your formula again.
This brings us to the grid assumption. You're assuming that nodes are incapable of "skipping" a row or column in your unnecessarily-rectilinear grid, but in reality that's not likely to be the case. If I have a couple of hundred potential neighbors, I'd have to be an idiot to route everything only through the ten nearest
I'm already assuming you're routing to the *farthest* possible cell phone. Which is in the adjacent *node*. A node, in my previous post, is a *group* of cell phones.
You want a more rigorous illustration of why you get congestion? Fine:
You have a large area containing cell phones, with very short communications range. You have random point-to-point communication requests within the large area.
Draw a stripe through the middle of the area, with a width equal to the phone-to-phone communication range. About half of the total phone traffic connects people on opposite sides of the stripe.
All of this communication must be routed through phones within the stripe - it's wide enough that you can't just skip over it.
The number of calls/message channels routed through the stripe is proportional to the number of phones, which is proportional to the area (we're in a city with phones uniformly distributed).
The number of phones within the stripe is proportional to a constant (the phone-to-phone range) times the *diameter* of the region - which is proportional to the square root of the area of the region (and hence the square root of the number of phones).
Thus, you end up with a number of communication channels proportional to the total number of phones being routed through a stripe containing a number of phones proportional to the square root of the total number of phones. Average number of channels being routed through any given phone on the stripe is proportional to the square root of the total number of phones.
This holds as a fundamental limit regardless of the number of phones that any given phone can contact, and regardless of the routing algorithm.
Now do you see where I'm coming from?
Lastly, let's consider the assumption that you'd always be routing exclusively through other mobile nodes? Why?
Because that was what the article was suggesting be done.
If I'm allowed to use fixed towers, I'll just make them have as large a range as bandwidth lets me (to widen the stripe that things have to be routed through), and use very high capacity links between towers (so that high load isn't as serious a problem), and force all phone traffic to be routed through them. And maybe use something other than a mesh-style topology for tower-to-tower routing, if I have high enough capacity data conduits, as there's no range limit for tower-to-tower communication if I'm running fiber instead of broadcasting. But all of this dispenses of the idea of a magical phone-based decentralized network, which the article's authour was so enamoured with.
Wrong. Traffic per node in an N-node network is proportional to log(N) - the log base being the average connectivity - not sqrt(N). For a million-node network with average connectivity of four, that's the difference between your figure of 1000 and a correct figure of 10.
You are making flawed assumptions about the nature of the network.
A cell phone's range, when communicating with another cell phone instead of a tower, sucks. You can model the resulting network as a large grid of cells, with a cell's size being the communications range of a cell phone to another cell phone.
Assume you have a large grid. Assume that people are communicating between random points within this grid.
Traffic only flows to neighbouring cells - your range sucks, as mentioned.
Draw a partition down the center of this grid. Half of your traffic will cross this partition (given random sources and destinations).
If everyone is on the phone, and you have N cells, you have O(N) communications channels, half of which cross the partition, being routed through a region containin O(sqrt(N)) cells.
This gives O(sqrt(N)) communications lines being routed through each cell.
Arguing that that only applies to people near the center of the grid is a cop-out - you'll still have a large fraction of your cells with traffic comparable to what you have near the center, especially since you're spreading traffic routes out to avoid local congestion.
Find a way around that, with the assumptions that I described (array size much larger than cell size with random point-to-point communications requests), and you're a network god. Good luck.
*sigh* -1, Redundant
Exactly the same point was already raised...and answered [slashdot.org].
*Sigh*.
I was pointing out that even with perfectly balanced, zero-overhead routing, this system doesn't scale well. Arguing that routing is easier than I'm claiming completely misses the point of my post.
Even if every phone had a perfect routing table, you'd still have very severe scaling problems.
Even if almost all of the messages being routed are to phones in the same city, the density of messages at each relay node will be large (total traffic is proportional to the number of nodes talking, and for an even distribution, traffic per node is proportional to the square root of this). A city has a million phones or more. This means that each phone would be routing messages for hundreds or thousands of other phones on a *normal* day. *If* all of the load-balancing in the routing table works perfectly.
Fast forward to Sept. 11th. You have everyone in North America trying to call or message relatives in New York City. The traffic densities as you approach New York would be *HUGE*. Inside the city, you'd have phones trying to handle thousands of messages or *more* at *once*, instead of whenever phone users decided to send. This would melt down the message network in the city and for a little ways around it.
All of this assumes that each phone knows the best route for all messages. In practice, they don't. I'll let someone with more network expertise than I have describe how nasty things get when your phone can only fit a small routing table and you have a constantly-shifting pattern of connections that has to update itself in a decentralized manner (instead of being tracked by a central server that knows where everyone is). Short version: It's not going to be pretty.
In summary, I think that the authours of the article are overlooking a significant problem, especially given that they're proposing this as a way of overcoming system load problems in situations like the Sept. 11th attacks.
Geez, I'd hate to be one of the guys in the control room on this one. With a) variably dense atmosphere, and b) major guesswork on how the heat will affect the spacecraft, I wouldn't be all that surprised if c) the ship failed!
Actually, you have a very good idea of how the heat will affect the craft, because you've already tested any spacecraft over its entire rated temperature range here on Earth before sending it into space (if you have any sense, at least).
They know how much heating plowing through a given amount of atmosphere will provide. They just keep this low enough per pass that it doesn't take craft temperature outside its known-good range (with a healthy safety margin).
Similarly, dealing with a factor of two uncertainty in the amount of atmosphere you'll be blowing through is straightforward too - assume the wost-case, and plot your course to keep the craft within spec. If you were wrong, no harm is done; you just need a few more orbits before you've lost the amount of speed you need to.
The main impact, if I understand correctly, is on mission scheduling. Mission control *likes* to know within a millimetre or two where your craft will be the Tuesday after next, so that it can plan experiments for the Thursday following *that*. Extra uncertainty means a longer waiting period before you know you'll have settled into a circular orbit, cleaned up any irregularities, and be ready to start scientific measurements. This costs money and leaves the primary mission scientists biting their nails a bit longer.
I didn't see any real mention of the martian winds in this article, don't they get up to hundreds of miles per hour in the upper atmosphere?
Even at its slowest, the craft will be travelling at many thousands of miles per hour. If there's wind at all in the far reaches of the atmosphere where it will be braking, it won't make that big a difference compared to uncertainty about the thickness of the atmosphere at that height.
This definitely gives pause when considering the difficulty of landing manned craft on the surface. With so many variables, you're almost guaranteed that something is going to go wrong.
The good news is that, for aerobraking at least, nothing can go wrong that can't be compensated for over the next few orbits.
Landings are a lot trickier, because you need a much greater change in velocity in a far, far shorter time, and if you screw up, you lose the craft. All they're doing for this craft is moving it from one orbit to another by slowly bleeding off velocity, which is much easier.
The main advantage to hydrogen is that it would disperse if there was a leak.
The main disadvantage is that its density is horribly low, even when liquified.
Why not use propane instead? It too will disperse (though it'll drift down instead of up), and it can be stored at a density approaching that of gasoline.
If you want something that won't pool, ethane will work, though that's harder to liquify by pressure alone. It's about as dense as air, and so will just tend to spread out if released.
Methane would drift upwards, but you'd need a cryogenic tank to hold liquid methane. Much higher energy density per unit _volume_ than liquid hydrogen, though.
Hey...I read some something about with Muon catylised fuson that they were able to get hydrogen to fuse when it's cold...like frozen cold. I also wonder if it's possible to combine a fusor (electrostatic) type reactor and muons to up the reaction rate.
This wouldn't do anything, because muon catalyzation only works with molecular hydrogen. A fusor uses a hydrogen plasma (albeit a relatively cool one).
See my previous post for information on how muon-catalyzed fusion works, which should make clear why molecular hydrogen is required.
If you could find a magical way of producing a thermal neutron beam for less than, say, 100 keV per neutron, you could also get what amounts to catalyzed fusion just by firing the beam at a block of lead.
I don't want to sound like some trekkie fanboy, but that sounds like it could be used as a weapon
If you were using it as a weapon, you'd be better off just firing the neutron beam at your target and letting everyone inside die of radiation poisoning from activated materials, as opposed to trying to use fusion as the energy source.
In practice, generating a neutron beam is likely to remain difficult and energy-expensive. This means that even if we can make the energy cost low enough to make power generation practical, we're probably not going to get much more energy out than we put in. There would be no easy way to turn this into a weapon (energy output (as heat) from the lead block would max out as some low multiple of the power rating of your (big, expensive) neutron generator).
One thing many people seem to miss is the problem of waste heat. Since fusion power still obeys the laws of thermodynamics, waste heat will inevitably flow into the environment. This, along with heat caused by power transmission losses (very significant) will have a significant environmental impact if power use were to drastically rise.
It's straightforward enough to get rid of the excess heat - concentrate it and let it radiate out into space. The per unit power cost of this is fairly low, so by the time we'll need it, we'll be able to build it.
It would only be a big problem if a fairly large area (hundreds of miles on a side) were to use much more power than the same area receives from sunlight, though. That would require a very high population density over a very large area. In the near term, it'll only hold for very small, densely populated areas (like cities). While this causes a local environmental impact, the effect on the environment as a whole is quite small for the time being (I'd worry more about chemical waste and deforestation).
Nowhere in the article does it mention creating mini-black-holes. The purpose is to try to create Higgs bosons and to precisely measure their characteristics to get a better handle on how electroweak symmetry breaking works.
To create mini-black-holes, you'd need a Planck-energy accelerator. This is beyond our current ability to build, and will remain so for quite a while. Scientific American had an article many years ago about what you'd have to do to build a conventional linac that powerful; it ended up having to be constructed in space and taking 2% of the sun's power output to run.
On a more mundane scale, we have experimental evidence (from cosmic rays of the same energy) that nothing catastrophically bad happens in collisions at energies of up to about 1.0e30 eV. We're not going to produce energies this high for a very long time either (current accellerators get in the 1.0e13 range at most; that's 100,000,000,000,000,000 times too low to be a concern).
I don't get how the DOE could keep a straight face whilst pushing the cleanliness of fusion power talking about heavy water plants.
Maybe they know more about the half-life of the byproducts than you do?
The original poster is correct. Neutron activation of the reactor vessel occurs in exactly the same way as in a fission reactor, and with exactly the same results - the whole reactor becomes low-level radioactive waste. As you'll be swapping out parts every few years (and disposing of old parts), this is a problem.
Lifetime of a neutron isn't relevant, any more than it is for a fission reactor - within a few microseconds the neutron has been absorbed by a nucleus in the reactor housing.
Fusion reactors produce no _high-level_ waste - strongly radioactive spent fuel byproducts - but reactor materials activation is just as big a problem.
[FWIW, cost of shielding *isn't* a problem - it will be far cheaper than the rest of the reactor even if you need ten feet of lead.]
Cold fusion may or may not work, however there is more than magentic containment. Try electrostatic. You could build a small (very ineffcient) fusion reator in you garage. They do away with using 'hot' plamsa and just go for ionized hydrogen being accelerated towards the middle of the reator. It works like a champ. And depending on the design of the reactor you can directly convert the energy released by the fusion reactions to (high voltage) DC (electricity).
The problem is that with a scheme like this you end up with difficulties surprisingly similar to magnetic confinement fusion if you're operating in a regime that produces useful power.
If your particle streams are fairly tenuous, they pass through each other with few reactions, and you operate at very poor energy efficiency (most of your input energy is wasted).
If the particle streams are dense enough that most particles interact, then shortly after impact you have an ordinary cloud of hot plamsa. This will disperse very quickly, leaving only a very short time for interaction, which again results in very poor energy efficiency.
You can try to confine the resulting plasma with magnetic fields to get a longer interaction time... at which point you're dealing with magnetic confinement fusion with a novel injection and heating scheme. Still interesting to build, but not as completely different from magnetic confinement fusion as your post suggests.
No low temperature fusion has ever been verified, though occasionally you will see new proposals for how it might be possible.
Actually, muon-catalyzed fusion at low temperature has been verified and is well-understood. The problem is that we don't have an efficient enough way of making muons to make this give a net energy gain.
Muon catalyized fusion works by firing a beam of muons at a pellet of frozen hydrogen. Muons will displace electrons in the H2 molecule. As muons are far heavier than electrons, they have a much shorter wavelength, which means that their molecular orbitals are much smaller, which means that the resulting hydrogen molecule is much smaller.
This puts the hydrogen nuclei close enough to have a reasonably good chance of tunnelling through the Coulomb barrier and spontaneously fusing.
The problem is that muons decay after a little while. In order for muon-catalyzed fusion to be energy-efficient, a muon must catalyze enough reactions in its lifetime to produce more energy than it took to create it. With current experiment setups and current methods of producing muons, this isn't the case.
[In case anyone's confused, this is completely unrelated to the "cold fusion" that caused such a stir a few years back and was mostly debunked.]
If you could find a magical way of producing a thermal neutron beam for less than, say, 100 keV per neutron, you could also get what amounts to catalyzed fusion just by firing the beam at a block of lead. Four neutrons being absorbed by the same lead atom results in two beta decays and one alpha decay - emitting the components of a helium-4 atom. This isn't time-sensitive, so you don't need a terribly intense neutron beam or any other special conditions. Unfortunately, I know of no way to produce neutrons out of thin air (or thin hydrogen) at a cost lower than a few MeV per neutron.
This would be a good time to jump in and say "What about hemp?"
Last summer a group of young scientists drove an unmodified, diesel engine Mercedes Benz across country to promote hemp for fuel. They ran the car entirely on fuel created from hemp seeds. Although mileage was slightly impaired, the amount of pollution generated was greatly reduced because, unlike gasoline refining, which adds many noxious and dangerous chemicals, hemp fuels rely on natural methods.
This fuel "created from hemp seeds" was almost certainly just an alcohol. You can make alcohol by fermenting just about anything organic.
The problem is that both the growing of the plants and the fermenting are not terribly energy-efficient. Direct synthesis by burning CO2 in a hydrogen atmosphere would almost certainly be a better option.
The other thing that they might have produced from hemp is something vaguely resembling diesel fuel. This too can be produced fairly readily from many types of plant (think "low-grade vegetable oil").
The problem is that burning long-chain hydrocarbons cleanly is very difficult to do. This would probably not be a viable fuel source even if you weren't stuck with plants' energy efficiency.
The "...which adds many noxious and dangerous chemicals" line is mainly trolling on the part of whatever source gave you this information. The most dangerous things coming out of a gasoline engine are sulphur and nitrogen oxides. The sulphur came straight from the ground with the fuel, and the nitrogen oxides are a natural byproduct of burning any hydrocarbon under engine conditions. Hemp deisel would contain as much sulphur as the hemp did (all plant and animal matter contains some of it; at least one of the amino acids uses it). Hemp alcohol wouldn't... but I don't see any reason to use hemp alcohol over direct-synthesis alcohol.
In summary, I don't see any real advantage to using hemp as a fuel.
No matter how meaningful quantities hydrogen are generated, greenheads will hate the fact that mother earth will incur vast amounts of greenhouse gases. Shall we address the infrastructure problems associated with hydrogen? The costs of retooling fuel distribution channels to handle hydrogen?
The advantage to switching to hydrogen or another easily-synthesized fuel like methanol is that it centralizes the power generation, allowing you to switch to a different system (solar, nuclear, hamster wheels, or what-have-you) without requiring another upgrade to all of the cars and service stations on a continent. This is a very respectable accomplishment.
You can also generally install better scrubbers on a coal power plant than on a car, even before you start switching to alternate power sources.
Another issue conveniently ignored is the storage of hydrogen. Hydrogen, in its current form, is not particularly dense, requiring large tanks to store the equivalent energy stored in fossil fuels.
That's why I like the idea of using methanol as a fuel. You could handle it in existing service stations without too much refitting, and you could burn it in a conventional internal combustion engine (though you'd probably want a ceramic engine to avoid corrosion over time). Fuel cells can process it too, though with greater difficulty. Methanol's boiling point is low enough that you'd have to store it under pressure, like propane, but this isn't too difficult (we already have the infrastructure for it for propane).
Methanol can be produced by fermenting plants if you're desperate, or produced by direct synthesis if you have a source of power, hydrogen, and CO2 handy. Plunk a fuel plant next to a big city, and you have all three (water, exhaust, and the local power plant).
This gives us the advantages of a hydrocarbon fuel without having to short-circuit the carbon cycle or depend on exhaustible fossil fuel deposits.
Of course, we'll only really switch when fossil fuels become scarce enough to make this cost-effective.
So how would you go about building, say, a 120V inverter to run off this gizmo without wasting too much energy or winding up with voltage stability problems on the output? Switching power supply to generate a fixed DC from the unregulated DC?
The voltage output of a fuel cell is determined by electrochemical effects (like a battery), so it should be very stable.
Turning it into AC is easy ($5 worth of electronics from the local hobby store). Add another $5 and about a pound of iron for the inductors if you want it to be filtered into a nice smooth sine wave (otherwise it'll be a square wave, and many electronic devices object to this).
Why cant they just use Magnetic Resonance Imaging instead, then they doesnt even have to put stuff in the poor little rats head. Using nuclear magnetic resonance seems to me to be the only way to se things in 3D because you can scan out "slices" and put them together and so to speak get a 3D-picture of the stuff in the brain.
Actually, PET (Positron Emission Tomography) and CAT (Computed Axial Tomography [via x-ray absorption scanning]) and even old-fashioned ultrasound give you 3D pictures too.
None of these are anywhere close to the resolution you'd get looking through a microscope. Great for finding tumours or looking at large-scale brain activity, and useless for looking at function on the level of individual neurons.
Even if you're looking only at surface neurons, watching neurons while they're operating in a brain will teach you one heck of a lot (especially if you hook a spectrophotometer up to the microscope and get chemical composition readouts - neurochemistry is only partly understood).
However, on the Moon (on the surface that is) the 'night' is 2 weeks long! Not that many plants can survive 2 weeks without sunlight.
:).
Good point.
The last reason for not using sunlight for growing crops in a space station is that spacecraft usually rotate in order to maintain a constant bearing and in order to equalize the heat recieved from the sun. In order to maintain sunshine through the small window you would have to have an elaborate mirror-arrangement outside to direct the sunlight through the window. Such things are expensive to make, and second they also weight something and have to be sent up. Electricity is not so sparce in space, as solar pannels produce electricity.
You could reduce the window size needed by using a curved mirror and focusing sunlight through a slit or an aperture. This should still be reasonably cheap, as a mirror doesn't have to be very strong in space.
Rotation is a trickier problem. If I was designing the station, I'd either make the greenhouse portions not rotate, or I'd put a nonrotating mirror above the axis of the craft and focus light through an aperture on the axis.
That, or use a nonrotating craft. Attitude control isn't a problem with modern spacecraft guidance systems, and the heating problem is manageable, albeit with a small amount of extra mass.
Academic, of course, since I'm not in a position to design spacecraft