Welcome to our forums
See the announcement for v8.50...
Fortran 2003 standard intrinsic GET_ENVIRONMENT_VARIABLE added.
I know about GETENV@, users here played with it a lot. Here is for example the code to find the processor parameters.
Integer, external :: processor_id
jj= processor_id ()
end
!=====================================
integer function processor_id ()
!
! With thanks to John Horspool 2008-04-02
!
use mswin
CHARACTER*400 LDATA
CHARACTER*80 getenv@, IDENTIFIER
CHARACTER*80 CPU_stepping, CPU_description
integer n_processorsTotalGetEnv
character*256 ResultsToSave(10)
integer iVersionOfTesrResFile
LSTR=400
k = REGOPENKEYEX(HKEY_LOCAL_MACHINE, &
'HARDWARE\DESCRIPTION\System\CentralProcessor\0', 0,KEY_READ,MyKey)
CPU_description= ' N/A '
if (MyKey.GT.0) then
k = REGQUERYVALUEEX(MyKey,'ProcessorNameString', &
CORE4(0),CORE4(0),LDATA,LSTR)
! WRITE(*,'(a,a)')' Processor : ', LDATA(1:LSTR)
CPU_description = LDATA(1:min(80,LSTR))
endif
k = REGCLOSEKEY(MyKey)
! write(*,*) getenv@('PROCESSOR_IDENTIFIER')
! write(*,*) 'Number of cores=', getenv@('NUMBER_OF_PROCESSORS')
READ(getenv@('NUMBER_OF_PROCESSORS'),*)n_processorsTotalGetEnv
Write (*,*) ' Number of Processors/cores/threads= ', &
n_processorsTotalGetEnv, ' ', getenv@('PROCESSOR_IDENTIFIER')
Read (getenv@('PROCESSOR_IDENTIFIER'),'(a)') CPU_stepping
processor_id=2
end function
But now I compile some third party code which has the line
if(qui.eq.' ') call getenv('USER',qui)
and clearly this GETENV has different I/O
As far as I am aware GETENV is not in the Fortran standard.
It commonly takes the form CALL GETENV(NAME, VALUE) so this could be added to the FTN95 library.
Fortran codes developed on Unix/Linux may make calls to routines in the '3f' group. The following is the Oracle/Sun man page for GETENV:
https://docs.oracle.com/cd/E37069_01/html/E54439/getenv-3f.html
If this routine is added to FTN95, the 3f way of handling insufficient argument string sizes may also need to be implemented.
mecej4
Thanks for the information.
The release notes for version 8.70 state:
The Fortran 2003 feature that allows standard intrinsics in initialisation statements has been added
I am pleased to be using this feature, but note that INT and REAL are not yet permitted by FTN95. Are there any plans to add these?
simon
I guess that this was just an oversight. I will make a note of this omission.
Out of interest, can you illustrate this with code where these are useful?
Paul,
Simon's post reminded me of this one. A colleague who uses another compiler came up with this, which does not work with FTN95:-
integer, parameter :: dp=kind(1.d0), n = 10
integer i
complex(kind=dp), dimension(1:10), parameter :: j_n = [ (cmplx(0.d0,i,kind=dp), i = 1, 10) ] ! Not acceptable to FTN95, but OK with others
do i = 1, n
print*, i, j_n(i)
end do
end
Their compiler produces:
1 (0.0000000000000000,1.0000000000000000)
2 (0.0000000000000000,2.0000000000000000)
3 (0.0000000000000000,3.0000000000000000)
4 (0.0000000000000000,4.0000000000000000)
5 (0.0000000000000000,5.0000000000000000)
6 (0.0000000000000000,6.0000000000000000)
7 (0.0000000000000000,7.0000000000000000)
8 (0.0000000000000000,8.0000000000000000)
9 (0.0000000000000000,9.0000000000000000)
10 (0.0000000000000000,10.000000000000000)
While FTN95 says:-
Error 172 - Constant expression expected
Compilation failed.
Many thanks Paul. Using this new feature, I am now defining various constants in the declarations, thus:
Module m
Implicit None
Intrinsic Epsilon, Huge, Kind, Sqrt, Tiny
!
Integer, Parameter, Public :: rp = Kind(1.0d0) ! - double precision -
!
Real(Kind=rp), Parameter, Public :: one = 1.0_rp ! - one -
!
Integer, Parameter, Public :: ihuge = Huge(rp) ! - huge integer -
!
Real(Kind=rp), Parameter, Public :: rhuge = Huge(one) ! - huge real -
Real(Kind=rp), Parameter, Public :: eps = Epsilon(one) ! - machine precision -
Real(Kind=rp), Parameter, Public :: sfmin = Tiny(one) ! - safe minimum -
Real(Kind=rp), Parameter, Public :: sfmax = one/sfmin ! - safe maximum -
Real(Kind=rp), Parameter, Public :: smlnum = Sqrt(sfmin)/eps ! - small number -
Real(Kind=rp), Parameter, Public :: bignum = one/smlnum ! - big number -
Real(Kind=rp), Parameter, Public :: tol = Sqrt(eps) ! - tolerance -
End Module m
It would be nice to add the following:
Real(Kind=rp), Parameter, Public :: base = Real(Radix(one), Kind=rp) ! - base -
Real(Kind=rp), Parameter, Public :: bt = base**(Digits(one) - 1) ! - machine precision -
Simon and Ken
Thank you for the information.
The use of REAL in an initialisation expression will be permitted in the next release of FTN95.
Unfortunately allowing cmplx in an initialisation expression with array constructor would involve a disproportional amount of work. So for the time being at least it will be necessary to change the code to...
complex(kind=dp), dimension(1:10):: j_n
j_n = [ (cmplx(0.d0,i), i = 1, 10) ]
Paul, Thanks for the feedback, I know to avoid this construction (for now).
Many thanks, Paul. Will INT also be available?
Simon
It seemed to me that INT was already available. If not can you provide a sample.
Hi Paul, INT does not appear to be working. As long as you do not ask me to remember why I am using this particular equation(!), here is an example:
Real(Kind=rp), Parameter, Public :: elim = Real(Int(0.693_rp*MaxExponent(one)), Kind=rp)
where 'one' is previously defined as a Real(Kind=rp) parameter, 1.0_rp
Simon
This has now been fixed for the next release of FTN95.
I have just tried to compile LAPACK 3.10.0 and get an error message about FLOOR and CEILING not being permitted in initialization. Paul kindly enabled a few intrinsic functions to be used in initialization. May I add these to his in tray? Many thanks, Simon
Thanks Simon. I have logged this for investigation.
FLOOR and CEILING have now been added for the next release of FTN95.
Hi Paul, Would it be difficult to add SOURCE= as an optional argument to ALLOCATE? I believe it is a 2003 standard.