Probably not. Complex things break a lot. You want the life-critical code to be as simple as possible, with proven correctness if possible. I bet you'll not find 1 recursion in ISS flight code, and you'll not find anything that's not having an known-upper-bound on time run.
It is possible that code itself is not that complex, but the interaction between all modules certainly has a high level of complexity.
"In the International Space Station’s U.S. segment alone, more than 1.5 million lines of flight software code run on 44 computers communicating via 100 data networks transferring 400,000 signals (e.g. pressure or temperature measurements, valve positions, etc.)."
This is a critical part to consider in "current" fusion research. Most of it rely on the deuterium / tritium fusion which will probably require a classic nuclear plant to generate the fuel. This makes the whole "infinite clean energy" claim pretty bogus for now.
We know how to contain strong neutron flux. We know how to contain short to medium lived activated materials, we know to avoid cobalt is hardened materials, we don't have to deal with water based corrosion in a fusion containment, though neutron embitterment may be a similar issue.
It is very unclean, especially since it requires conventional fission reactors to produce the tritium. It’s theoretically possibl to breed tritium in the reactor blanket of the fusion reactor, but that’s a totally unsolved problem. The high neutron flux of the D-T reaction also destroys all known materials in short order by disrupting the atomic structure of the materials through atomic spallation. There are plenty of other hurdles to making a fusion power plant as oppposed to just a research reactor, but those are big ones.
There is currently a good stock of tritium that would power many such reactors for a while. So it's not insane to put off the tritium problem for later.
The global inventory of tritium is estimated around 20Kg, that's barely enough for research purposes and ITER. Fueling DEMO, the first commercial fusion reactor will require about 10Kg, and at 2-4GW thermal it will require about 300g of tritium per day, completely depleting the existing stockpile in a single month of operation.
So the existing stock is insuficient for even a single commercial reactor. Talking about container sized fusors without ensuring tritium self-sufficiency is a particularity distilled form of insanity.
The device level images are a mix of Scanning Electron Microscope (SEM) and visual microscope images.
A bunch of different ways. Depends on the material being measured but measuring sheet resistance (effectively, you can back calculate the thickness by measuring the resistance of a square of known size) and light scattering off the surface are the most common.
A key feature of the plasma magnet is that the diameter of the magnetosphere increases as the density of the solar wind decreases as it expands away from the sun. The resulting expansion exactly matches the decrease in density, ensuring constant thrust. Therefore the plasma magnet has a constant acceleration irrespective of its position in the solar system.
I'm not 100% sure about the science here, but the "exactly" looks a bit magical to me. If I understand the concept correctly, when the sail is closer to the sun, the particles "pressure" on the sail will "compress" and reduce its effective area.
Without having studied the equations, but having seen similar phenomenon occur in other work my guess would be that the equation to determine the total area of the magnetosphere (let's say A = M(V,r) where A is the area and V is applied voltage and r is the distance from the sun) includes a component based on the density of the solar wind at that position.
The component is likely in the denominator because as solar wind density goes down we'd expect the magnetosphere size to increase.
Now, the solar pressure is something like P=S(r) where P is the pressure and r is the distance from the sun and S contains some geometry and solar power terms.
If we look at M(V) we could probably then find an M'(V) s.t. M(V,r) = M'(V) / S(r). To get the force produced by the drive we'd take M(V,r) * S(r) which cancels out all radius terms.
Mathematically this would indicate that the thrust on the magnetosphere would be invariant for all r within the solar system (after that point other terms within S() and M() that are based on solar output would likely start to break down)
A shared_ptr is a reference counted allocator, which has nontrivial runtime overhead. It's not what you want when you just want to pass down a reference to some object allocated as part of an enclosing stack frame.
The problem in the article is that the code has a firm RAII promise that the higher level object will be destroyed correctly (i.e. never before any called functions use it). But the author wants to add safety by ensuring that the called functions aren't able to store or copy the pointer or otherwise muck with that allocation promise. And the chosen syntax with unique_ptr works well enough I guess (though it will break if you need the same object used across two disjoint subtrees of the calll tree).
Personally? If this is really what you want then Rust is probably a better proposition as it doesn't require extra syntax for this case. Is it really what you want? Dunno. A simple application of "const" to a few places can get you maybe 70% of the way to the goal here in designs like this.
> though it will break if you need the same object used across two disjoint subtrees of the calll tree
Yes, while I prefer to use plain values or unique_ptrs when I can, I will use C++ references (or plain pointers) in this sort of situation. Basically in C++ I think an of old-style pointers/refs as Rust-like "borrowed" references.
This is an example of how the Rust safety model is really about compiler enforcement of good practices from C and C++ (as opposed to, say, GC which is a distinct practice). I appreciate what Rust is doing, but it is also true that good coding conventions in C++ will get you 90% of the way there.
> good coding conventions in C++ will get you 90% of the way there
For those that need it, SaferCPlusPlus conventions will get you even further.
> Basically in C++ I think an of old-style pointers/refs as Rust-like "borrowed" references.
They key safety feature of Rust references is that they have "scope lifetime" and their target is guaranteed to be alive for the duration of that scope lifetime. You can use SaferCPlusPlus' "scope pointers"[1] to achieve this in C++.
Scope pointers can be explicitly converted to raw pointers, so they can be used with existing "legacy" functions. But you get even more benefit when you change your function interfaces to support scope pointers directly[2]. For example, it would prevent the function from (inappropriately) putting a copy of the scope pointer into "long term storage" (like Rust does).
The Réso is awesome. Next time I'm in Montreal, I want to stay at the Hyatt at the Complexe Desjardins: It's possible to get all the way from your hotel room to the Place D'armes Metro station a few blocks south or the Place Des Arts Metro station a few blocks north, all without going outside, not to mention a mall, a performing arts center, and countless restaurants.
