All FC "current" cars are 700 bar (~10,000 psi). Busses are often 350 bar, but are moving to 700 bar. Trucks from Nicola were announced at 350 bar, but may actually ship at 700 bar. Nicola are committed to 700 bar fueling stations regardless. The first Kenworth prototype was 350 bar, but the new projects with Toyota are 700 bar. The Toyota prototypes in Long Beach are all 700 bar.
Bottom line is that 700 bar is getting easier to do. If you store "cryo" as liquid H2, then compressing to 700 bar can be done with nearly zero energy using the "boil off" energy. This is how Linde H2 stations work. No this is not a violation of physics. The energy required to get to 9 degrees K can be recovered to get the gas up to 10K psi.
Uber and Lyft drivers drive Prius hybrids because they are the lowest operating cost cars you can buy. The gas engines last to 200K+. Brakes are 100K+. The hybrid system is zero maintenance and the battery does not wear out. And you get 40 MPG is you drive it like a taxi cab.
I also have a Mirai. There are three H2 stations near me. The car is a bit of a science project, but it works very well. FC failure rates are very low. Much lower than reported battery or motor issues from Tesla. The rest of the car is rock solid. The weakest part is the Michelin tires.
Hybrids that regen break are a must. With a BEV, you can re-purpose the motors and battery. With a FC you can re-purpose the motor, but need an additional small battery. The Mirai has a 1.5 KWh NiMH pack for regen and it is up to most uses. If you are going downhill on the GrapeVine north of LA, the run is too long for the regen capacity and you start to use real brakes. I would wager than none of the 5000+ Mirais on the road have needed brakes yet. If they are like the other Toyota hybrids, they will easily last 100K+ miles.
I think the "ideal" is something like the plug-in Mercedes FC they are building in Germany (unfortunately, under 100). It is a FC "hybrid" that has about a 10KWh battery pack that can be plugged in. So it is a PHFCEV. The advantage of the battery is that it mitigates the lower end-to-end efficiency of the FC stack. The advantage of the FC stack if range and quick refilling.
In the end, FCs have some interesting new tech on the way. One university paper describes a "bi-direction FC electrode system". A single set of electrodes can use electricity to split H20 into H2 and O2 (electrolysis) and you can then turn it around and turn H2 and O2 into H2O plus electricity (a FC stack). This is energy storage on a "grid level" scale. Amazingly, they are reporting 75%+ round trip efficiency which is better than stores hydro.
Actually, MPGe is a very solid measurement. Take the amount of "energy" in a gallon of gasoline and compare that energy in another storage form. This is a very big disadvantage to gasoline as ICE engines are about 20% efficient. BEVs are 85% or so (after the electronics). FCEVs are 60% or so, but have the "advantage" of being better in cold weather than BEVs (you can use the FC waste heat to heat the cabin and the capacity of H2 does not degrade with temperature).
MPGe has nothing to do with fuel or electricity cost.
Your numbers are correct, but don't always work with all usage scenarios. I suspect "local traffic" with stop signs and sharp curves need a different calculation Not sure which way it would move.
In terms of straight line, the problem is that both of your cars are "nothing" compared to a 80,000 lb fully loaded semi with 80 psi tires. If you are charging for "road wear out", then the truck should pay "all of it". The cars are a rounding error. But this has it's problems as well.
You have the purpose of the new "red sticker" wrong. It is just a way to enforce an expiration date. New EVs get 3-4 years of carpool access. If you have a "white or green" sticker for a car you bought after 1/1/2017, you can get a red replacement.
After 12/31/2018, new cars will get yet another color good thru 12/31/2022. This is reported to be purple. Next year, another color will roll out.
The "red sticker" did have some glitches. If you were unlucky and got a car in 2016, you would only get 2-3 years. If you bought in 2017, you would get 4-5 years. In the future it is supposed to stay at 3-4 years.
So it is not the "type" of EV, but when you bought it.
Also, a plug-in EV, assuming you actually plug it in, is amazingly good at emissions reduction. I know someone with a Volt that only buys gas four times a year. It is easy to argue that this is a "better solution" than 100% EVs (either battery or FC) because the ramp-up costs can be faster. I am not sure I agree and I like my FCEV very much.
... the obvious, existing, efficient, works today, energy storage. Pump water up-hill. Release it downhill. Low tech. Massive storage amounts with a big enough reservoir. In use at multiple sites in California, often just to make money on power arbitrage (ie, San Louis dam, reservoir, and fore-bay).
While your "logic" seems OK, I have no reason to doubt the author's research on the specific regions that produce barley. Actual, local, modeling is far more likely to produce accurate results that global ideas. I am not saying that your overall approach is wrong. If the author's research only looks at current locations for barley and what would happen to them, then that research is correct, but the conclusion is flawed. If the research also looks at new areas that can start to grown barley, then it would be reasonable methodology.
My real problem with the author is the lack of an economic model for the pricing spikes. Price spikes like this don't tend to happen unless the shortage is extreme. Pulling 10% from a source will not be prioritized to some other "more noble" product like animal feed. The market will use the product by whoever can pay the most for it. If beer production is impacted and price doubles, then beer production can pay a lot more, and the price will level out long before it doubles. Perhaps this is a bias based on "centrally controlled" economies. I don't think German barley farmers could be "told" to not sell to beer producers by the German or EU government, even if the government wanted to.
Your comparison with nuclear waste is as off-point as the rest of your post. If anything, a hydrogen leak is the least destructive event of any fuel leak. Gas and diesel are famous for pollution. Your example of nuclear waste is obvious. BEV battery fires produce all sorts of toxic gasses and hazardous left overs. A hydrogen fire/explosion produces water. If it does not burn, it heads into space. There is zero environmental impact.
Your analysis of hydrogen safety ignores a lot of research. The most important point is that at STP, hydrogen while flammable and even explosive if mixed with air, has a very low energy content. The energy content is low because because the gas is so light. 1/16 the weight of oxygen. About 78 W/hours per cu feet (not kw/hours).
The second point you miss is that hydrogen aggressively goes straight up when there is a leak. Gasoline and diesel pool. Even worse for gasoline, the vapors can pool and ignite. Hydrogen just heads for the sky. There is an on-line video of a two cars, one hydrogen and one gasoline. Both are set on fire with a fuel leak. The gasoline car is melted down. The hydrogen car is basically intact and can even roll on it's own tires at the end.
If you look at hydrogen fueling stations, they either do not have roofs, or they are designed to vent up. Air Products had a leak from about 30 kg of hydrogen tanks on a delivery truck. The damage was minor. The over-reaction was the biggest issue. Even the truck drove away. Also, the other 170 kg of hydrogen, on the same truck, never burned. The accident itself was caused by a pressure release "burst disk", in this case the wrong pressure disk was installed.
Issues about metal embrittlement are interesting, but not on point. A hydrogen leak will not "attack metals". If you build a tank out of the wrong stuff, it will fail. Don't build the tank out of the wrong stuff. Gasoline attacks a lot of different rubber seals. It is the same for diesel. You have to build the hardware with appropriate materials. In the case of automobile hydrogen tanks, this is fiberglass, plastic, and Kevlar. Hydrogen cars, and hydrogen filling stations are a lot safer than gasoline. A purely compression explosion is an interesting thought experiment, but even in a major crash, it is not that much energy (compared to the crash). In such a case, the hydrogen will only make it a few feet sideways before heading skyward.
And you never withdrew your 100 mile range and fueling a BITCH comment. There are issues of cost, available supply, and round trip energy efficiency. Then again, for some applications, hydrogen FC vehicles work really well. Long haul trains where caternary wires are too expensive. Long haul trucks. For passenger cars, Toyota believes that FC tech will be cheaper to build than batteries. Not sure if they are right or not, but they have a lot of experience, so betting against them is dubious. And I would much rather have a FC car in Lake Tahoe in the winter at -10F that a BEV Bolt or Tesla.
The future is a plug-in hybrid. Hydrogen and a FC for range, and a small-ish battery. With 50 miles of BEV range and 300+ miles of FC range, you have a Chevy Volt that does not pollute at all. Hydrogen cost and round trip efficiency are not all that important as the plug-in battery does most of the miles for most people. This also mitigates the hydrogen round trip efficiency and cost. With a bigger battery, the FC can be smaller, so this combo costs less to build. The battery is still small enough to not need a "super charger", so the grid is not impacted as much. Mercedes has one of these in tests now. The reason they are not building this is that there needs to be demand for H2 stations first. This hybrid design is no more complicated that the stock FC design, it just has a bigger regen battery and the charging electronics. Plug in FCs is what will win for all but NEV applications (Neighborhood Electric Vehicle).
FC Cars are nothing like you describe. Range is 300+ miles. Fueling is under 5 minutes from empty and generally un-eventful. The H2 supply chain breaks down far more often than the cars or the fueling stations (and the supply chain is getting better).
H2 tanks are extensively tested including such items as shooting them with 50 cal bullets. It takes two bullets to the same location to pierce the tank, and then it is a leak and the H2 gas that goes straight up. If it ignites, all the flame goes straight up as well. It is very hard to create an explosive mixture, and even then the explosive over-pressure is not really an explosion (a refinery in Wilmington, CA had a very large H2 tank explode a number of years ago. I felt the pressure wave 15 miles away. Even though many people were on site, no one was even injured.) I always wondered if H2 was a greenhouse gas. The answer is no as it actually escapes into space and literally leaves the planet (Helium does this as well). There are design differences, but generally H2 is far safer than gasoline car. Even a BEV car has real safety issues. Did you know the fire department needs to "saw" two spots on a Tesla Model 3 to break the high voltage "loop".
Reliability is also very good with 100K miles warranty and almost no required maintenance. Even the breaks last forever. I drive my FC car every day and it is an excellent car that gets me where I want to go in safety and comfort. My closest H2 station is about 4 miles away with 2 others within 15 miles. I see other FC cars on the road most days. 5100+ in California. http://www.cafcp.org./
You are shockingly wrong. Storing hydrogen at pressure for very long periods (decades) is now quite easy. You have to use the correct materials, but it is cost effective and the leak rate is basically undetectable. The correct materials are not exotic (fiberglass, plastics, kevlar)
We have hydrogen cars in California (over 5000). People drive them. People fill them, go on vacation, and come back six weeks later and they are still full. There are inefficiencies and costs, but the tech works reliably and the cars are practical.
... and companies routinely produce cars for "non California" markets. Take the Chevy Volt. Hybrid, "green". In California, they have to use a different gasoline generator to meet emission standards to qualify for stuff like carpoll stickers etc. So California "rules" are not everyone's rules and car makers often build differently in other states.
You are wrong. Non exhaust emissions are the three factors you specify. One of these, break wear, is dramatically lower on "electrified" cars. My Prius brakes last 100K+ miles. Tesla brakes, the same. My Mirai brakes, the same. My Chrysler mini-van, 15K tops. My wife's Honda FIT, 25K tops.
So road and tire emissions are "perhaps" marginally higher because of higher weight, but brakes move radically in the other direction.
Water vapor is a big greenhouse gas when releases in the stratosphere. Water vapor at the surface does not translate into water vapor at altitude. If it did, then Florida humidity would doom us all.
Plus you need to consider that gasoline and diesel engines also produce a lot of water vapor.
I have been awaiting some non-intel results on the X25-M drives for a while. Intel has been very good at putting marketting spin on this drive. While it is a good drive, it is nice to finally see some real numbers.
There appear to be two sites that have posted IOMeter results. I like IOMeter numbers because they don't try to hide the details and are easy to reporduce. Just for fun, I ran IOMeter File-Server, Workstation, and Database tests on an in-house MLC SSD to see how it compared. My results are here compared with the two sites X25-M numbers.
File Server:
Numbers are "Outstanding IOs", MFT IOPS, Intel X25-M @ pcper.com, and Intel X25-M @techreport.com.
A couple of points here. First, my numbers from the sites are from their graphs, so I might be off by a few percent.
Second, it looks like pcper.com's numbers for File-Server are messed up. They are too high at larger queue sizes. File-Server numbers should not be better than workstation numbers.
Regardless, these tests show two things. First, the Intel drive is a very good drive when comparing it with other "non managed" drives. Flash storage is a strange thing that really benefits from software that is designed for flash storage. That is what MFT (Managed Flash Technology) is. MFT is basically a transparent layer under the filesystem that re-ordered reads and writes so that Flash "is happy". Flash file systems do much the same things, although less aggressively than MFT.
Also, from what I can tell from Intel market-hype, their drive should last about 10x longer than other MLC drives for typical random-write workloads. This 80GB drive is designed for 20GB/day of random writes for a 5 year life. With MFT, a 64GB MLC drive can do about 100GB/day for a 7 year life so the software solution is still better.
We are shipping servers with MLC drives now. Their lifespan and performance is quite good. Now the "experts" might be behind the time, but what else is new.
Our typical server with MLC Mtron's run about 8000 4K read IOPS/drive. Writes are 40 MB/sec per drive, but we always write linearly so this still works out very well on mid-sized arrays. Even a single drive does 8000+ 4K write IOPS/drive. Our biggest issue is that current HBA and raid controllers don't scale as the arrays get big. Once your are above 100,000 IOPS, the HBAs just have no clue. Lifespan is also more than acceptable with 7-20 year lifespan assuming you overwrite the array daily.
For your 500TB/month application, you should be looking at MAID. Massive arrays of idle disks. If your read needs are semi-online, the spin up times can be manageable. I doubt that SSD will get to cost parity with HDDs in your type of application any time in the next 10+ years.
140 years at 50 GB/day is for linear writes. If you are doing random writes you have to scale this based on your average write size.
If your average random write size is 12K, then the amount of writes will be 12KB/2MB of the above amount or about 0.58% as much data. This is 170x worse.
Now this is an SLC drive, so you are probably still OK.
Flash $/GB is already lower than 15K 36GB 2.5" drives. $/IOPS is silly compared to 15K drives. Power and physical space are also wins on the SSD side, so this leaves only wear.
Our company ships servers with SSDs and software that "linearizes" the writes to the drives. This fixes the two big problems with Flash SSDs. First, random writes are no different than linear writes, so random writes are fast. Often > 20,000 4K write IOPS. Second, the wear performance of the drive improves dramatically.
When you random write to a traditional Flash SSD, each write becomes a write/erase cycle. This write/erase might not happen immediately, but eventually, the drive needs to put the data back in it's place. With current 2MB erase blocks, an "average" 12K random write is 0.59% efficient. You are literally burning through erase blocks 170x faster than "ideal". This is the real cause of concern with drive wearout. The disparity between block sizes at the application and Flash levels.
Now with our software layer in place, the story is very different. We have been running live servers for about 6 months and our ratios range from 93% wear efficiency to about 40% wear efficiency depending on the IO patterns, the amount of free space, and whether or not you are using our latest code. At 93% efficiency, the same drive with 12K average writes lasts 150 times longer.
In simple terms, the 40% to 90% efficiency that we achieve means that you can overwrite an array's entire capacity from 1 to 3 times a day and still hit 7 years "useful life" with MLC drives. SLC are 10x better.
So we agree that tier-1 15K drives are dead.
ps: A baby 5-drive server we recently shipped measured 49,935 read IOPS (4K random) and 31,493 write IOPS (also 4K random) using MLC drives setup raid-5. Our biggest server to date did 124,187 4K reads and 56,462 4K writes, but it was actually controller limited.
Including 4K numbers makes sense. If you are working inside of a filesystem (NTFS, FAT, ext3,... and most others), the smallest IO that actually happens is 4K and these are aligned on 4K boundaries. So 512 byte numbers don't actually mean anything.
Your math is a bit off. Wear leveling lets you use the entire drive. If it is done correctly (and most SSDs are at least very close), then you can guess how many total "random writes" you can do before the drive wears out.
The first thing to guess is the size of the erase block. With most current drives this is 1MB or 2MB. So a 16GB SLC drive has 16,000 / 2 * 100,000 = 800,000,000 total lifetime available writes. At 86,400 writes/day this is 9,259 days or about 25 years.
The same numbers for MLC are 1/10th (10,000 write cycles instead of 100,000) so you wear out in 2.5 years.
Either way, these numbers are "good enough" for some applications and impractical for others.
It would have to be fast for that kind of money. $20,000 for 1TB? A 1TB hard disk costs $200.
Granted, I'm sure you're right and it probably is that fast. There's certainly a niche for it.
(I have some relevant curiosity as I'm developing a database engine.) 1TB of raid protected SSD for 20K was un-imaginable just a few years ago and without MLC commodity drives plus MFT it still a ways off now. Remember that 50,000 IOPS is 200 15K SAS drives. By the times you raid-10 them, put in controllers etc., and even if you "do it on the cheap" (ie from a SAN vendors this will cost a lot more), you are talking $80K and you only get 3.6TB out of this (200 raid-10 36GB drives). Lot of GBs at 100 IOPS is easy. When you need 1000 IOPS it gets a lot harder.
Your license seems rather expensive, but I'm not one of your customers. Still, it's a motivator for other developers to undercut you. This is what we are selling at. Our licenses have actually come down over the last 6 months. Our policy is to follow the drive prices down. We also work with good reseller discounts. I also suspect that you don't have a lot of contact with the enterprise storage space. Things like a "volume management option" on your SAN can cost $10K. Remember that regular FC drives for EMC servers are 3x the "stock" drives cost because of the special firmware.
Other developers will probably come along, but they need to be very careful. The whole area of Flash is a minefield of patents. We have been very careful to keep the scope of what we are doing compartmentalized. We also pay our lawyers very good money. Even though some platforms like Linux have the attitude of "that looks good, I can write it to", the business world does not work that way.
From your basic description, it seems likely that UBI + BLKUBI (block driver over UBI) may give similar functionality to what you described but without the performance, because BLKUBI doesn't group 4k writes consecutively. (There are people using that combination in some embedded products in development now.)
However, UBIFS + loop mount, or LogFS + loop mount, might get close in performance. Both of those present a block device which can be used by any filesystem, but underneath translate to a logged tree-structured filesystem. The layers hurt a lot, especially if you loop mount back to user space. We see overhead in raid controllers that hurt performance 30%. Remember that we are dealing with drives that have 40 uS latency on reads and arrays of drives that can hit you with 100 operations a timer tick.
UBI is too slow at mounting huge drives, but LogFS is good for that. My reading on LogFS is that it can be very slow with large volumes as well. We mount at around 5 - 20 GB/sec depending on the drive layout.
Does your system offer a significant difference from UBIFS/LogFS (containing a single file) + loop mount? I have not seen performance numbers of UBIFS or LogFS published. Our layer on top of a single drive tends to yield ~8000 4K random reads (which is drive dependent) and 4K random writes of around 10,000. Plus you have the benefit of using any file system with any file system feature that you wish.
I suspect BTRFS (similar to ZFS) will start getting good at this eventually. It's not aimed at flash right now, but it's a natural direction for a log-tree-structured filesystem to go in when SSDs become more popular. And it has better RAID than drive-level RAID in many ways. Flash is quite "special". If you are really going to exploit it, you have to target everything you do on the write leg for flash. This means designing your code for absolutely zero random writes with allowable exceptions on mount/unmount.
Current Flash SSDs act like flash but present a block interface. UBIFS appears to require raw flash access thru UBI and YAFFS 1&2 also expect to drive the flash directly.
LogFS can use block devices but does not appear to be "production ready".
I am sure that people will start paying attention to the new flash drives, both from the software and the controllers point of view. MFT has the advantage of working with the hardware and software that we have now. It is also doing some very unique things in terms of free space management, migrating user blocks into usage zones, controlling wearout rates of drives, etc. These are all things that our patent writes and lawyers have been careful to state in our patent paperwork. In fact, the whole flash arena is a minefield of patent stuff, so new flash FS work could get "interesting".
You should also realize that MFT is targeted for hardware configurations that just did not exist a couple of years ago. Specifically, MFT assumes you are willing to burn quite a bit of kernel memory to make the storage run fast. This works out to about 1.2 MB/GB of usable storage. While this is 100% practical for "big servers" with performance critical database, and even quite reasonable for workstation and laptop usage, it is a show stopper for many embedded device environments.
So at this point if you want 1TB of fast Flash SSD storage with good random write performance, you can use STEC Zeus IOPS drives on a EMC array for some wild price (probably approaching $500K) or regular Flash SSDs with our software layer. 1TB using the new 1000 series drive from Mtron would be:
This is 18 drives raid-5 w/ 1 hot-spare. Performance is about 60,000 read IOPS and 50,000 4K write IOPS. Linear speeds on reads top out at 700 MB/sec. Basically you hit Linux raid and controller latency limits long before you saturate the drives. Usable space is 1036 GB in the configuration. The 1000 series is not quite shipping yet, so the largest array like this actually built was assembled by one of our resellers with 22 32GB Mtron 3000 series for about 500 GB of usable space. When you run benchmarks of these against "normal" drives, you get jaded very quickly.
We are constantly adjusting market positioning. There should be a "laptop" version for single drive usage at around $150 list. Check back with our website in about a week to see new stuff.
Our pricing goals are to "follow the drives down", so as drives get cheaper we want our layer to follow them.
And we have talked with Samsung and others (and will continue those conversations). Then again, you know how "really big companies" work.
Slashdot Mirror
All FC "current" cars are 700 bar (~10,000 psi). Busses are often 350 bar, but are moving to 700 bar. Trucks from Nicola were announced at 350 bar, but may actually ship at 700 bar. Nicola are committed to 700 bar fueling stations regardless. The first Kenworth prototype was 350 bar, but the new projects with Toyota are 700 bar. The Toyota prototypes in Long Beach are all 700 bar.
Bottom line is that 700 bar is getting easier to do. If you store "cryo" as liquid H2, then compressing to 700 bar can be done with nearly zero energy using the "boil off" energy. This is how Linde H2 stations work. No this is not a violation of physics. The energy required to get to 9 degrees K can be recovered to get the gas up to 10K psi.
Uber and Lyft drivers drive Prius hybrids because they are the lowest operating cost cars you can buy. The gas engines last to 200K+. Brakes are 100K+. The hybrid system is zero maintenance and the battery does not wear out. And you get 40 MPG is you drive it like a taxi cab.
I also have a Mirai. There are three H2 stations near me. The car is a bit of a science project, but it works very well. FC failure rates are very low. Much lower than reported battery or motor issues from Tesla. The rest of the car is rock solid. The weakest part is the Michelin tires.
Hybrids that regen break are a must. With a BEV, you can re-purpose the motors and battery. With a FC you can re-purpose the motor, but need an additional small battery. The Mirai has a 1.5 KWh NiMH pack for regen and it is up to most uses. If you are going downhill on the GrapeVine north of LA, the run is too long for the regen capacity and you start to use real brakes. I would wager than none of the 5000+ Mirais on the road have needed brakes yet. If they are like the other Toyota hybrids, they will easily last 100K+ miles.
I think the "ideal" is something like the plug-in Mercedes FC they are building in Germany (unfortunately, under 100). It is a FC "hybrid" that has about a 10KWh battery pack that can be plugged in. So it is a PHFCEV. The advantage of the battery is that it mitigates the lower end-to-end efficiency of the FC stack. The advantage of the FC stack if range and quick refilling.
In the end, FCs have some interesting new tech on the way. One university paper describes a "bi-direction FC electrode system". A single set of electrodes can use electricity to split H20 into H2 and O2 (electrolysis) and you can then turn it around and turn H2 and O2 into H2O plus electricity (a FC stack). This is energy storage on a "grid level" scale. Amazingly, they are reporting 75%+ round trip efficiency which is better than stores hydro.
Actually, MPGe is a very solid measurement. Take the amount of "energy" in a gallon of gasoline and compare that energy in another storage form. This is a very big disadvantage to gasoline as ICE engines are about 20% efficient. BEVs are 85% or so (after the electronics). FCEVs are 60% or so, but have the "advantage" of being better in cold weather than BEVs (you can use the FC waste heat to heat the cabin and the capacity of H2 does not degrade with temperature).
MPGe has nothing to do with fuel or electricity cost.
Your numbers are correct, but don't always work with all usage scenarios. I suspect "local traffic" with stop signs and sharp curves need a different calculation Not sure which way it would move.
In terms of straight line, the problem is that both of your cars are "nothing" compared to a 80,000 lb fully loaded semi with 80 psi tires. If you are charging for "road wear out", then the truck should pay "all of it". The cars are a rounding error. But this has it's problems as well.
You have the purpose of the new "red sticker" wrong. It is just a way to enforce an expiration date. New EVs get 3-4 years of carpool access. If you have a "white or green" sticker for a car you bought after 1/1/2017, you can get a red replacement.
After 12/31/2018, new cars will get yet another color good thru 12/31/2022. This is reported to be purple. Next year, another color will roll out.
The "red sticker" did have some glitches. If you were unlucky and got a car in 2016, you would only get 2-3 years. If you bought in 2017, you would get 4-5 years. In the future it is supposed to stay at 3-4 years.
So it is not the "type" of EV, but when you bought it.
Also, a plug-in EV, assuming you actually plug it in, is amazingly good at emissions reduction. I know someone with a Volt that only buys gas four times a year. It is easy to argue that this is a "better solution" than 100% EVs (either battery or FC) because the ramp-up costs can be faster. I am not sure I agree and I like my FCEV very much.
... the obvious, existing, efficient, works today, energy storage. Pump water up-hill. Release it downhill. Low tech. Massive storage amounts with a big enough reservoir. In use at multiple sites in California, often just to make money on power arbitrage (ie, San Louis dam, reservoir, and fore-bay).
While your "logic" seems OK, I have no reason to doubt the author's research on the specific regions that produce barley. Actual, local, modeling is far more likely to produce accurate results that global ideas. I am not saying that your overall approach is wrong. If the author's research only looks at current locations for barley and what would happen to them, then that research is correct, but the conclusion is flawed. If the research also looks at new areas that can start to grown barley, then it would be reasonable methodology.
My real problem with the author is the lack of an economic model for the pricing spikes. Price spikes like this don't tend to happen unless the shortage is extreme. Pulling 10% from a source will not be prioritized to some other "more noble" product like animal feed. The market will use the product by whoever can pay the most for it. If beer production is impacted and price doubles, then beer production can pay a lot more, and the price will level out long before it doubles. Perhaps this is a bias based on "centrally controlled" economies. I don't think German barley farmers could be "told" to not sell to beer producers by the German or EU government, even if the government wanted to.
Your comparison with nuclear waste is as off-point as the rest of your post. If anything, a hydrogen leak is the least destructive event of any fuel leak. Gas and diesel are famous for pollution. Your example of nuclear waste is obvious. BEV battery fires produce all sorts of toxic gasses and hazardous left overs. A hydrogen fire/explosion produces water. If it does not burn, it heads into space. There is zero environmental impact.
Your analysis of hydrogen safety ignores a lot of research. The most important point is that at STP, hydrogen while flammable and even explosive if mixed with air, has a very low energy content. The energy content is low because because the gas is so light. 1/16 the weight of oxygen. About 78 W/hours per cu feet (not kw/hours).
The second point you miss is that hydrogen aggressively goes straight up when there is a leak. Gasoline and diesel pool. Even worse for gasoline, the vapors can pool and ignite. Hydrogen just heads for the sky. There is an on-line video of a two cars, one hydrogen and one gasoline. Both are set on fire with a fuel leak. The gasoline car is melted down. The hydrogen car is basically intact and can even roll on it's own tires at the end.
If you look at hydrogen fueling stations, they either do not have roofs, or they are designed to vent up. Air Products had a leak from about 30 kg of hydrogen tanks on a delivery truck. The damage was minor. The over-reaction was the biggest issue. Even the truck drove away. Also, the other 170 kg of hydrogen, on the same truck, never burned. The accident itself was caused by a pressure release "burst disk", in this case the wrong pressure disk was installed.
Issues about metal embrittlement are interesting, but not on point. A hydrogen leak will not "attack metals". If you build a tank out of the wrong stuff, it will fail. Don't build the tank out of the wrong stuff. Gasoline attacks a lot of different rubber seals. It is the same for diesel. You have to build the hardware with appropriate materials. In the case of automobile hydrogen tanks, this is fiberglass, plastic, and Kevlar. Hydrogen cars, and hydrogen filling stations are a lot safer than gasoline. A purely compression explosion is an interesting thought experiment, but even in a major crash, it is not that much energy (compared to the crash). In such a case, the hydrogen will only make it a few feet sideways before heading skyward.
And you never withdrew your 100 mile range and fueling a BITCH comment. There are issues of cost, available supply, and round trip energy efficiency. Then again, for some applications, hydrogen FC vehicles work really well. Long haul trains where caternary wires are too expensive. Long haul trucks. For passenger cars, Toyota believes that FC tech will be cheaper to build than batteries. Not sure if they are right or not, but they have a lot of experience, so betting against them is dubious. And I would much rather have a FC car in Lake Tahoe in the winter at -10F that a BEV Bolt or Tesla.
The future is a plug-in hybrid. Hydrogen and a FC for range, and a small-ish battery. With 50 miles of BEV range and 300+ miles of FC range, you have a Chevy Volt that does not pollute at all. Hydrogen cost and round trip efficiency are not all that important as the plug-in battery does most of the miles for most people. This also mitigates the hydrogen round trip efficiency and cost. With a bigger battery, the FC can be smaller, so this combo costs less to build. The battery is still small enough to not need a "super charger", so the grid is not impacted as much. Mercedes has one of these in tests now. The reason they are not building this is that there needs to be demand for H2 stations first. This hybrid design is no more complicated that the stock FC design, it just has a bigger regen battery and the charging electronics. Plug in FCs is what will win for all but NEV applications (Neighborhood Electric Vehicle).
FC Cars are nothing like you describe. Range is 300+ miles. Fueling is under 5 minutes from empty and generally un-eventful. The H2 supply chain breaks down far more often than the cars or the fueling stations (and the supply chain is getting better).
H2 tanks are extensively tested including such items as shooting them with 50 cal bullets. It takes two bullets to the same location to pierce the tank, and then it is a leak and the H2 gas that goes straight up. If it ignites, all the flame goes straight up as well. It is very hard to create an explosive mixture, and even then the explosive over-pressure is not really an explosion (a refinery in Wilmington, CA had a very large H2 tank explode a number of years ago. I felt the pressure wave 15 miles away. Even though many people were on site, no one was even injured.) I always wondered if H2 was a greenhouse gas. The answer is no as it actually escapes into space and literally leaves the planet (Helium does this as well). There are design differences, but generally H2 is far safer than gasoline car. Even a BEV car has real safety issues. Did you know the fire department needs to "saw" two spots on a Tesla Model 3 to break the high voltage "loop".
Reliability is also very good with 100K miles warranty and almost no required maintenance. Even the breaks last forever. I drive my FC car every day and it is an excellent car that gets me where I want to go in safety and comfort. My closest H2 station is about 4 miles away with 2 others within 15 miles. I see other FC cars on the road most days. 5100+ in California. http://www.cafcp.org./
You are shockingly wrong. Storing hydrogen at pressure for very long periods (decades) is now quite easy. You have to use the correct materials, but it is cost effective and the leak rate is basically undetectable. The correct materials are not exotic (fiberglass, plastics, kevlar)
We have hydrogen cars in California (over 5000). People drive them. People fill them, go on vacation, and come back six weeks later and they are still full. There are inefficiencies and costs, but the tech works reliably and the cars are practical.
... and companies routinely produce cars for "non California" markets. Take the Chevy Volt. Hybrid, "green". In California, they have to use a different gasoline generator to meet emission standards to qualify for stuff like carpoll stickers etc. So California "rules" are not everyone's rules and car makers often build differently in other states.
You are wrong. Non exhaust emissions are the three factors you specify. One of these, break wear, is dramatically lower on "electrified" cars. My Prius brakes last 100K+ miles. Tesla brakes, the same. My Mirai brakes, the same. My Chrysler mini-van, 15K tops. My wife's Honda FIT, 25K tops.
So road and tire emissions are "perhaps" marginally higher because of higher weight, but brakes move radically in the other direction.
Water vapor is a big greenhouse gas when releases in the stratosphere. Water vapor at the surface does not translate into water vapor at altitude. If it did, then Florida humidity would doom us all.
Plus you need to consider that gasoline and diesel engines also produce a lot of water vapor.
Actually a lot of water:
30 kg of H2 = 30 x (16+2)/2 = 270 kg of water or 71 gallons of water.
I have been awaiting some non-intel results on the X25-M drives for a while. Intel has been very good at putting marketting spin on this drive. While it is a good drive, it is nice to finally see some real numbers.
There appear to be two sites that have posted IOMeter results. I like IOMeter numbers because they don't try to hide the details and are easy to reporduce. Just for fun, I ran IOMeter File-Server, Workstation, and Database tests on an in-house MLC SSD to see how it compared. My results are here compared with the two sites X25-M numbers.
File Server:
Numbers are "Outstanding IOs", MFT IOPS, Intel X25-M @ pcper.com, and Intel X25-M @techreport.com.
1 - 2652.64 / 3000 / 850
2 - 2724.80 / 3700 / 1010
4 - 2224.81 / 4000 / 990
8 - 2472.40 / 4800 / 1040
16 - 2754.18 / 5200 / 1060
32 - 2783.93 / 5800 / 1055
Workstation:
Numbers are "Outstanding IOs", MFT IOPS, Intel X25-M @ pcper.com, and Intel X25-M @techreport.com.
1 - 3346.12 / 850 / 850
2 - 3582.49 / 860 / 1000
4 - 3637.09 / 910 / 990
8 - 3657.64 / 900 / 1030
16 - 3692.25 / 890 / 1060
32 - 3716.06 / 900 / 1050
Database:
Numbers are "Outstanding IOs", MFT IOPS, Intel X25-M @ pcper.com, and Intel X25-M @techreport.com.
1 - 3705.97 / 1800 / 980
2 - 3947.26 / 1950 / 600
4 - 3948.28 / 1100 / 600
8 - 3838.48 / 975 / 600
16 - 3800.85 / 925 / 610
32 - 3930.27 / 800 / 620
Someday I will learn how to post tables on /.
A couple of points here. First, my numbers from the sites are from their graphs, so I might be off by a few percent.
Second, it looks like pcper.com's numbers for File-Server are messed up. They are too high at larger queue sizes. File-Server numbers should not be better than workstation numbers.
Regardless, these tests show two things. First, the Intel drive is a very good drive when comparing it with other "non managed" drives. Flash storage is a strange thing that really benefits from software that is designed for flash storage. That is what MFT (Managed Flash Technology) is. MFT is basically a transparent layer under the filesystem that re-ordered reads and writes so that Flash "is happy". Flash file systems do much the same things, although less aggressively than MFT.
Also, from what I can tell from Intel market-hype, their drive should last about 10x longer than other MLC drives for typical random-write workloads. This 80GB drive is designed for 20GB/day of random writes for a 5 year life. With MFT, a 64GB MLC drive can do about 100GB/day for a 7 year life so the software solution is still better.
We are shipping servers with MLC drives now. Their lifespan and performance is quite good. Now the "experts" might be behind the time, but what else is new.
Our typical server with MLC Mtron's run about 8000 4K read IOPS/drive. Writes are 40 MB/sec per drive, but we always write linearly so this still works out very well on mid-sized arrays. Even a single drive does 8000+ 4K write IOPS/drive. Our biggest issue is that current HBA and raid controllers don't scale as the arrays get big. Once your are above 100,000 IOPS, the HBAs just have no clue. Lifespan is also more than acceptable with 7-20 year lifespan assuming you overwrite the array daily.
For your 500TB/month application, you should be looking at MAID. Massive arrays of idle disks. If your read needs are semi-online, the spin up times can be manageable. I doubt that SSD will get to cost parity with HDDs in your type of application any time in the next 10+ years.
Watch out for MFG figures on writes.
140 years at 50 GB/day is for linear writes. If you are doing random writes you have to scale this based on your average write size.
If your average random write size is 12K, then the amount of writes will be 12KB/2MB of the above amount or about 0.58% as much data. This is 170x worse.
Now this is an SLC drive, so you are probably still OK.
This is "fixable".
If you want to test a beta of our MFT software, drop an email to sales@easyco.com or read up at http://easyco.com./
ps: my apologies for the blatant advert. I think my karma can stand it. At least I was short ;)
Flash $/GB is already lower than 15K 36GB 2.5" drives. $/IOPS is silly compared to 15K drives. Power and physical space are also wins on the SSD side, so this leaves only wear.
Our company ships servers with SSDs and software that "linearizes" the writes to the drives. This fixes the two big problems with Flash SSDs. First, random writes are no different than linear writes, so random writes are fast. Often > 20,000 4K write IOPS. Second, the wear performance of the drive improves dramatically.
When you random write to a traditional Flash SSD, each write becomes a write/erase cycle. This write/erase might not happen immediately, but eventually, the drive needs to put the data back in it's place. With current 2MB erase blocks, an "average" 12K random write is 0.59% efficient. You are literally burning through erase blocks 170x faster than "ideal". This is the real cause of concern with drive wearout. The disparity between block sizes at the application and Flash levels.
Now with our software layer in place, the story is very different. We have been running live servers for about 6 months and our ratios range from 93% wear efficiency to about 40% wear efficiency depending on the IO patterns, the amount of free space, and whether or not you are using our latest code. At 93% efficiency, the same drive with 12K average writes lasts 150 times longer.
In simple terms, the 40% to 90% efficiency that we achieve means that you can overwrite an array's entire capacity from 1 to 3 times a day and still hit 7 years "useful life" with MLC drives. SLC are 10x better.
So we agree that tier-1 15K drives are dead.
ps: A baby 5-drive server we recently shipped measured 49,935 read IOPS (4K random) and 31,493 write IOPS (also 4K random) using MLC drives setup raid-5. Our biggest server to date did 124,187 4K reads and 56,462 4K writes, but it was actually controller limited.
Including 4K numbers makes sense. If you are working inside of a filesystem (NTFS, FAT, ext3, ... and most others), the smallest IO that actually happens is 4K and these are aligned on 4K boundaries. So 512 byte numbers don't actually mean anything.
Your math is a bit off. Wear leveling lets you use the entire drive. If it is done correctly (and most SSDs are at least very close), then you can guess how many total "random writes" you can do before the drive wears out.
The first thing to guess is the size of the erase block. With most current drives this is 1MB or 2MB. So a 16GB SLC drive has 16,000 / 2 * 100,000 = 800,000,000 total lifetime available writes. At 86,400 writes/day this is 9,259 days or about 25 years.
The same numbers for MLC are 1/10th (10,000 write cycles instead of 100,000) so you wear out in 2.5 years.
Either way, these numbers are "good enough" for some applications and impractical for others.
Granted, I'm sure you're right and it probably is that fast. There's certainly a niche for it.
(I have some relevant curiosity as I'm developing a database engine.) 1TB of raid protected SSD for 20K was un-imaginable just a few years ago and without MLC commodity drives plus MFT it still a ways off now. Remember that 50,000 IOPS is 200 15K SAS drives. By the times you raid-10 them, put in controllers etc., and even if you "do it on the cheap" (ie from a SAN vendors this will cost a lot more), you are talking $80K and you only get 3.6TB out of this (200 raid-10 36GB drives). Lot of GBs at 100 IOPS is easy. When you need 1000 IOPS it gets a lot harder. Your license seems rather expensive, but I'm not one of your customers. Still, it's a motivator for other developers to undercut you. This is what we are selling at. Our licenses have actually come down over the last 6 months. Our policy is to follow the drive prices down. We also work with good reseller discounts. I also suspect that you don't have a lot of contact with the enterprise storage space. Things like a "volume management option" on your SAN can cost $10K. Remember that regular FC drives for EMC servers are 3x the "stock" drives cost because of the special firmware.
Other developers will probably come along, but they need to be very careful. The whole area of Flash is a minefield of patents. We have been very careful to keep the scope of what we are doing compartmentalized. We also pay our lawyers very good money. Even though some platforms like Linux have the attitude of "that looks good, I can write it to", the business world does not work that way. From your basic description, it seems likely that UBI + BLKUBI (block driver over UBI) may give similar functionality to what you described but without the performance, because BLKUBI doesn't group 4k writes consecutively. (There are people using that combination in some embedded products in development now.)
However, UBIFS + loop mount, or LogFS + loop mount, might get close in performance. Both of those present a block device which can be used by any filesystem, but underneath translate to a logged tree-structured filesystem. The layers hurt a lot, especially if you loop mount back to user space. We see overhead in raid controllers that hurt performance 30%. Remember that we are dealing with drives that have 40 uS latency on reads and arrays of drives that can hit you with 100 operations a timer tick. UBI is too slow at mounting huge drives, but LogFS is good for that. My reading on LogFS is that it can be very slow with large volumes as well. We mount at around 5 - 20 GB/sec depending on the drive layout. Does your system offer a significant difference from UBIFS/LogFS (containing a single file) + loop mount? I have not seen performance numbers of UBIFS or LogFS published. Our layer on top of a single drive tends to yield ~8000 4K random reads (which is drive dependent) and 4K random writes of around 10,000. Plus you have the benefit of using any file system with any file system feature that you wish. I suspect BTRFS (similar to ZFS) will start getting good at this eventually. It's not aimed at flash right now, but it's a natural direction for a log-tree-structured filesystem to go in when SSDs become more popular. And it has better RAID than drive-level RAID in many ways. Flash is quite "special". If you are really going to exploit it, you have to target everything you do on the write leg for flash. This means designing your code for absolutely zero random writes with allowable exceptions on mount/unmount.
Current Flash SSDs act like flash but present a block interface. UBIFS appears to require raw flash access thru UBI and YAFFS 1&2 also expect to drive the flash directly.
LogFS can use block devices but does not appear to be "production ready".
I am sure that people will start paying attention to the new flash drives, both from the software and the controllers point of view. MFT has the advantage of working with the hardware and software that we have now. It is also doing some very unique things in terms of free space management, migrating user blocks into usage zones, controlling wearout rates of drives, etc. These are all things that our patent writes and lawyers have been careful to state in our patent paperwork. In fact, the whole flash arena is a minefield of patent stuff, so new flash FS work could get "interesting".
You should also realize that MFT is targeted for hardware configurations that just did not exist a couple of years ago. Specifically, MFT assumes you are willing to burn quite a bit of kernel memory to make the storage run fast. This works out to about 1.2 MB/GB of usable storage. While this is 100% practical for "big servers" with performance critical database, and even quite reasonable for workstation and laptop usage, it is a show stopper for many embedded device environments.
So at this point if you want 1TB of fast Flash SSD storage with good random write performance, you can use STEC Zeus IOPS drives on a EMC array for some wild price (probably approaching $500K) or regular Flash SSDs with our software layer. 1TB using the new 1000 series drive from Mtron would be:
20 64GB SSDs $ 9,560
Chassis $ 1,000
Raid Ctrls $ 900
MFT License $ 8,250
-----
19,710
This is 18 drives raid-5 w/ 1 hot-spare. Performance is about 60,000 read IOPS and 50,000 4K write IOPS. Linear speeds on reads top out at 700 MB/sec. Basically you hit Linux raid and controller latency limits long before you saturate the drives. Usable space is 1036 GB in the configuration. The 1000 series is not quite shipping yet, so the largest array like this actually built was assembled by one of our resellers with 22 32GB Mtron 3000 series for about 500 GB of usable space. When you run benchmarks of these against "normal" drives, you get jaded very quickly.
We are constantly adjusting market positioning. There should be a "laptop" version for single drive usage at around $150 list. Check back with our website in about a week to see new stuff.
Our pricing goals are to "follow the drives down", so as drives get cheaper we want our layer to follow them.
And we have talked with Samsung and others (and will continue those conversations). Then again, you know how "really big companies" work.