I remember in high school chemistry (or physics?) we had a wooden model of the benzene ring with the ground state molecular orbitals. Diameter about 30cm.
Isn't sf6 on the way out due to it being an extremely potent GHG?
Not sure what the alternative would be for really high voltages? Vacuum insulated switchgear seems to be a hot topic at the moment, but not sure how it'd work with such extreme voltages?
How does this generally work wrt brakes needing to be used occasionally to not rust shut? Even with an ICE car if you don't drive a lot, and drive in a fuel efficient way (e.g. coasting towards red lights) this can be an issue resulting in an expensive surprise when you need to replace disks long before they are worn out.
Some EVs (Teslas are ones I know of) have software that occasionally lightly applies the brakes to keep them clean.
Also, on EVs with LFP batteries the brakes do get used a bit more, because a full and/or cold pack usually can only take very limited power from regenerative braking. Depending on the implementation in the vehicle, brakes are either applied automatically to still allow for one-pedal-driving (aka. "brake blending", making the difference unnoticeable to the driver), or throttle-pedal regen is simply capped and the driver has to use the brake pedal when they notice that regen power is not sufficient.
Have Tesla with badly corroded rear brake discs. Software does clearly not help here. It was very bad at the end of winter. Now it’s getting better in spring. I am curious how does it look in autumn. Trying to use mechanical brakes occasionally. I had same story with corroded rear brakes on BMW. The solution was mechanical handbrake.
Which one do you have? I had the same issues with my '19 M3P, all the brakes were badly corroded a year into the lease. Apparently the software to keep this under control came a bit later into the lifecycle, and is not very effective if the problem is already apparent. Anecdotally, what was _very_ effective at cleaning up the brakes was blasting it for a couple laps around the Nürburgring Nordschleife - the grooves / corrosion went away almost completely :D
Now I have a RWD Model 3 with an LFP pack (SR+/"base model"), and have to use the brakes much more than with the old car (that had an NMC pack and almost never limited regen). Over two years in, brakes seem good as new, hopefully they stay this way.
Model Y AWD which saw its first winter recently. So the software should be the recent one. Left side is much worse than right side. Quality problem? Maybe swapping discs before winter could save them. Or replace them before TÜV check, the parts aren’t that expensive.
There is an additive called 6PPD added to tires to prevent them from degrading in the atmosphere, and it has been found that when this thing reacts with ozone in the air it forms another compound 6PPD-quinone which is highly toxic to some fishes. Weirdly enough it's highly toxic to some species of salmon but not to other salmon species.
Presumably there's work ongoing to find an less damaging replacement, but I haven't heard of any.
> This being said, I’ve noticed that many a “big EV” driver will take off from red lights like they’re driving a dragster.
That would be my guess. Occasionally looking at specs from EV's coming on market, they seem to have very powerful engines, and of course the torque curve of electric motors is fantastic. So if you have such a car, and a heavy foot, I can well imagine you going through tires at a decent clip.
The kilogram is no longer defined by a physical artifact, fwiw.
Anyway, the point is the inconsistency in the system due to the kilogram being the base unit. So derived units are defined in terms of kilogram rather than gram. Say, the unit of force, Newton (N), is defined as kgm/s^2 and not gm/s^2). Or pressure, Pascal (Pa) which is N/m^2 which inherits N being defined in terms of the kilogram). And so on. Anyway, an annoying inconsistency maybe but doesn't really affect usage of the system once you get used to it.
> As an aside, that kABI guarantee only goes so far. I work in HPC/AI, and the out-of-tree drivers we use like MOFED and Lustre drivers would break with EVERY SINGLE RHEL minor update (like RHEL X.Y -> X.(Y+1) ). Using past form here because I haven't been using RHEL for this purpose for the past ~5 years, so maybe it has changed since although I doubt it.
I'm not sure what the underlying problem here is, is the kABI guarantee worthless generally or is it just that MOFED and Lustre drivers need to use features not covered by some kind of "kABI stability guarantee"?
I work on Lustre development. Lustre uses a lot of kernel symbols not covered by the kABI stability guarantee and we already need to maintain configure checks for all of the other kernels (SuSe, Ubuntu, mainline, etc) that don't offer kABI anyway. So in my opinion, it's not worth the effort to adhere to kABI just for RHEL. Especially when RHEL derivatives might not offer the same guarantees. DKMS works well enough, especially for something open source like Lustre.
Honestly, I'm not sure who kABI is even designed for. All of the drivers I've interacted with the HPC space (NVIDIA, Lustre, vendor network drivers, etc.) don't seem to adhere to kABI. DKMS is far more standard. I'd be interested to know which vendors are making heavy use of it.
The problem is that some vendors don't participate or care about the KABI program. They have their reasons, maybe the cost is too high to maintain RHEL compat and upstream compatability, so they simply choose the one that is the least pain to adhere to when a customer requests a fix.
If companies talked to partner engineering about their kABI requirements, I think there would be a lot less breaking however I'm sure that i'm oversimplifying the reason that they cant or wont do this.
I completely understand that the work is non-trivial and that they have many environmental pressures that affect their choices. The KABI is the olive leaf, they can take it or not.
> The version and ABI guarantee is not for everyone.
As an aside, that kABI guarantee only goes so far. I work in HPC/AI, and the out-of-tree drivers we use like MOFED and Lustre drivers would break with EVERY SINGLE RHEL minor update (like RHEL X.Y -> X.(Y+1) ). Using past form here because I haven't been using RHEL for this purpose for the past ~5 years, so maybe it has changed since although I doubt it.
In that boat now, weak-modules means you sometimes get lucky, and can reuse. However, since it's more effort to determine if a rebuild is needed than just slap the "build all the vendor kmods and slurm" button, we tend to build for each kernel.
IIRC el8 added kernel symbol signature hashes as Provide/Requires, with automation to extract them at build time, so kmods got a lot easier to deal with.
Sorry, I was being imprecise. Rebuilds per se are no problem, as both MOFED and Lustre provide sources, and DKMS nicely automates rebuilding when installing a new kernel image. The actual problem is that RHEL minor releases would also break kernel internal API's, and thus building the kernel modules would fail.
The kernel parts of MOFED are largely backports of the latest and greatest upstream kernel drivers to the various distro kernels their customers actually run. (The non-kernel parts of MOFED is mostly open source but does contain some proprietary special sauce on top, like IIRC SHARP support isn't available in FOSS.). The HPC community does tend to want to use the latest RDMA drivers as those are critical for at scale performance.
For Lustre, the client driver was upstreamed into staging, where it sat AFAIU largely unused for a few years until it was ripped out again. The problem was that Lustre developers didn't adopt an upstream-first development approach, and thus the in-kernel driver was basically a throw over the fence fork that nobody cared about. I think there is an effort to try again and hopefully adopt an upstream-first approach, remains to be seen whether it'll succeed.
reply