[SOLVED] Argument disparity in function declaration in Fortran's ScaLAPACK

ejspeiro · 03-19-2013, 09:25 PM

Hi guys,

so, I want to call the following function from C:

http://www.netlib.org/scalapack/expl...8f_source.html

thus translating lines 156 to 159 of this file:

http://www.netlib.org/scalapack/expl...8f_source.html

BUT, since I am not good with Fortran, I have to ask: CAN YOU, IN FORTRAN, DECLARE ONE PARAMETER TO BE OF ONE TYPE WHEN DEFINING A FUNCTION, AND THEN CALL THE FUNCTION WITH A DIFFERENT TYPE?

Notice in the FIRST file, that the 26th parameter is an array of integer:

Code:

00001       SUBROUTINE PDGBINFO( SUMMRY, NOUT, TRANS, NMAT, NVAL, LDNVAL, NBW,
00002      $                     BWLVAL, BWUVAL, LDBWVAL, NNB, NBVAL, LDNBVAL,
00003      $                     NNR, NRVAL, LDNRVAL, NNBR, NBRVAL, LDNBRVAL,
00004      $                     NGRIDS, PVAL, LDPVAL, QVAL, LDQVAL, THRESH,
00005      $                     WORK, IAM, NPROCS )
...
00023 *     .. Array Arguments ..
00024       INTEGER            NBRVAL( LDNBRVAL ), NBVAL( LDNBVAL ),
00025      $                   NRVAL( LDNRVAL ), NVAL( LDNVAL ),
00026      $                   BWLVAL( LDBWVAL),BWUVAL( LDBWVAL),
00027      $                   PVAL( LDPVAL ), QVAL(LDQVAL), WORK( * )

BUT notice in the SECOND file, that the same function is being called using an array of DOUBLE PRECISION:

Code:

00001       PROGRAM PDGBDRIVER
...
00116 *     .. Local Arrays ..
...
00123       DOUBLE PRECISION   CTIME( 2 ), MEM( MEMSIZ ), WTIME( 2 )
...
00156       CALL PDGBINFO( OUTFILE, NOUT, TRANS, NMAT, NVAL, NTESTS, NBW,
00157      $               BWLVAL, BWUVAL, NTESTS, NNB, NBVAL, NTESTS, NNR,
00158      $               NRVAL, NTESTS, NNBR, NBRVAL, NTESTS, NGRIDS, PVAL,
00159      $               NTESTS, QVAL, NTESTS, THRESH, MEM, IAM, NPROCS )

DOES THIS MAKE SENSE?!? I am trying to translate this code to C, BUT this keeps the code from compiling properly, and furthermore, the driver from the SECOND file works 0k! It actually works great! It passes the numerical tests, and it scales in terms of execution times when increasing the number of processors.

My common sense is being tested here

Thanks!

ejspeiro · 03-19-2013, 09:50 PM

I checked this source:

http://orion.math.iastate.edu/burkar...an_arrays.html

They say that because of how is the WORK array declared in the subroutine, you pass the array, but avoid having to specify the size by using the "*".

Therefore, I am tempted to declare the routine in my C code, as receiving a double *, to please the C compiler.

Does this make any sense?

Thanks!

mabouali · 03-20-2013, 01:41 AM

FORTRAN Does the type casting, So I think thats what is happening and you don't get any error.

One more thing to remember is that in FORTRAN the memsize is always in terms of number of elements. while in C/C++ the memsize is provided in bytes. So in your C code while passing the memory size don't multiply by sizeof(whatever).

ejspeiro · 03-20-2013, 09:32 AM

Quote:

Originally Posted by mabouali

One more thing to remember is that in FORTRAN the memsize is always in terms of number of elements. while in C/C++ the memsize is provided in bytes. So in your C code while passing the memory size don't multiply by sizeof(whatever).

Wow Mo! I believe this statement right here is just as important as the "three well-known differences" between C and Fortran, that we all keep in mind when interacting between them:

Column- versus row-major arrays
Always passing by references versus MAYBE passing by reference
1-based indexing versus 0-based indexing

Which btw, as far as the last one goes, as I read more and more about Fortran, I'm discovering is not as important!

Dude thanks! I already know what to try for in my code! Come back home quickly!

\m/

mabouali · 03-20-2013, 12:50 PM

As you pointed out I think the first one is the most important, that is row/col major

On C you always loop like this
loop over I
loop over J
a[I][J] ...

while in FORTRAN you loop
loop over J
loop over I
a(I,J) ...

For array numbers it starts by default from 1. You can actually tell fortran what should be the range of arrays.
So if you do
REAL, dimension(10) :: A
the 'A' would be an array of 10 element and the first element would be A(1) (not zero).

However, if you define
REAL, dimension(0:9) :: A
the 'A' would be an array of 10 element and the first element would be A(0).

something that I like, particularly when we use dummy/ghost nodes in PDE you can define
REAL, dimension(-2:7) :: A
the 'A' would be an array of 10 element and the first element would be A(-2).
So pretty much I use the negative indices for ghost nodes.

Thursday I am driving back. 7 hours of drive

ejspeiro · 03-20-2013, 04:12 PM

It seems like it works!

I basically did this:

Code:

MEM = (double *) malloc(MEMSIZ);

without multiplying by sizeof(double)!

It works (for now!). I still have to complete the driver!

In the mean time, I am calling this one as solved! Thanks Mo!

\m/