I am slowly finding from experimentation and from reading the literature that there is a solid reason why people do not use Runge Kutta Nystrom methods to solve the second order general differential equation. The complaint is the in-stable behaviour of the higher factors. Although Poincaire plots show nice stability once you get into the right step range. most of the published solutions start by referencing the Fryba full solution and then immediately say drop the velocity component -- even recent papers
Lear published the coefficients for a 4 stage RKN for the general solution in 1976. Jacob from TRW (TRW == NASA Contractor) published the simple algorithm for the 4 stage RKN. I have now essentially got it running -- I am slowly going through finding all the interesting issues and sorting Fryba's equations - he does not define everything.
The latest issue is STACK OVERFLOW Error -- I found the heaps array fix, but this does not work as the array size increases
RKN has a very limited stable region, if the time step is to long > 0.000005 -- the acceleration results disappear to infinity within about 5 time steps. Interestingly Fryba said on a Ural 2 Computer he has it working with a time step of 0.001 -- I cannot get to that limit without interfering with the acceleration increase rate -- not really acceptable
So for a 25 m/s truck speed over a 16 metre bridge - I need something in excess of 200000 array sizes, they work at this size, but if I move to half the time step I need 400000 and this crashes with stack overflow.
Any ideas on the stack overflow?
The issue of time step selection has some fascinating problems at the start of the analysis -- using the step and two half steps method to check for acceptable answers works nicely except for the first 30 time steps -- here the full steps moves through a slow convergence to the half steps over 30 steps. It cannot be fitted to a standard regression method.
Once it is stable the full step is within 0.22% of the half step except with the Y solution crosses zero and I get a weird shape in the ratio of the full step to half step step results ratio -- see attached - anyone seen this type of signal before. -- it is not a real problem just interesting
There is a simple way to solve the array size use a step size of h for the overall problem and do a simple 2, 5, 25 or 50 part time step for each main step - but I would like to avoid this if I can
Thank heavens for Fortran this would be impossibly hard on most other languages.
Enabling heap arrays helps. You can also increase the stack size by setting the property Linker > System > Stack Reserve Size. I suggest starting with 100000000 and increasing by 1000000 each time until it works. Don't go too high with this as it can prevent the program from running at all.
From the command line, add "/link /stack:100000000" at the end of the ifort line that invokes the linker.
When the stack overflow is not due to excessive recursive procedures, then the cause is usually attributable to having an actual argument to a subroutine/function as a dis-contiguous array slice or array expression. In these cases you can potentially manually store the slice/expression into a working array, which is potentially SAVE provided this isn't a recursive/reentrant procedure and then use that temporary as the actual argument. While this could be a stack/heap array, you may find it beneficial to keep the array around.
Side note on stack based arrays: Should your program be multi-threaded (e.g. OpenMP), and should the stack temporary be created by only the main thread (possibly used later in a parallel region), then the stack reserve size applies to all threads. This may not be suitable for your system.
There is only a single thread, this is a simple loop program for an ODE. The arrays are declared as allocatable, but I did not understand the features of RKN when I set up the Fortran. Once I get it working properly I will go back and fix the step size selection routine and reduce the size of the arrays.
Steve's suggestion worked a treat. I had set the stack size but it was 10 times to small.