What is the rationale for that ?

I see the code where ALL not-integer constants are defined like this

    INTEGER, PARAMETER :: num = KIND(1.d0)
    REAL(num), PARAMETER :: c_tiny = TINY(1.0_num)
    REAL(num), PARAMETER :: c_largest_number = HUGE(1.0_num)
    REAL(num), PARAMETER :: c_maxexponent = MAXEXPONENT(1.0_num)
    REAL(num), PARAMETER :: c_log2 = 0.69314718055994530941723212145817657_num
    REAL(num), PARAMETER :: pi = 3.141592653589793238462643383279503_num
    REAL(num), PARAMETER :: q0 = 1.602176565e-19_num ! C (+/- 3.5e-27)
    REAL(num), PARAMETER :: m0 = 9.10938291e-31_num ! kg (+/- 4e-38)
    REAL(num), PARAMETER :: c  = 2.99792458e8_num   ! m/s^2 (exact)
    REAL(num), PARAMETER :: kb = 1.3806488e-23_num  ! J/K (+/- 1.3e-29)
    REAL(num), PARAMETER :: mu0 = 4.e-7_num * pi ! N/A^2 (exact)
    REAL(num), PARAMETER :: epsilon0 = 8.854187817620389850536563031710750e-12_num
    REAL(num), PARAMETER :: h_planck = 6.62606957e-34_num ! J s (+/- 2.9e-41)
    REAL(num), PARAMETER :: ev = q0 ! J
    REAL(num), PARAMETER :: h_bar = 1.054571725336289397963133257349698e-34_num
    REAL(num), PARAMETER :: a0 = 5.291772101121111395947216558438464e-11_num
    REAL(num), PARAMETER :: hartree = 4.359744350823120007758594450644308e-18_num
    REAL(num), PARAMETER :: alpha = 7.2973525755230202568508027295271584628e-3_num
    REAL(num), PARAMETER :: atomic_time = 2.418884320905619591809404261549867e-17_num
    REAL(num), PARAMETER ::  atomic_electric_field = 5.142206538736485312185213306837419e11_num
    REAL(num), PARAMETER :: mc0 = 2.73092429345209278e-22_num
    REAL(num), PARAMETER :: b_s = 4.414005028109566589829741352306303e9_num
    REAL(num), PARAMETER :: e_s = 1.323285417001326061279735961512150e18_num
    REAL(num), PARAMETER :: alpha_f = 7.297352575523020256850802729527158e-3_num
    REAL(num), PARAMETER :: tau_c = 1.288088667367242662108649212042082e-21_num
    jx = 0.0_num
    jy = 0.0_num
    jz = 0.0_num

    gx = 0.0_num
    gy = 0.0_num
    gz = 0.0_num

    idx = 1.0_num / dx
    idy = 1.0_num / dy
    idz = 1.0_num / dz
    idt = 1.0_num / dt
    dto2 = dt / 2.0_num
    dtco2 = c * dto2
    dtfac = 0.5_num * dt * fac
    third = 1.0_num / 3.0_num
 .......................................
 .......................................

Hell amount of them, and all with _num. Be it 0.d0, 1.d0, or 2.d0 etc Why this was done when there was no intention to use real*4 in the code ever?

Is this any better than just write 0d0, 1d0 or 2d0 ? OK, ok, i will now remember till the end of my days not to do that due to one dumb but now unavoidable Fortran exclusion. 'Better' is not good word here. Really useful, at least really will be ever needed? At least 0.d0,1.d0 or 2.d0 etc is always shorter. Or people writing this way think their codes in the future will be running on unknown alien's architecture totally different from major current ones?

Was this verbose and annoying way or writing done just to avoid potential bug because Fortran default real type is REAL*4 ?

One of Silverfrost;s proud boasts is

We let you use Fortran your way , so if it compiles, then they are living up to it!

Devotees of telling other people how to program usually employ rather incomprehensible and obscure statements, don't they?

I call them 'hammocky headstanders'. PM me if you don't understand that.

Eddie

This code uses all modern tricks besides that. Instead of being simpler due to that we get usually much larger size and complexity. It's ok when you will be the only author who support the code, but if you give it for everyone, the amount of potential users will drop dramatically because very little percentage of Fortran users know and willing to learn these OO, polymorphism etc features. Due to complexity the code becomes like Tesla car, completely not fixable by the consumer. Will see while i will be using more these new features may be i am wrong.

Sometimes there is no choice, like for example with abandoning common blocks in favor of modules because developers found no way to make common block variables allocatable. I feel i lost a lot of simplicity in reusing subroutines due to that (which were before like almost independent lego blocks) because common block was telling you exactly which variables are communicating with the external world. Now when i try to move some feature to another code i see million variables in the major module and know i will never select those variables which go only to this specific subroutine. If i will try to make many smaller modules, i will get huge modules interdependence and will eventually give up with those conflicts. Hopefully PLATO really solved such conflicts problem,i need to try it. How MAKE misses such conflicts we saw few messages back

Dan,

You are talking to the converted (me) - the simplicity of old-style Fortran has (in my opinion) been debauched.

Eddie

We let you use Fortran your way

Do you think we should just force you to do it our way then?

Robert,

Up to a point, you do. Every compiler does. One lives with that. At least FTN95 accepts both color (for those with Webster's Syndrome) as well as colour! So the boast is lived up to in many different respects. I think that you got the wrong end of the stick quoting it back as if I criticised it.

The point is that Dan doesn't like people writing things he doesn't understand, or doesn't think is good practice. Dijkstra made his name spouting off on that subject, and I suspect that many others have too, saying things like you can write Fortran in any language. I just shrug my shoulders safe in the knowledge that stuff I wrote over 50 years ago* I can still follow, and it still runs, and I don't force my views on others. Some of the stuff Dan cites probably can't be followed by its author 50 seconds after he/she/xe/they wrote it - and certainly not by Dan without a lot of effort, or by me at all. That's fine by me.

In my view, for what it's worth (which ain't much, granted) most of the changes to Fortran were made either by people who hate Fortran as it is or was (bad) or who want stuff to be allocatable because that minimises the space take up on systems that have multiple users simultaneously (commendable), completely missing the point that such people are outnumbered millions to one by other folk using PCs who have the entire machine at their disposal, and for whom, frankly, a couple of Gb is effectively infinite. People programming on PCs want tools to do graphics or make a GUI, and FTN95 has those - indeed, so did FTN95 even in the DBOS days - things that the Fortran Committee in their wisdom (or lack of it) have never provided. And that's praise for Salford/Silverfrost.

So letting users do it their way seems to me to be a great idea, and if someone has a way that seems to Dan (or even me) to be stark, staring, bonkers, then that's their business. But sometimes, perhaps, Dan has a point, don't you agree?

Eddie

*And thankfully, I don't expect to have to be able to follow it 50 years hence! (But someone else might).

It is funny how computer languages develop. I suspect the current trends have quite a big impact on them. Ten years later there are another set of trends. Twenty years later it all looks a bit odd... I wonder if Fortran needed much more developing past Fortran 90.

FTN77 (as was DBOS!) was written in Fortran 77 with a few extensions. In about 1990 a macro processor was added and that allowed quite nasty bit operations on arrays to be converted into a nice form that looked like function calls. With the addition of some allocatable and a struct I think it would have been a very programmable set up.

I don't write mathematical models so.... do people actually use this kind stuff? I get that you might want a data type to have a certain precision but that is usually pretty fixed on the system you are using: real4, real8, real*10. I see lots of Fortran like the stuff Dan posted -- is it really used to dynamically select data types at compile time, or does it just make the source code look messy?

In the area i work there is still a lot of programming scientific development. That activity got stimulated by the progress in ultrapowerful lasers with ultrashort pulse durations like femtoseconds and attoseconds, ultrarelativistic intensities allowing to achieve ultra high energy densities...The guys got Nobel Prize for the trick which allowed all that. There are a lot of buzzwords like 'ultra' and 'super', the supercomputers are also there. Projects usually require tens of millions of core-hours per years. Petaflops, petabytes of storage and top500 buzzwords are common like 'inflation' 😃

So here come also computer science departments folks. They of course bring all the latest tricks into the programming. It was them by the way who started to port many programs initially written in Fortran to C/C++ because they know this language better. They brought some euphoria initially that with such old 'dumb' language like Fortran and such great powerful and universal one as C/C++ they will be able to screw Fortran and make brilliant programs.

The result ? Codes became much larger. Much harder to read. How they debug such codes is beyond me, even Fortran codes are full of hidden bugs. And if funding is stable and decent, say, because this is national lab magnitude project - things in general got not bad there. The codes despite not being easily manageable sometimes work not as bad. Of course the cost of development there millions and millions dollars for many years. But if even one person out of team of 5-10 will move out of project because of funding depletion or other reason the whole modeling project is doomed. Obviously CS folks change their jobs and interest pretty often.

Now i found serious and complex code with Fortran too. Initially it was written in older Fortran by other people. But here came guys who made it super modern. All was OK, the code was used by the community pretty often. But now one of its major developers who rewrote the code using Fortran2003 does not 100% of his time works with this project and the result is? I thought because the code in Fortran i will start it running and modifying the way i need it to in a day or two. And spent two month so far. Nobody answers the questions on the Github for these months. Almost no people develop anything there. I got a 'cultural shock' comparing how quickly we get responds on this forum and having absolutely none there. Zero. Thanks one of developers found his time to answer my questions, but that was when i asked personally, the GitHub still looks like a graveyard.

And possibly why this happened? I suspect this in part is due to the way the code was written - it is really way too modernistic Fortran. And very verbose. And with large codes the size does matter. Simplicity is the key. Now i more and more think that rewriting public Fortran codes from older easy Fortran not only to C/C++ is bad idea but probably to use too modernistic Fortrans is also a mistake for the codes where the authors may leave the project.

Time will tell while i learn the tricks of their language if rewriting to modern Fortran was justified or not

Quoted from Robert

I don't write mathematical models so.... do people actually use this kind stuff? I get that you might want a data type to have a certain precision but that is usually pretty fixed on the system you are using: real4, real8, real*10. I see lots of Fortran like the stuff Dan posted -- is it really used to dynamically select data types at compile time, or does it just make the source code look messy?

Robert, I had one method which needed extended precision for REAL*10 where the numbers were in the order of 10^4000 and I'd took it even more if it would be allowed. This was just the stupid approach to solve some problem due to its straightforward simplicity. It is possible to avoid that but this required complication of the code.

The EPOCH code we are discussing indeed has a lot of dynamic selections at compile time. Authors chose this for some unknown reasons, possibly to save the RAM memory which is never enough be it 640k, or 640MB or 640GB. With last one by the way my tasks do not even start 😃. This makes the code less universal and the user to recompile the code permanently for specific task which is of course super inconvenient. But in some cases this is the only option to run. Happens all the time because, for example, with 3D simulations (and the trend is to run things in real world dimensions) the simple increase of size by factor of 2, which might look small, immediately increases RAM consumption 8 times. And needs 8 times more powerful supercomputer

It seems to me that by saying 'when there was no intention to use real*4 in the code ever', you do close the door to _num being a useful new feature. But what IF you did wish to change the precision, then you only need to change line 1? And if you wanted to ensure similar results on different machine architectures, you may well need to change the precision. On a Cray, for example, the code you supply would effectively be run in quadruple precision. I use something similar to _num and make line 1 a conditional compilation, something like the following, defining DOUBLE_PRECISION using (for FTN95) /VPARAM:

#if DOUBLE_PRECISION == 1 INTEGER, PARAMETER :: num = KIND(1.d0) #else INTEGER, PARAMETER :: num = KIND(1.e0) #endif

You could do something more intelligent using SELECTED_REAL_KIND to deal with the Cray idiosyncrasy. This way you do not have to change the code in different settings.

If appending '_num' is verbose why not use '_d', for example, instead?

Anyway, my point is that I have found this, and quite a few of the other modern features of Fortran, have made programming simpler and more streamlined. I am sorry to hear that is not others' experience.

Simon,

I disagree with your rosey picture of KIND. This is what introduced bloat into Fortran. Things have only got worse !

Given that most computer hardware now supports IEEE 754, the idea of selecting an alternative precision is rarely necessary.

The possibilities are: REAL4 : not accurate enough REAL8 : the same precision I have selected for 40 years REAL10 : was good as an accumulator when it was available, but AVX stoped all that. REAL16 : could be great for some niche problems, but not hardware supported.

For my work, there is only one possible real precision; REAL8. I have not changed this selection since 1975 ! ( In structural engineering a node has 6 freedoms, 3 disp and 3 first derivitives which make real4 impractical) There is no need for all the extra bloat in code when there are no practical alternatives.

The problem is more for INTEGER KIND, especially when trying to define 64-bit integer constants in 64-bit Fortran. Perhaps FTN95 should consider recognising 3000000000_8 as a valid 64-bit integer.

When switching between different compilers, a concise description of 64-bit integers can be annoying. You can't be lazy in FTN95 and use 3000000000_4 ! I do get in the habit of writing 3*billion.

Simon, I'd not worry about Cray precision in this case because this was a PIC code. It has inherent problem which is its kind of 'genetic defect' like a quantum noise or similarly sensor noise of digital cameras. It has very limited number of particles per cell N and so the relative noise is sqrt(N)/N. With N=100 particles for example the noise is 10%. So even REAL4 and may be REAL2 with 8 bits per number (256 gradations) probably sometimes an overkill for this method in terms of accuracy 😃.

I was just pocking very strict elitistic 'finishing school accent' of this code asking if this has any justifiable purpose or it just exposed personal style and taste of the coder.

But in general case if you are doing multi-purpose multisystem future proof codes plus you afraid that sometimes you may forget to declare some variable or a constant by needed kind this style might be useful, i do not know.

How specifically you use /VPARAM ? How /VPARAM of defining special parameter works in other cases ? What kind of special parameters can be defined?

And i wish Silverfrost would make eventually such code

#if DOUBLE_PRECISION == 1
INTEGER, PARAMETER :: num = KIND(1.d0)
#else
INTEGER, PARAMETER :: num = KIND(1.e0)
#endif

recognizable by their compiler. FTN03 would be good name for it. 😃 ALL other compilers already do that even all that appeared recently

Dan,

A few suggestions for OP

INTEGER, PARAMETER :: wp = KIND(1.d0)        !  wp =  working precision
REAL(wp), PARAMETER :: c_log2 = log(2.0_wp) 
REAL(wp), PARAMETER :: pi = 4*atan(1.0_wp)  ! much safer, unless you prefer all the digits on pi day 14-Mar

Agree, John. Already use them close to that in my own codes

Hi Dan,

I think there is no disagreement that the new Fortran features DO enable the programmer to be much more verbose and obscure! And maybe, unfortunately, that is the general tendency.

The example I provided DOES work in FTN95. You need to run with the preprocessor, obviously, and so if you have:

#if DOUBLE_PRECISION == 1 INTEGER, PARAMETER :: num = KIND(1.d0) #else INTEGER, PARAMETER :: num = KIND(1.e0) #endif

you would need to compile with /FPP /VPARAM DOUBLE_PRECISION 1.

Simon, Wow, i did not know about preprocessor is already there. Never used or seen people used it in this forum at least.

As to these new Fortran features there clearly are world champions of obscurity and verbosity. Out of curiosity i compared the original code written by other people which was then rewritten into Fortran2003 code. Original was ~3 times smaller and absolutely clear. No heavy use of derived types, pointers, interfaces, model procedures, no anything fancy complicating readabilty to the state you're totally lost. For example, in Fortran2003 code IF or DO blocks look very small. But the trick is that this was because the source text was packed into subroutines. These subroutines immediately called another subroutines, which called another and another which called INCLUDE files 😃

Fun was to find that OPEN(file=..., status=...) is not just one line of Fortran code but also a subroutine 113 lines long. The WRITE(unit=..., Format=...) not one line of Fortran code but several subroutines around 2KB each which are very specific for some obscure data packing file format no one here used or knew.

One of the most confusing is that you never know the variable is array or not and what is its dimensions, types and interfaces, and how to find all that quickly. And when trying to find all that among 100s of files you totally lose the track.

Will i change my mind as times go and i will use these features? Possible but not very likely. Because even the authors of this long rewritten code now say that the code is quite large and complex 😃

Additional intrigue with this code is that the original Fortran source code was also rewritten by some other people. Fun is that it was moved to C. Will ask these folks if they are happy with that move too in which i doubt a lot. I have seen people moved from Fortran to C and then the code development almost stopped. Soon i will be able to compare several such codes performances, and we will see how much they no doubt lost here too.

Simon, i tried this code

#if PHOTONS==1
INTEGER, PARAMETER :: num = KIND(1.d0)
#else
INTEGER, PARAMETER :: num = KIND(1.e0)
#endif

print*, num
end

compiling it

ftn95 aaa.f90 /link /fpp /vparam PHOTONS 1 >z

and getting this error message

0001) #if PHOTONS==1
*** Invalid character '#' at start of line
*** Statement not recognised
0003) #else
*** Invalid character '#' at start of line
*** Statement not recognised
0004) INTEGER, PARAMETER :: num = KIND(1.e0)
*** NUM has already been declared with the PARAMETER attribute
WARNING - NUM has been declared more than once with the same type (see line 2)
0005) #endif
*** Invalid character '#' at start of line
*** Statement not recognised
    7 ERRORS, 1 WARNING  [<main program> FTN95 v8.83.0]
*** Compilation failed

What's wrong?

You need /CFPP.

https://silverfrost.com/ftn95-help/options/using_the_preprocessor.aspx

Thanks, Paul

About preprocessor: in some 3rd party code FTN95 found the error on this line

#include '../afivo/src/cpp_macros.h'



0001) #include '../afivo/src/cpp_macros.h'
*** Invalid character '#' at start of line
*** Statement not recognised

Is this incompatibility of FTN95 with this code or still a preprocessor command ? I see in other places this code uses preprocessor commands usual way like this #if NDIM == 2 if (GL_cylindrical) volume = af_cyl_volume_cc(box, i) #endif

To use it i will compile with

FTN95 apic.f90 /CFPP /VPARAM NDIM 2 

If this is C-style preprocessing then how i have to setup /CFPP to use this include file ? Should i do like this ?

FTN95 apic.f90 /CFPP /VPARAM INCLUDE '../afivo/src/cpp_macros.h' 

repeating the line of source text in the command prompt ? But there are a lot of such preprocessor definitions in the code and all of them to add into compilation line would be probably impossible. Here is the complete their list in this mentioned above file 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

Wish this is not our usual Saturday devilry from the hell 😃