One of the dastardly acts for a Professor is to teach in units of metres and then set the exam problems in mm.
Fryba in his publications on the RKN ODE Problem developed in the 1960s and early 1970s provides an excellent book, but he does not provide all of the numbers needed to replicate his results. He notes that the missing data is in a book published in the Czech language in 1964 as a technical report.
I can replicate his results basically and see the pattern in the plots that matches his patterns and I can explain where the pattern comes from in the output.
My results for the deflection in metric are one/thousandth of his -- he provides most of the data except the few critical bits that are needed to replicate his results. He provides some of the critical graphs but not all.
I have spent three days slowly working through the Fortran code looking for errors, it is never bug free but it appears to be reasonable as a starting point - I get the correct shape for the ODE results and the Poincaire plots look normal. I have plotted all of the data I can to compare to his graphs.
In his results he discusses the problems he had and now that I have the Fortran running I can understand exactly what he is talking about - why the heck cannot people not be like Conte and De Boore and publish the code. Plus he died 5 months ago and it was programmed on a URAL 2 computer in the late 1960s. You can read the modern papers and see others run into the issues of using the general differential equation - second order - then they revert to the non-general equation and replicate something akin to Fryba in Matlab, but ignore velocity. Like ACM Algorithm 670 - why not solve the general equation.
Excuse the rant -- but this runs in 12 seconds on a single core and gives 260000 time steps. By comparison in FEM that would take a supercomputer a week. I know I tried and got banned from the supercomputer at Newcastle.
Anyway I enclose the xls file with the graph showing the deflection -- and a zip file with Fryba's results. All we need is his code to see what I am doing wrong.
He spent at least a decade on this work and is interesting that it is so hard to reproduce.
This is the problem with large swaths of modern engineering - hard to replicate results
At least the Fortran Intel Compiler provides a good solution platform. Anyway so much for today.
Now to find the Czech book.
As bad as not knowing the specific units, I assume that whatever they are, that they are all metric as opposed to a mix of metric, Imperial and/or US units. Back in 2004 I was developing a simulator in C++ (this is before acquiring a superior simulator in Fortran). An issue I wanted to avoid was related to potential mismatch of not only units, but also to avoid occasional programming errors of maintaining dimensional consistencies. For example I wished to be informed at compile time that I misused a unit of length for a unit of area. Additionally, the operator functions would automatically handle any unit conversions. For example an expression could contain a mix of US and metric values on the rhs and store into US or metric on lhs with the appropriate conversions being made. And the compiler would complain if a type of area was being set to a value of length or velocity or anything other than a value or expression that produces an area (of any unit that can be converted to type of lhs).
Thanks for the note. Thankfully Fryba published all of his results in metric and so the program is all standard SI.
One learns that lesson early in engineering school.
I just have to work through the code and find the mistake(s). I was reading a paper last night on this stuff, the author was talking about run times in the late 1990s in the low seconds for the solution and with a CORE i5 I cannot get under 13 seconds and my computer is way faster than any 1998 machine.
They do not tell you the compiler or anything.