First gig was summer after my freshman year working for a EE professor who was researching why the Bonneville Power Administration power distribution network would oscillate in frequency and eventually trip one or more breakers systemwide. This involved producing a state vector of 500 elements and evaluating the eigenvalues and eigenvectors of a 500x500 matrix on a CDC 3500 computer with approximately 35k of memory. To invert the matrix, he would need to read in a handful of rows and calculate the inverse of the matrix incrementally. No small feat.
My contribution to this effort was to read in values for the C matrix and produce it in the format that the rest of the program required. One summer's work.
I met with him a few years ago and he showed me the current version of the program--not much had changed in 40 years, to my astonishment. Also he noted that this whole system was used to decide where to locate Fermilab.
Turns out that the result of the computation showed where the poles and zeroes were for the system. If too close to the y-axis, the system could slip into being an oscilator. Too far to the left, and there was too much damping.
This was my first astonished exposure to the idea that we could build something and not know how it was going to operate. "That thing I built does what!?"
This involved producing a state vector of 500 elements and evaluating the eigenvalues and eigenvectors of a 500x500 matrix on a CDC 3500 computer with approximately 35k of memory. To invert the matrix, he would need to read in a handful of rows and calculate the inverse of the matrix incrementally. No small feat.
Interestingly (at least to me), I can't help but put this into context by reflecting on the other pieces of software I'm familiar with that were developed in this era. In fact, the main one I do know does essentially the same maths operations as yours, and is also still used today. It's a little bit of code that basically underpins modern mechanical engineering and its name is derived from NASa STRuctural ANalysis.
I wonder if / by how long you beat them at developing what is fundamentally an FEA engine with modal analysis capabilities? :)
So it isn't immediately clear to me how these two overlap. Probably at the core there are some similar mathematical operations, but my professor's program's thrust was on control system stability analysis, and NASTRAN seems like a pretty sophisticated FEA wrapped in a lot of useful modeling and presentation code.
The huge challenge for this was matrix operations on a machine that was way too small for the task, where intermediate results need to be written to tape. And it appears, at least in current versions, NASTRAN is significantly larger, and handles a broad range of engineering problems.
This software was closer to LINPACK and EISPACK, which it predated.
FEA, at its base, is solving for [x] in [F] = [k][x] where F is your input forces on a structure, k is the stiffness matrix and x is the resultant displacement, which when combined with material properties produces a strain matrix and therefore body stresses of the structure. It basically has to invert a many-dimensional matrix to do that, which is where most of the 'core' computations of a linear-static FEA solution sit. Of course, desire for more detailed simulation has always exceeded computational capacity, so slicing up the matrix operation and writing it to permanent storage (tape, disk, etc.) is a routine operation for all solvers like this.
Expanding on from that, working out eigenvalues and eigenvectors for a matrix allows you to solve for harmonics, as you're well aware. Harmonics in a structural context are used to identify modal vibrations (e.g.: at what resonant frequency a drum skin vibrates for a given surface area, material and tension). It's essentially analogous to solving harmonics in electrical systems, like how a mass-spring-damper system is analogous to an RLC circuit.
NASTRAN is the granddaddy of FEA packages and was produced for NASA (hence its name) way back in the early days of computational simulation for their space programme. Well before the days of desktop workstations, companies (including the one I work for) would bundle up their model, ship it off to a company that had spare mainframe capacity and a solver licence, have them run it during their downtime and then receive their results back some time later.
Basically, as a kid of the 80s all of this sits in 'computing prehistory' for me so it was a fascinating (to me) exercise to place your work in the context of big software packages with which I'm familiar from a similar era. My last comment about beating NASA at writing a numerical solver for matrix inversion was just a bit of a silly joke, but it's similarly cool to realise that it's in fact true for other big numerical packages like LINPACK! :)
Upon reflection, I don’t think I addressed your question well.
I don’t have any reference to the decision about Fermilab as it was a verbal discussion. He mentioned that Scoop Jackson, often called the senator from Boeing, was angling to have it located in Washington. My professors friends at Bonneville called him in a bit of a panic to say that the power grid would not be able to handle the load. So he ran a simulation, knowing that power grid rather well, and demonstrated that the lights across the Pacific Northwest would dim every four seconds. Same simulation for Illinois showed no flicker.
My contribution to this effort was to read in values for the C matrix and produce it in the format that the rest of the program required. One summer's work.
I met with him a few years ago and he showed me the current version of the program--not much had changed in 40 years, to my astonishment. Also he noted that this whole system was used to decide where to locate Fermilab.
Turns out that the result of the computation showed where the poles and zeroes were for the system. If too close to the y-axis, the system could slip into being an oscilator. Too far to the left, and there was too much damping.
This was my first astonished exposure to the idea that we could build something and not know how it was going to operate. "That thing I built does what!?"