forums.silverfrost.com
Welcome to the Silverfrost forums

 What is the rationale for that ? Goto page 1, 2  Next
Author Message
DanRRight

Joined: 10 Mar 2008
Posts: 2777
Location: South Pole, Antarctica

Posted: Wed Jun 15, 2022 2:15 am    Post subject: What is the rationale for that ?

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

 Code: 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 ?
LitusSaxonicum

Joined: 23 Aug 2005
Posts: 2385
Location: Yateley, Hants, UK

Posted: Wed Jun 15, 2022 7:18 pm    Post subject:

One of Silverfrost;s proud boasts is
 Quote: 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
DanRRight

Joined: 10 Mar 2008
Posts: 2777
Location: South Pole, Antarctica

 Posted: Thu Jun 16, 2022 2:53 am    Post subject: 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
LitusSaxonicum

Joined: 23 Aug 2005
Posts: 2385
Location: Yateley, Hants, UK

 Posted: Thu Jun 16, 2022 9:05 am    Post subject: Dan, You are talking to the converted (me) - the simplicity of old-style Fortran has (in my opinion) been debauched. Eddie
Robert

Joined: 29 Nov 2006
Posts: 438
Location: Manchester

 Posted: Thu Jun 16, 2022 10:49 am    Post subject: > We let you use Fortran your way Do you think we should just force you to do it our way then?
LitusSaxonicum

Joined: 23 Aug 2005
Posts: 2385
Location: Yateley, Hants, UK

 Posted: Thu Jun 16, 2022 11:14 am    Post subject: 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).
Robert

Joined: 29 Nov 2006
Posts: 438
Location: Manchester

 Posted: Fri Jun 17, 2022 11:13 am    Post subject: 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: real*4, real*8, 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?
DanRRight

Joined: 10 Mar 2008
Posts: 2777
Location: South Pole, Antarctica

 Posted: Fri Jun 17, 2022 12:10 pm    Post subject: 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
DanRRight

Joined: 10 Mar 2008
Posts: 2777
Location: South Pole, Antarctica

Posted: Tue Jun 21, 2022 12:21 am    Post subject: Re:

 Robert wrote: 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: real*4, real*8, 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
simon

Joined: 05 Jul 2006
Posts: 268

 Posted: Tue Jun 21, 2022 5:14 pm    Post subject: 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.
JohnCampbell

Joined: 16 Feb 2006
Posts: 2506
Location: Sydney

 Posted: Wed Jun 22, 2022 5:10 am    Post subject: 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: REAL*4 : not accurate enough REAL*8 : the same precision I have selected for 40 years REAL*10 : was good as an accumulator when it was available, but AVX stoped all that. REAL*16 : could be great for some niche problems, but not hardware supported. For my work, there is only one possible real precision; REAL*8. I have not changed this selection since 1975 ! ( In structural engineering a node has 6 freedoms, 3 disp and 3 first derivitives which make real*4 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.
DanRRight

Joined: 10 Mar 2008
Posts: 2777
Location: South Pole, Antarctica

Posted: Thu Jun 23, 2022 10:06 pm    Post subject:

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 REAL*4 and may be REAL*2 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
 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

Last edited by DanRRight on Fri Jun 24, 2022 9:31 pm; edited 1 time in total
JohnCampbell

Joined: 16 Feb 2006
Posts: 2506
Location: Sydney

 Posted: Fri Jun 24, 2022 6:00 am    Post subject: 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
DanRRight

Joined: 10 Mar 2008
Posts: 2777
Location: South Pole, Antarctica

 Posted: Fri Jun 24, 2022 7:49 am    Post subject: Agree, John. Already use them close to that in my own codes
simon

Joined: 05 Jul 2006
Posts: 268

 Posted: Fri Jun 24, 2022 6:26 pm    Post subject: 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.
 Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First
 All times are GMT + 1 HourGoto page 1, 2  Next Page 1 of 2