Large wall time, small CPU_TIME, what does that tell you?

[CRquantum]

@RonShepard

This is the code I used in my previous post. I explained why it failed and two ways to fix it (one suggested by you earlier), and I posted timing results with the fixed version.

Thanks! I see. This issue may be remotely kind of related with the following two posts:

Integer 4 or integer 8?

In the original version of OP there was an array AAA(np,nd). I guess that internally, the processor should deal properly even with AAA(100000,100000) although the indices would overflow when simply multiplied. In explicit calculations, however, one has to make sure there is no overflow and use proper kind(s). Note also, that with your declarations: integer(kind=i4) :: np,nd integer(kind=i8) :: jjj jjj = np*nd jjj will not be properly assigned if np*nd overflows in i4 kind. Consider sample pro…

LightKrylov (v0.1.0-beta) : Pre-release

If you use EXPOKIT, note that there are some small bugs in some of its code which can cause integer overflow and lead to wrong results. For example, in dgpadm.f, around line 87 [image] Originally it is scale = t / DBLE(2**ns) that 2**ns will cause integer overflow if ns>30 if the default integer type is integer 4, then the DBLE(2**ns) will be something like NAN. You need to change DBLE(2**ns) to something like 2.0d0**ns Without this fix, every time if ns>30, dgpadm will just output wron…