My guess is something about the waveform of the inverter is tripping up something in the power supply. Many moons ago I worked on laser printers and we had a customer who was melting fusers. Turned out their UPS had small but fast spikes around the zero-crossing that would exceed the allowable dV/dt and trigger the triac to turn on even though there was no gate signal present. That's not the mechanism here but I would scope the AC line from the inverter. I bet it's not clean and something about the weird waveform is confusing the power supply. I don't think the 4500 W inverter is even noticing the loads from the router power supply. The power supply is misbehaving browning out briefly. Nothing in the router will run straight from that supply though, there are DC-DC converters to make the lower voltage used on the board. It would be kinda fascinating to figure out what is really happening to lead to the described behaviors.
First, the force that is proportional to the square of the speed is the drag force, which means it's the force you need to supply just to keep the speed from dropping. Power = force * speed is a different "force" - it's the force produced by the engine.
Second, power output of an engine typically has an RPM where it peaks. Past that point, more speed means less power output, which means much less force output, because the force is the power divided by the speed. But force needed still increases as the square of speed.
It's exactly how it works and the math is not complicated.
Suppose you have a vehicle w/ 3 m^2 frontal area, drag coefficient of 0.3 and it's travelling at 30 m/s. Using this calculator https://www.symbolab.com/calculator/physics/drag-equation you can find that will require about 500 N of force (use density of 1.225). The power at that operating point is the product of speed and force, or 30 m/s * 500 N = 15 kW.
Now let's change the speed to 40 m/s. That bumps the force to about 900 N. Now we would calculate power as 40 m/s * 900 N = 36 kW.
Changing these numbers to horsepower we get 20 hp and 48 hp.
The force goes with the square, the power goes with cube. There are assumptions here - for example, if you have a headwind this statement is no longer true because the speed in the drag equation is the air speed of the vehicle (goes up with headwind / down with tailwind) but the third speed factor is the ground speed of the vehicle (because that's based on the physics "work is equal to force times distance" and power is the rate of work).
The graph of an internal combustion engine's power at wide-open throttle vs. engine speed is irrelevant, unless you are trying to figure out which gear ratios would let the engine make enough power to drive the vehicle under those conditions.
The first problems I came to Julia to solve were ODE simulations in which it's just as critical that the stuff I write and rewrite over and over again (the actual differential equations of my model and associated simulated controller callbacks) runs fast as it is that the pre-written stuff of the library (the solvers or integrators) runs fast. To the best of my knowledge I can't do that in python.
This example (DifferentialEquations.jl in particular and SciML.ai in general) is one of the places where Julia leads the pack.
When I first used Julia it felt rather strange in a lot of ways (I had used python for about 20 years), but after 2 years when I go back to python (and of course there are places where it makes more sense to use python) it feels primitive as there are a lot of very nice features of Julia that I suddenly miss.
Ok... I read that. I have to say it's very not intuitive. I like Julia overall, but this is an area where I scratch my head and say "Hmmm... why would they do that?" (performance, I'd guess, but it's not very user friendly). Is there a set of guidelines for translating Python/numpy code to Julia because indexing in Python/numpy works a lot differently (and seems more intuitive).
I will also say, a number of times I've thought something like "why would they do that?", and some months later (I'm kinda slow) I would realize that it now makes sense.
If you specify a distribution using, say, Float32s, you'll get a distribution in Float32s. I'm guessing the machine learning example used Float32s so they would better take advantage of a GPU. It's almost always true in Julia that you can combine your choice of numeric type with other neat packages without the author of either one being aware of the other. Want to simulate ODEs in Float32 for speed on GPU, in Float64 for GPU, or if you have an exotic need for high accuracy use something bigger but slower, you can do it.
