I used the same integrator that we had setup for use with the stationary solver. I had expected it to either fail or return a very different result, but assumed that the fact that it was returning the same result as when it was used after the previous solvers indicated that it was able to use that solver to find the value. After seeing this comment I went back and checked and the solver was setup to use the last stationary solution regardless which solver last ran. I will run the previous tests which relied on using this integrator in conjunction with nonstationary solvers again and see if they actually agree and how the results they give compare to the analytic solution. I will spend some time today trying this. Unfortunately, both the time dependent and frequency domain solvers take a long time to converge, so running these tests may take most of the day, but I can start reading through some of the Livelink for Matlab documentation while they run.
edit:
I ran the timedependent solver for the rigid back boundary condition and computed the strain energy for the final two timesteps. Both of them gave a value of 1.58425*10^10 J which corresponds to Sx(100 Hz)=2.08871*10^40 which is about 3.6% greater than the value obtained from the stationary solver. I don't understand why these values would differ at all. When I tried to run the time dependent solver with the spring back and gravitationally opposing force boundary conditions an error message was returned: "Failed to find consistent initial values., Last step is not converged.; Feature: TimeDependent Solver 1 (sol4/t1).; Error: Failed to find consistent initial values."
I'm going to spend some more time looking at the COMSOL model attempting to find anything which could be causing this error and reading any relevant documentation I can find.
edit 2:
I spent most of the day attempting to find the source of either of these errors. Possible solutions I found and tried included increasing or decreasing how fine the mesh is, increasing the acceptable tolerances, and increasing the time interval in the time dependent solver. I attempted all of these and none of them worked. Surprisingly, when I increased the acceptable tolerance level for the stationary solver, it returned a greater relative residual which does not make sense to me.
I also took the simple 3d cylinder constructed yesterday and was able to replicate the errors with it. When I increased the time interval on that case for the time dependent solver, it converged and gave a result. I was able to get a Umax value for the final time step, which should be equivalent to the one which we would expect a stationary solver to return. Further increasing the number of time steps the primary model computed did not cause it to converge. I will run this again with many more time steps and see if it converges. Even if it does, this doesn't seem like a good way to do our computations as it takes a long time to complete a solution, but seeing whether it converges may give us information on what the problem with the stationary solution is, in particular if increasing the number of time steps does cause it to converge, then that would indicate that finding a way to make the simple case converge would probably work for our model as well.
Quote: 
Emory:
I don't understand how you're getting the strain energy from the eigenvalue solver. It is my understanding that the eigenvalue solver will only give you the strain energy at a particular eigenfrequency. We're interested in the strain energy from the beam deformation at frequencies below the first eigenmode.
Quote: 
We have been encountering an error in COMSOL for a while of the form "Failed to find a solution.; The relative residual (###) is greater than the relative tolerance.; Returned solution is not converged.; Feature: Stationary Solver 1 (sol1/s1); Error: Failed to find a solution." The error has occurred when attempting to find a stationary solution in models with boundary loads and no fixed constraints (preventing an edge from moving). We wanted to determine what the error was caused by to allow us to use the stationary solver, or at least to confirm that the error was not indicative of a problem in our model. To this end, I designed a few very simple COMSOL models in which I was able to reproduce the behaviour and attempted to determine the root of the issue.
I first constructed a somewhat similar model to ours using a cylinder of fused silica with all of the default values and a normal meshing. I applied a boundary load of 1N on one of the faces and ran a stationary solver. As expected, the solver failed to converge since it had no boundary condition preventing it from accelerating continuously. Applying a force of 1N on the opposing face resulted in the same error as above, which replicates the previous error since the system is failing to converge in a case where it should. I decided also to make an even simpler 2D model of a square. Applying 1N forces to opposing sides on the square again returned the error above.
Both of these models were able to be evaluated using at least an eigenfrequency solver as noted on the primary model in the previous eLog. I looked on the COMSOL forums and read through some more of their documentation and saw the suggestion in response to this error to use a timedependent solver and simply view times after the system will have settled to a stationary state (#2 https://community.cmc.ca/docs/DOC1453). I attempted this on the test models and both of the time dependent solutions converged without error to their expected solutions (compression between the faces on which forces were being applied). This may be a suboptimal computational method though as even in the simple cylinder case with 6133 elements and a simple force profile, the solution took several minutes to run. For the cylindrical model, I evaluated the strain energy using both an eigenfrequency and time dependent solver and obtained the same result using both of the solvers. The eigenfrequency solver evaluates much more quickly than the time dependent solver, and in the primary model as I noted in my previous eLog, the strain energy obtained using the eigenfrequency and frequency domain solvers agreed, so it seems that the best manner in which to proceed is to use the eigenfrequency solver to compute the strain energy.
The source of the error is still unknown, but given these tests, it seems very unlikely to be indicative of a problem in our model. We still have a very significant disagreement between the simulated results and the calculated values. I am going to spend the next day or so looking through both the COMSOL model and the analytic calculation and checking them for errors which could cause this discrepancy. I will then start reading the documentation on Livelink for Matlab and try to implement it.


