0

I have code written in old-style Fortran 95 for combustion modelling. One of the features of this problem is that one have to solve stiff ODE system for taking into account chemical reactions influence. For this purpouse I use Fortran SLATEC library, which is also quite old. The solving procedure is straight forward, one just need to call subroutine ddriv3 in every cell of computational domain, so that looks something like that:

do i = 1,Number_of_cells ! Number of cells is about 2000
call ddriv3(...)     ! All calls are independent on cell number i
end do

ddriv3 is quite complex and utilizes many other library functions.

Is there any way to get an advantage with CUDA Fortran, without searching some another library for this purpose? If I just run this as "parallel loop" is that will be efficient, or may be there is another way?

I'm sorry for such kind of question that immidiately arises the most obvious answer: "Why wouldn't you try and know it by yourself?", but i'm in a really straitened time conditions. I have no any experience in CUDA and I just want to choose the most right and easiest way to start.

Thanks in advance !

Yakovenko Ivan
  • 29
  • 9

1 Answers1

1

You won't be able to use or parallelize the ddriv3 call without some effort. Your usage of the phrase "parallel loop" suggests to me you may be thinking of using OpenACC directives with Fortran, as opposed to CUDA Fortran, but the general answer isn't any different in either case.

The ddriv3 call, being part of a Fortran library (which is presumably compiled for x86 usage) cannot be directly used in either CUDA Fortran (i.e. using CUDA GPU kernels within Fortran) or in OpenACC Fortran, for essentially the same reason: The library code is x86 code and cannot be used on the GPU.

Since presumably you may have access to the source implementation of ddriv3, you might be able to extract the source code, and work on creating a CUDA version of it (or a version that OpenACC won't choke on), but if it uses many other library routines, it may mean that you have to create CUDA (or direct Fortran source, for OpenACC) versions of each of those library calls as well. If you have no experience with CUDA, this might not be what you want to do (I don't know.) If you go down this path, it would certainly imply learning more about CUDA, or at least converting the library calls to direct Fortran source (for an OpenACC version).

For the above reasons, it might make sense to investigate whether a GPU library replacement (or something similar) might exist for the ddriv3 call (but you specifically excluded that option in your question.) There are certainly GPU libraries that can assist in solving ODE's.

Robert Crovella
  • 143,785
  • 11
  • 213
  • 257
  • Thank you very much for your answer ! As I understood, the pre-compilation of the library is the problem. Actually my Fortran project consists of my *.F90 files and souce code of SLATEC library (also *.F90, autonomous) and when I'm compiling my project, the source code of SLATEC is compiled as well, just as a bunch of supplementary subroutines. I'm sorry if I've used term "library" wrong, and if it changes the situation. – Yakovenko Ivan Aug 02 '13 at 16:57
  • Then your case is covered in my 3rd paragraph. As long as none of the supplementary subroutines make reference to any host library, it might be worth a try to see what happens with OpenACC (although I'm not terribly optimistic about the outcome). With CUDA Fortran, you are still faced with the task of converting all the subroutine code to CUDA parallelized code (i.e. it's not as simple as "parallel loop" in OpenACC). In either case, it's likely that some non-trivial effort is involved, i.e. something beyond a simple annotation of your code with a few directives. – Robert Crovella Aug 02 '13 at 17:02