forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

What is the rationale for that ?
Goto page 1, 2  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General
View previous topic :: View next topic  
Author Message
DanRRight



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

PostPosted: Wed Jun 15, 2022 2:15 am    Post subject: What is the rationale for that ? Reply with quote

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 ?
Back to top
View user's profile Send private message
LitusSaxonicum



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

PostPosted: Wed Jun 15, 2022 7:18 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Thu Jun 16, 2022 2:53 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
LitusSaxonicum



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

PostPosted: Thu Jun 16, 2022 9:05 am    Post subject: Reply with quote

Dan,

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

Eddie
Back to top
View user's profile Send private message
Robert



Joined: 29 Nov 2006
Posts: 411
Location: Manchester

PostPosted: Thu Jun 16, 2022 10:49 am    Post subject: Reply with quote

> We let you use Fortran your way

Do you think we should just force you to do it our way then?
Back to top
View user's profile Send private message Visit poster's website
LitusSaxonicum



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

PostPosted: Thu Jun 16, 2022 11:14 am    Post subject: Reply with quote

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).
Back to top
View user's profile Send private message
Robert



Joined: 29 Nov 2006
Posts: 411
Location: Manchester

PostPosted: Fri Jun 17, 2022 11:13 am    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message Visit poster's website
DanRRight



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

PostPosted: Fri Jun 17, 2022 12:10 pm    Post subject: Reply with quote

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" Smile

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
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Tue Jun 21, 2022 12:21 am    Post subject: Re: Reply with quote

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 Smile. 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
Back to top
View user's profile Send private message
simon



Joined: 05 Jul 2006
Posts: 216

PostPosted: Tue Jun 21, 2022 5:14 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2387
Location: Sydney

PostPosted: Wed Jun 22, 2022 5:10 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Thu Jun 23, 2022 10:06 pm    Post subject: Reply with quote

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 Smile.

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. Smile 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
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2387
Location: Sydney

PostPosted: Fri Jun 24, 2022 6:00 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Fri Jun 24, 2022 7:49 am    Post subject: Reply with quote

Agree, John. Already use them close to that in my own codes
Back to top
View user's profile Send private message
simon



Joined: 05 Jul 2006
Posts: 216

PostPosted: Fri Jun 24, 2022 6:26 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General All times are GMT + 1 Hour
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group