Ivpag

[mecej4]

Which memory are you talking about? The memory allocated for EMIN will stay as such until you deallocate it.

As I suggested, you should use some other integrator than DIVPAG -- not because it is not up to the task, but because using it for a non-stiff problem is overkill and causes slower computing.

If the integrator (DIVPAG or an equivalent) allocates some memory that is saved, you should read the documentation for that information and take the prescribed steps to free that memory, if necessary.

You should really read the IMSL documentation and a good Fortran manual in order to work on a project of such complexity.

[mecej4]

I tried using other solver DIVPRK, it does not help. It is 10-20 times slower than DIVPAG
So does this suggest problem is stiff?
So I have to reply on DIVPAG solver?

No. The lesson is that you should fix the bugs in subroutines F1 and JAC1 before attempting to draw any conclusions regarding performance.

also you said COMMON statements make complex code difficult to optimize. Does it slow down the code as well?

Well, failing to optimize should be expected to produce code that takes longer to run. Furthermore, if variables located far apart in a huge COMMON block larger than the cache are accessed, a further slowdown can occur.

[mecej4]

First, some basic points (correct me if I have some wrong): you have a linear, slightly damped second order system subject to sinusoidal excitation. The mass matrix is not singular. For such a system, the expected response is decaying oscillations, with fundamental frequency fairly close to the excitation frequency. There is no reason to expect stiffness in the ODE.

Consequently, any problems with an integrator, especially reports about stiffness in the ODE, raise the suspicion that your code has bugs in it or that you are not calling the ODE solver correctly.

If you post your cleaned up code in a zipped-up attachment, I will look at it. Keep in mind, however, that you bear most of the burden of ensuring that your code represents the mathematical problem correctly. If you cannot do so, and as I have said before, it is pointless to complain about the behavior of an integration routine.

[mecej4]

Prashant:

Hi, either you forgot to attach the zip-file, or my browser and the new Roguewave forum setting are conspiring to make it invisible. Please check.

Also, please state which Fortran compiler and which version of IMSL you use.

[mecej4]

I have the files now.

These bugs are still present:

BETAR is used before set in Subroutine f1. The arrays MbeamT, MbeamR, Mbeamtheata, KbeamT, KbeamTheata, KbeamZ, Gbeam have only some values set in Subroutine Beammat. The other elements are undefined. Some lines are longer than 72 characters and may suffer truncation.

Because of these bugs, the ODE integrator can give you false reports of stiffness.

The matrices Em, Emin and EK are computed thousands of times even though once would suffice. Since Emin is computed by inverting Em, a 324 X 324 matrix, a calculation that should take less than 10 seconds will now take many minutes, even after the bugs listed above have been fixed.

[mecej4]

No here is thing

Now EMin is computed only once in routine f1 and jac1 I am using allocatable save array as you suggested last time
double precision, allocatable, save :: EMin(:,
...
LOGICAL,SAVE :: INITIAL = .true.
..
IF (INITIAL) THEN
--- compute inverse or L-U factors of mass matrix into array EMIN ---
INITIAL=.false.
ENDIF

Okay, I see this part now. However, you are still recomputing EK every time. Secondly, Jac is irrelevant since it is no longer used if you use IVMRK

also regarding BETAR as I told you I removed some stuff from routine to remove some part of my code , in that section BETAR is defined

I can only comment on the code that you supplied.

regarding MbeamT, MbeamR........, as those arrays are static arrays. once I define them they begin with zero values and then I populate only part of those arrays.

They are local arrays, and are not static.

About lines which are greater than 72 only comments exceed beyond 72 words.

No, there are executable statements that exceed line length, as I pointed out.

[mecej4]

Hello
I have not heard back from you? Do you also think problem is stiff and need stiff solver?

No. It is probably not stiff, or only mildly stiff. But don't take my word for it. Investigate the stiffness yourself.

What is your recommendations?

Nothing beyond what I have already recommended in the earlier posts in this thread.
[QUOTE]