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 

Fortran 2003 and 2008 features
Goto page Previous  1, 2, 3  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Suggestions
View previous topic :: View next topic  
Author Message
mecej4



Joined: 31 Oct 2006
Posts: 1124

PostPosted: Mon Jan 21, 2019 6:56 pm    Post subject: Reply with quote

That's nice to hear. Thanks.
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2079
Location: Sydney

PostPosted: Tue Jan 22, 2019 3:00 am    Post subject: Reply with quote

Commenting on the addition of TR15581 functionality:
When using FTN95 at present, the approach required for modifying allocatable arrays is to place the allocatable array in a MODULE and address it directly in the routine. As well as allocating, the other task is to check and re-size allocatable arrays if they are required to store more information.
This approach is limiting, as only a specific array can be defined.

TR15581, allows allocatable arrays to be routine arguments and so can be defined or adjusted when required, rather than designed in the routine hierarchy. This provides for routines to be more general and deal with multiple arrays of the same rank.

The other complexity of this additional functionality is the use of INTENT with ALLOCATABLE which can imply automatic deallocation.
TR15581 is not a trivial change, but would be very helpful.

The other changes I have been requesting are hopefully less complex. They are :
1) to include "information" intrinsic procedures that have been provided in F2003 and F2008. This assists in standardising the approach/name for information that is often available with other FTN95 library routines.
2) to provide other information routines that are becoming more useful (hopefully to others as well), such as GlobalMemoryStatusEx and others that have been identified lately.
3) to provide a version of ISO_FORTRAN_ENV module that covers the features in FTN95 that are included in the F2003 and F2008 module definition.

I would hope that the features selected in this list are easy to implement and so provides a coding path for improved portability and extent the usefulness of FTN95, which is my primary development compiler.

The other wish I would have is support for some OpenMP functionality, using the !$OMP directives. FTN95 has recently provided some multi-threaded capability, but the addition of PRIVATE variable construction would be very helpful. Unfortunately, this may be a much more complex addition. I would like to suggest support of OpenMP Version 3.0 or 3.1, but I am sure requests for later more complex versions would soon come.

Some indication on what is more likely or easier to achieve would be informative.

(apologies this post is similar to my previous post, but does provide some additional info. I have been on holidays on the beach, so have forgotten what I did last year, which is becoming an issue for us Fortran programmers !!)
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5912
Location: Salford, UK

PostPosted: Tue Jan 22, 2019 8:46 am    Post subject: Reply with quote

John

Thank you for the feedback.

I understand about TR15581 but your items 1-3 are somewhat vague. If you can be more specific then that would help. OpenMP seems to be unrealistic to me at the moment.

I am not sure if you know this but GlobalMemoryStatus@ already provides access to GlobalMemoryStatusEx.
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1124

PostPosted: Tue Jan 22, 2019 3:36 pm    Post subject: Reply with quote

In the category 1) of John's post there are routines for parsing the command line used to run a user program, such as COMMAND_LINE, GET_COMMAND, etc. Some of these are FTN95 extensions, some are from F2003, and it would be useful to know whether each such routine is standard or an extension.

Consider an example. In the FTN95 8.3 help file, when I look up the description for "Command line parsing routines", I can see COMMAND_LINE and GET_COMMAND listed with the description "Reads the whole command line." If the help file told me (with an 'X', or a check mark) that only the latter was from F2003, when writing new code I would use that in preference to the nonstandard one. Similarly, when I look up COMMAND_LINE, the help file could inform me (with a mark, a distinct background colour, etc.) that there exists a standard routine with the same functionality.


Last edited by mecej4 on Wed Jan 23, 2019 4:27 pm; edited 4 times in total
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5912
Location: Salford, UK

PostPosted: Wed Jan 23, 2019 8:23 am    Post subject: Reply with quote

mecej4

Thanks for the feedback. I will see what can be done.
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1115
Location: Aerospace Valley

PostPosted: Wed Jan 23, 2019 12:14 pm    Post subject: Reply with quote

would it not be good form to start periodically (say every 3 months) publishing the 'wish list' to the forums, just for information so we know in general the direction(s) this great software is taking ?
You know my area of interest (which I don't even know if it appears on the infamous list or not let alone it's priority) and I'm sure lots of people have an interest to know if past reauests are in imminent danger of being adressed.
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5912
Location: Salford, UK

PostPosted: Mon Mar 18, 2019 10:20 am    Post subject: Reply with quote

The next release of FTN95 will allow dummy arguments to be ALLOCATABLE arrays. This will include the corresponding INTENT restrictions.
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2079
Location: Sydney

PostPosted: Wed Mar 20, 2019 2:51 am    Post subject: Reply with quote

Paul,

Thanks very much for this addition.
I shall be interested to test it when it is released.

This has the potential to simplify the code structure for resizing allocatable arrays.
It will be interesting to adopt in existing projects, as it can involve removing the old messy approach that is now working.

John
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Mon May 27, 2019 2:20 am    Post subject: Reply with quote

No GETENV yet?
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1115
Location: Aerospace Valley

PostPosted: Mon May 27, 2019 5:37 am    Post subject: Reply with quote

Dan,

I don't see it mentioned in the v8.5 revision history (neither in announcements nor in documentation - we're all human and can forgt to add things in such lists), but clearly it has bheen addd (presumeably in v8.5 as that is what Paul said back on 12 Dec 2018)
No doubt Paul also has his own spreadsheet to keep track of, what is sometimes a bit of a mysterious black box to us, his 'wish list' ... his 'hit list' .... of what needs addressing, and it's priorities.

... because it's here in the online documentation ... https://silverfrost.com/ftn95-help/system/getenv.aspx
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5912
Location: Salford, UK

PostPosted: Mon May 27, 2019 7:43 am    Post subject: Reply with quote

See the announcement for v8.50...

Quote:
Fortran 2003 standard intrinsic GET_ENVIRONMENT_VARIABLE added.
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1115
Location: Aerospace Valley

PostPosted: Mon May 27, 2019 1:46 pm    Post subject: Reply with quote

Indeed Paul ... apologies, my error in not realising that GETENV@ (the documented new function I assume) wouldn't be mentioned in the release notes.

Maybe it would be a good idea to avoid other dumbo users like myself from searching for non-existent terminology, to mod the description to something like:

Quote:
Fortran 2003 standard intrinsic GET_ENVIRONMENT_VARIABLE added via the introduction of new ClearWin+ function GETENV@


It might be a goofėd idea too to mention in the description of GETENV@ that it is based on calls to the windows API: GET_ENVIRONMENTAL_VARIABLE.
That would have help me pick up my faux pas too.
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Mon May 27, 2019 10:20 pm    Post subject: Reply with quote

I know about GETENV@, users here played with it a lot. Here is for example the code to find the processor parameters.
Code:

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
Code:
   if(qui.eq.' ') call getenv('USER',qui)
and clearly this GETENV has different I/O
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5912
Location: Salford, UK

PostPosted: Tue May 28, 2019 7:12 am    Post subject: Reply with quote

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



Joined: 31 Oct 2006
Posts: 1124

PostPosted: Tue May 28, 2019 1:56 pm    Post subject: Reply with quote

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.
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 -> Suggestions All times are GMT + 1 Hour
Goto page Previous  1, 2, 3  Next
Page 2 of 3

 
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