Fortran 2003 and 2008 features

Paul, When playing with Warwick University 3D PIC code written in Fortran 2003 i found that it is so incredibly fast that actually works even on a single core and runs in less than 1 minute many test examples. It also probably will run on a cell phone or even calculator if it has good amount of memory. With other PIC codes i sometimes run for a month on a supercomputer 😃)

At the same time it is so advanced in using all these new Fortran features and also is written so pedantically (sometimes you feel that this is not a Fortran but some kind of perversion, a crazy puzzle, a dialect of Maya language. It took me 3 months to crack this nut, and i still not fully understand few things) that if you need to check compatibility of your added 2003-2008 features to FTN95 then i suggest using this code as a bench. You can just omit MPI parallelization, which can be added later.

P.S. Use tar.gz not zip archive version from their GitHub, zipped one misses stuff (as they mentioned themselves. Not sure why they do that as if there are problems with the download file sizes nowadays. May be also zip hiccups somewhere). Also observing 50 times faster compilation speed (i compile it for 6 minutes on Linux supercomputer) will make you happy every day 😃

Dan

What does it use from Fortran 2003 that is not available with FTN95?

If FTN95 worked on Linux and supported its Make utility for compilation answering this question would take 5 seconds. So far i have not succeeded to compile this large Fortran 2003 code with FTN95 on Windows...

Surely there are other 'makes' around.

I tried few times but never succeeded to adopt Make to use with FTN95. It is probably possible and doable but not a piece of cake. No one also was able to help me here when i asked questions about using Make. There also are differences between Linux and Windows Make utilities besides the fact that their languages substantially differ from command prompt commands we typically somewhat familiar with. And if Make for FTN95 is also a bit different from other compilers - you will not touch Make with FTN95!

As a result i usually failed with Make and end up with file by file batch compilation. When there are few files it's ok, but when there are 100s interdependable files with their modules using other modules you end up with the hell. While all other Fortran compilers have zero worries about that.

I'd be glad to see FTN95 joined all other a half a dozen (essentially all currently available on the market) Fortran compilers to use Make they seems all use with no problems, you just change one single keyword in Makefile file like Intel to PGI or to gfortran or to g95 or IBM or even the ones i never heard about Archer or Hector and all just works. No any hell with module dependencies, and when you edit only one source file - only one file is recompiled.

Since we are approaching broad adoption of multiprocessor calculations by masses, adding OpenMP support, synchronize FTN95 with other compilers in most of their options (including Make, ensuring better compatibility of binary read/write file formats, may be also improving compatibility of LIB files with at least Intel Fortran) and ideally supporting also Linux, would be beneficial for FTN95. Windows and Unix were completely abandoned by supercomputers lately, there only Linux rules now.

Simon

The character handling features that you mention above have now been added for the next release of FTN95.

Paul, Have anyone asked to add Fortran 2008 feature NORM2 ? It's kind of unusual that it is not even in the Fortran90/95, because it is useful function and would be not hard to implement.

Besides, this code demonstrating NORM2 and some other tricks surprisingly runs on other compilers (look at the syntax of defining X)

PROGRAM test_sum
  REAL :: x(5) = [ real :: 1, 2, 3, 4, 5 ]
  print *, NORM2(x)  ! = sqrt(1**2 + 2**2 + 3**2 + 4**2 + 5.**2) = sqrt(55.) ~ 7.416
END PROGRAM

I saw already two large Fortran codes where authors started actively adopt F2003 and F2008 features. Here is another one which FTN95 can not compile https://gitlab.com/MD-CWI-NL/afivo-pic

Dan

I will add NORM2 to the list of missing features from the 2008 standard.

Regarding afivo-pic, please provide a short working program that illustrates the what is missing from FTN95.

I am not familiar with the history of NORM2, but I do use a similar RMS function, which I thought was more often used ?

If adding NORM2 to FTN95, then perhaps also consider HYPOT?

hypot(x,y) = sqrt(xx + yy) = abs(complex(x,y))

I have added HYPOT to the list.

Quoted from PaulLaidler Regarding afivo-pic, please provide a short working program that illustrates the what is missing from FTN95.

Paul, OK, here is an example of module m_af_types which has no other modules to USE but it has #include 'cpp_macros.h'. I further simplified both by shortening of them and removing mentioning GFortran there

m_af_types.f90:

#include 'cpp_macros.h'
module m_af_types

  use iso_c_binding, only: c_ptr
  implicit none
  public
  integer, parameter :: dp = kind(0.0d0)

end module m_af_types

cpp_macros.h:

!#ifdef __GFORTRAN__
!#define PASTE(a) a
!#define CONCAT(a,b) PASTE(a)b
!#else
#define PASTE(a) a ## b
#define CONCAT(a,b) PASTE(a,b)
!#endif

#if NDIM == 1
#define DTIMES(TXT) TXT
#define DINDEX(TXT) TXT(1)
#define DSLICE(lo,hi) lo(1):hi(1)
#define KJI_DO(lo,hi) i = lo, hi
#define CLOSE_DO
#define IJK i
#define IJK_(s) CONCAT(i_,s)
#define DIMNAME '1d'
#elif NDIM == 2
#define DTIMES(TXT) TXT, TXT
#define DINDEX(TXT) TXT(1), TXT(2)
#define DSLICE(lo,hi) lo(1):hi(1), lo(2):hi(2)
#define KJI_DO(lo,hi) j = lo, hi; do i = lo, hi
#define CLOSE_DO end do
#define IJK i, j
#define IJK_(s) CONCAT(i_,s), CONCAT(j_,s)
#define DIMNAME '2d'
#elif NDIM == 3
#define DTIMES(TXT) TXT, TXT, TXT
#define DINDEX(TXT) TXT(1), TXT(2), TXT(3)
#define DSLICE(lo,hi) lo(1):hi(1), lo(2):hi(2), lo(3):hi(3)
#define KJI_DO(lo,hi) k = lo, hi; do j = lo, hi; do i = lo, hi
#define CLOSE_DO end do; end do
#define IJK i, j, k
#define IJK_(s) CONCAT(i_,s), CONCAT(j_,s), CONCAT(k_,s)
#define DIMNAME '3d'
#endif

The compilation (i gather result of compilation in the file Z ):

 FTN95 m_af_types.f90 /CFPP NDIM 2 >Z 

The file Z:

*** More than one source file specified with names m_af_types.f90 and NDIM

    1 ERROR [m_af_types.f90] - Compilation failed.

Additionally this piece also looks very unusual

#define PASTE(a) a ## b

Dan

Some of the #define's illustrated here are not currently supported by FTN95.

Preprocessing instructions, such as these that are common to the language C, are not Fortran standard conforming.

Our first priority is to add useful features from the 200x Fortran standards that are not currently supported.

Dan, if he bothered to perform the RTFM ritual at least once a year, would have typed the compilation command as

FTN95 m_af_types.f90 /CFPP /DEFINE NDIM 2 >Z 

That aside, note that none of the macros defined in the included file is invoked in the .f90 source file that includes the .h file, so we have nothing to give us a hint as to how those macros are supposed to function. Depending on how a compiler is implemented, the syntax of macros that are not invoked may be subjected to no checking at all.

Mecej4 Adding content to the file still gives the error *** Unexpected character found after #define

Dan, I already noted that FTN95 is attempting to parse #define lines that are not needed in the Fortran file that includes the .h file, even when the macro being parsed is not invoked. Paul has pointed out that FTN95's preprocessing repertoire is not the same as that of typical C compilers.

FTN95 is in many ways not suitable as a replacement for GNU compilers when you are building a large Linux/Unix codebase on Windows. Its command line capabilities are not as extensive as those of other compilers -- you cannot issue a command similar to

gfortran a.f90 b.f90 -Lmydir -llib1 -llib2 -o myprog

Partly as a result of this difference, you cannot use makefiles from elsewhere (such as Linux) without making substantial adaptations.

It is one story when one compiler can do some things while the other can do the other things first one can't. Its up to developers to chose at what degree to support C-style or graphics integration or NET or Wininet etcetcetc in their compiler. Some compilers even can do some things absolutely no any other compilers do.

But it is different story when all 5 or 6 other existing Fortran compilers can do some things practically forming the de-facto standard even it is not in the written Fortran Standard while your own compiler is the only which can't do them. Specifically if the trends are pointing into specific directions like better C/C++ integration or multiprocessing, then for the lagging compiler there simply is no other way but to catch and start to support things where others already aligned. Not catching the cohort will marginalize the users base.

As to MAKE utility I have two Linux large codes and one for Windows which use MAKE for compilation. Make typically support whole bunch of compilers. The only compiler which did not work in all cases with MAKE was FTN95. Anyone wants to try? That are not my own codes

NORM2 and the 'cast' to REAL in an array constructor have now been implemented for the next release of FTN95 and the DLLs.

Thanks, Paul.

Here is more work for you extracted from the codes of crazy Fortran youngsters who surprisingly embraced so many modern Fortran latest tricks that the codes look unreadable as if this is not a Fortran. I lost last 4-5 months deciphering them. And unfortunately they are not in our forums but in the forums for the other compilers. This time it is a demo for 'associate' :

program associateTest

  implicit none
  integer :: a=1,b=1
  associate( x => a*b )
    print *, x                ! yields: 1
    a=10
    print *, x                ! yields: 1
  end associate

  associate( x => a )
    print *, x                ! yields: 10
    a=100
    print *, x                ! yields: 100
  end associate

end program associateTest