(nitpicking)
That's correct if you take into account the skin effect when computing the cross-section area (or if you design your transmission line to avoid it. Better solution). But at 50/60 Hz, it's negligible (the "skin depth" of copper at these frequencies is around 9mm)
I don't really know what are the exact regulations, but I've read the article. It says:
> The rules do not apply to agriculture, which is covered by different regulations and makes up the bulk of water use in the state. Cuts in supply based on seniority were imposed in the last year. Some of them have been rolled back already as water has become more available.
Doesn't that mean that there are also regulation on the agriculture part of water consumption?
The movie Chinatown was a "based on true events" kind of deal relating to California water rights when the state was going through growing pains in the post-WW1 boom.
The best I can figure, water rights (basically a contract which establishes how much water you have a right to use from which surface water sources) has to do with seniority. In 2015, the state regulators adjusted the coefficients in an effort to prevent starvation of downstream water rights[1].
I don't know how residential water districts compete with legacy water rights ownership, but I do know that residential water districts for the vast majority of the state's population get their water from just a small handful of inland reservoirs.
This is the absolute best long read I've seen on the Colorado River and California water rights.
Interestingly, many forms of water conservation for agriculture actually have a negative impact. If farmers keep the same allocation but use it more efficiently, they're able to grow more, and there's less runoff so less groundwater recharge and less return to the river.
It depends on what you call a "physics simulator". I don't know what they do at JAXA, but I would guess that they have at least some kind of simulator. But on thing which is difficult to avoid is to feed your simulator configuration with the same value as your satellite.
From what I understood, the failure (the final one, in safe mode, which is not the initial error but the one which killed the satellite) seems to be an error in thrust parameters. Somewhere in the software satellite, you evaluate your rotation speed. In safe mode, you probably want to nullify this speed. Let's say that you have measured 1 deg/s around the X axis. The controller will say "give me a torque of - 10 Nms around X (10 is a made up values, and I don't take the inertia tensor into account)
The next stage of the software will convert this "-10 Nms around X" to valve opening of one or more thruster. To do this conversion, it must know how much torque is generated by each thruster. This information must be on board, but to compute it, you need: each thruster position, each thruster direction, each thruster force intensity, the satellite center of mass position.
It's not a problem, this information is available somewhere, in a database. The propulsion engineer, together with people doing the CAD model, the people computing the mass parameters, they have got these values. Someone has checked them also.
Now imagine a scenario where this has been tested but the error has not been found. I don't say it happen like this , but I've encountered this kind of situations. Fortunately, always before launches ;-)
Let's look at the simulator side. What does it need to simulate the actuation of this thruster? Basically, the same information. If the valve is open for t secondes, the torque is t*(F x r). Where does it get this value? Same database, it's the same spacecraft, the same thruster, the same position, the same direction, ...
It absolutely makes sense to not duplicate this value.
But what happens if the value is wrong? For example, if the database says that you should have the thrust vector direction, but you put the direction of the mass flow? You just get -T instead of T for this thruster, both on the simulator and the software. Not a problem, your simulation can still works. (if you do it only for one thruster, it may not work, as you may not have control around one axis. But if you do it for all, or maybe for just two opposite thruster, it still works. It may be or may not be noticed that it does not makes sense)
The verification of this database is an extremely difficult (and boring, IMHO) job. You have trap everywhere. You have this kind of sign error, you need to know if the rotation matrix is from reference frame A to B, or B to A, does a 1 in a bit field means actuating your RW CCW or CW, is the tachometer of the wheel in the same direction, how are the thruster numbered from 1 to X, bonus if you have multiple different ordering method because the software guy, the electrical guy and the mechanical guy use a different one...) And this base is huge. (people managing this merit respect, but we prefer to yell at them because they are always late. Due to our own input, of course)
> Does this mean that error will compound if either the attitude or compensation are calculated or performed incorrectly? If so, is there a way to reduce that compounding, perhaps by making them more independent systems?
It's more the opposite. (well, not quite exactly the opposite, but I'll try to explain. It's a simplified explanation, I hope I didn't make any obvious error in the simplification)
IRU is mainly composed of gyroscope, measuring the spacecraft angular rate over three axis. They don't give you the absolute orientation. Of course, if you know the initial orientation, you could integrate angular rotation and have the current one. Except that in reality, you have several problems. The first one is that even if you have a perfect unbiased gyro, you need a continuous time integration, and not use sample every 0.X seconds. But the main problem of gyro are the instantaneous bias, and the slow change in bias over time. And when you integrate bias over a long time, the result diverge (all the type of gyroscope have these, but the level are different. There is also added noise on top and quantisation of the output. You get value over 8, 12 or 16 bits, not a real number. But integrating this should average to 0, so that's ok)
So you can't use only an IRU.
Could you use only a star tracker? Again, in an ideal world, yes. The star tracker gives you the absolute orientation and if you want the angular rate, you can get it by derivation (by differentiating, in discrete time) But the star tracker has its own problem. It cannot gives you an orientation when you turn it on, it has an acquisition phase first. It does not work when you have the sun in the field of view, or the earth, and sometimes also the moon. (it's basically a camera trying to take picture of the stars.Plus a lot of complicated software) As it includes a lot of complicated software, you don't necessarily want to use it in safe mode (software has bug. Also it uses electrical power) Sometime STT don't work when the rotation speed is too high also. And complexity also means more failure modes.
So STT only for all phases, including safe mode, if often not accepted by the system engineer/the satellite final client/the quality assurance department/... (sometimes its just not possible)
So what is usually done on satellite including both an IRU and a STT is to blend their data together. That gives you an accurate position (coming from the STT when it is ok, or by integrating the IRU data for "short" period when you get the sun in the field of view, for example), an estimation of the (current) gyro bias, and an accurate rotation rate (by using the IRU data minus the estimated bias)(this is usually based on a (extended) Kalman filter, but there are probably other methods)
With all this, you actually get a better attitude and rotation rate than IRU or STT alone. (when going in safe mode, you will probably switch to an attitude estimation based on IRU and some inaccurate but really simple sun sensor. Safe mode usually only wants to point some satellite axis to the sun with a bad accuracy, up to a few degree)
When everything works fine, it's nice.
But according to what they say, it seems that they have got an error in the algorithm (or some specific bug triggered by some strange sequence). There was the Earth in the field of view of the STT (so it was unavailable), then it has been to acquisition mode (no usable data), the tracking mode (data is good). At this point, there is a huge gap in the bias estimation (this kind of stuff happens when you re initiate a filter, or when conditions change), it's supposed to converge relatively fast to the good value (with "fast" being dependent on your algorithm). But during this convergence phase, they think that the STT did go back to acquisition mode. (for some reason, not completely clear). The estimated bias had a relatively high value (21 deg/h. Big for a bias), not corresponding to the real bias. But the satellite has keep using this value, until it finally reached safe mode.
It's not clear if it continued to use this bias value in safe mode, but it does not really matter (21 deg/h bias is not that big when you start using thrusters. It may use more fuel than needed but that's 0.3 deg/s. Relatively small). An error in other data uploaded in the software had basically transformed the safe mode to a kill mode (from what I understand, any transition to safe would have been extremely bad)
I'm don't completely agree with the fact that it's called a "software update". Reading different article about it, from what I understand, there was an initial error (software error probably triggered by an hardware error probably due to an upset due to radiation), but this error is not very important. A series of event from this error triggered the safe mode (that's expected), and there was the critical problem.
They had updated parameter in the software describing the torque generated by each thruster (or the center of mass position, or the tensor of inertia, or parameters based on all this) These parameter are software parameters, but updating them is not updating the software. It's software data, not software code.
Of course this does not change the fact that it is a critical error, but it's not exactly software update (IHMO). It's a configuration error. It's strange that they didn't see that in a simulator before updating them, but it's possible that they may have used the same value in the part simulating the software and the part simulating the thrusters themselves.
(note: I'm working in the satellite on-board software/attitude control domain, but not for JAXA, in Europe. Anyway at my current position, I must both test this kind of code, and the parameter used in the code. And checking the parameters is much more difficult, because you must be sure that everyone agree on everything. This includes a lot of basic stuff, but it's a pain in the ass ;-) )
This pdf from JAXA is probably the initial source of all articles. http://global.jaxa.jp/press/2016/04/files/20160428_hitomi.pd... I found it interesting to read, if you know how it works. I would of course prefer to have more detains. I always want more details. But it's for the press...
