Running a multidimensional problem on a single core

Click For Summary

Discussion Overview

The discussion revolves around a Fortran program designed to solve a six-dimensional partial differential equation (PDE), focusing on performance issues encountered when increasing the number of velocity variables from 80 to 288. Participants explore potential reasons for the unexpected increase in runtime when scaling the problem, considering aspects of memory usage and computational operations.

Discussion Character

  • Technical explanation
  • Debate/contested
  • Exploratory

Main Points Raised

  • One participant describes their Fortran program's performance with 80 velocity variables and notes a significant slowdown when increasing to 288 variables, despite expectations of a proportional increase in runtime.
  • Another participant speculates that the program or a library function may require additional intermediate storage or may be encountering integer overflow issues.
  • A participant mentions that their code has been mostly self-written, with only one external subroutine, and expresses suspicion about other potential issues affecting performance.
  • There is a discussion about the types of operations being performed on the data, with one participant highlighting that modern Fortran handles array operations differently than older versions, which could impact performance.
  • A participant clarifies that they are using Fortran77 and only the FFTW library, asserting that they are not performing matrix operations but rather working with arrays and loops.
  • Ultimately, one participant discovers a bug related to fixed memory allocation for arrays, which they believe is the source of the problem.

Areas of Agreement / Disagreement

Participants do not reach a consensus on the cause of the performance issue until one identifies a bug in their code. Prior to this, multiple competing hypotheses about potential causes are discussed without resolution.

Contextual Notes

Participants express uncertainty about the impact of the operating system on memory usage and performance, as well as the implications of using different versions of Fortran on computational efficiency.

Telemachus
Messages
820
Reaction score
30
Hi. I have written a Fortran program to solve a pde, which has six dimensions. One of these dimensions is time, 3 are for space, and the other are related to velocities.

The program works fine when I run it with ##38^3## points in space (one for each space dimension), and 80 other dimensions related to the velocities. However, I have tried to increase the number of velocity variables from 80 to 288, for which I would expect the program to run roughly 3 to 4 times the time it took with 80 variables.

The total number of unknowns is, in the first case: ##38^3\times 80 \times n_{time steps}##. In the second situation is ##38^3\times 288 \times n_{time steps}##. For the first run, it took exactly 494 seconds to solve it. However, when I run the second situation, it has been going on for hours, and it haven't finished, so I just quit the run, because I am suspecting that there is something going on. The number of time steps in both situations is 200, but I'm not storing the solutions in time, I don't think that matters.

However, I have enough ram for it, 16gb. It would require ##38^3\times 80 \times 8 bytes## of memory (I am working with double precision real numbers). This gives only 35.12 megabytes of memory required. And 126.43 megabytes for the 288 velocities. I don't see where the problem is. Is there something I am missing or this should be working? If it took 494 seconds in the first case, being the second problem less than 4 times bigger, I would expect this to be solved in roughly 2000 seconds, but it has been like an hour running without finishing.
 
Technology news on Phys.org
You don't give us much to go on. Here are two speculations.

  1. Either your program or some library function that you use, needs intermediate storage or a second copy of the arrays to work with.
  2. Integer overflow in your code or in a library function.
 
  • Like
Likes   Reactions: Telemachus
Hi. Almost all the code have been written by me, I am only using one subroutine which isn't mine, but didn't have any issue previously. The code works fine with smaller problems, the running time scales as expected until that point. I will try to let it running for more time, but I am suspecting that there is something else. I think I have the same issue if I increase the spatial coordinates, but I haven't tried because it goes like a power of three, so I will run into trouble faster.

I don't think I have any integer overflow neither. Is there any other possibility? I mean, clearly I have more than enough ram memory. But is there any other internal memory in the cpu that could be going out of range at some critical point or this should work for arbitrary large problems while I have enough ram to store it?
 
What kinds operations are you (or FORTRAN) doing on that matrix? Inversion? Factorization? anything?

Modern FORTRAN does operations on whole arrays or matrices.
That generates invisible calls to library functions.

Old FORTRAN makes you do everything one element at a time.

Edit: Of course yes the operating system needs memory too. You haven't told us what the OS is.
 
  • Like
Likes   Reactions: Telemachus
I am using Fortran77. The only library I am using is FFTW, but the way I am calling it really shouldn't make any difference when I use 80 or 288 velocities (all go on independently). I am not using any matrix operations, I work with the arrays and many do loops.
 
I have just found a bug in the code, I had fixed the memory for a set of a arrays to the situation where I had the 80 velocities. I think that's it. I'll fix it. Thanks.
 
  • Like
Likes   Reactions: anorlunda

Similar threads

  • · Replies 17 ·
Replies
17
Views
4K
  • · Replies 6 ·
Replies
6
Views
3K
Replies
1
Views
2K
  • · Replies 0 ·
Replies
0
Views
2K
  • · Replies 2 ·
Replies
2
Views
3K
  • · Replies 3 ·
Replies
3
Views
4K
  • · Replies 2 ·
Replies
2
Views
2K
  • · Replies 13 ·
Replies
13
Views
3K
  • · Replies 1 ·
Replies
1
Views
2K
  • · Replies 4 ·
Replies
4
Views
4K