jasonlarkin / p3dfft

Automatically exported from code.google.com/p/p3dfft
GNU General Public License v3.0
0 stars 0 forks source link

Fortran kind definition #25

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
A user reports:

The definition of the kind parameter mytype for the real precision might
be problematic. Now, I  might be wrong in my understanding of the
Fortran standard, but as far as I understand it, the actual kind
parameters, like 4 and 8 in P3DFFT, are *not* the number of bytes used
to represent that floating point type. They are merely tags and are as
thus not defined in the standard at all. E.g. the function
selected_real_kind(0d0) does not at all have to return 8, it could
return something completely different which that particular compiler
vendor has chosen. So hardcoding kind parameters such as 4 and 8,
although most vendors happen to use these to denote single and double
precision floating types, is not necessarily portable and safe. If it
works, then only because most vendors have chosen (for now) to use 4 and
8 as the parameters.

In our code I have a module which defines the corresponding types based
on the desired precision and those definitions are then used throughout
the code. If you want to, I could send it the module to you. There's
various similar pieces of code on the web, also on comp.lang.fortran.

To make things even more complicated, no matter if you defined the kind
parameters based on the desired precision or by hardcoding e.g. 4 and 8,
there is no guarantee that the type which you get has a given number of
bytes.  So when MPI is used the length of the corresponding  data type
isn't known. That's what the mpi_type_create_f90_* routines in the MPI-2
standard are for. Given a fortran real type, they return a MPI float
data type that can accomodate this fortran datatype. In principle, using
these routines and the types returned by them is the most portable way
of using/ switching between single and double precision. However, not
all MPI libraries have these routines readily implemented. E.g. SGI's
MPT lib will only have them in the next release. The next version of the
MPI standard will presumably have a more elegant way to map fortran kind
parameters to MPI datatypes anyway.

---

Anybody wants to take this on?

Original issue reported on code.google.com by dmitry...@gmail.com on 17 Apr 2010 at 2:04

GoogleCodeExporter commented 9 years ago
Currently working on this.

Original comment by d4p...@ucsd.edu on 6 May 2010 at 8:44

GoogleCodeExporter commented 9 years ago

Original comment by dmitry...@gmail.com on 21 Jun 2010 at 9:52

GoogleCodeExporter commented 9 years ago
Committed a small start to changing kind definitions. Had gone through and 
changed everything on the first try but tests were broken. Started over and 
have decided to commit step-by step after testing the changes instead.

Original comment by d4p...@ucsd.edu on 5 Jul 2010 at 12:26

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
Went through the build directory and changed all individual kind definitions to 
use global constants defined by SELECTED_INT_KIND and SELECTED_REAL_KIND; will 
replace these functions later with equivalent functions from MPI (only four 
lines will need to be changed for this). the changes have been tested by 
running all Fortran drivers and seem to be working properly.

will standardize kind definitions in the Fortran test drivers next.

Original comment by d4p...@ucsd.edu on 6 Jul 2010 at 5:15

GoogleCodeExporter commented 9 years ago
Fortran kind definitions in Fortran test drivers have been changed and tested.

Original comment by masta.p...@gmail.com on 6 Jul 2010 at 5:36

GoogleCodeExporter commented 9 years ago

Original comment by dmitry...@gmail.com on 4 Aug 2010 at 10:34