With their book, Scientific Software Design, Rouson, Xia and Xu pose themselves not a small task: describing the contours of an entire sub-discipline of software engineering. Their exposé comprises such topics as performance of large systems, memory management in relation to language features and the use of design patterns to facilitate the maintenance of the program code. The consequences for coding in Fortran and C++ are described in detail, with the implementations in both languages being as close to each other as possible. This requires some compromises with respect to the more advanced features that are available in the respective languages. The great advantage, however, is that practitioners acquainted with one of the two can compare solutions in the other and even learn some of the subtleties inherent in their own.
{"title":"Review: scientific software design by Damian Rouson, Jim Xia and Xiaofeng Xu","authors":"A. Markus","doi":"10.1145/2594488.2594489","DOIUrl":"https://doi.org/10.1145/2594488.2594489","url":null,"abstract":"With their book, Scientific Software Design, Rouson, Xia and Xu pose themselves not a small task: describing the contours of an entire sub-discipline of software engineering. Their exposé comprises such topics as performance of large systems, memory management in relation to language features and the use of design patterns to facilitate the maintenance of the program code. The consequences for coding in Fortran and C++ are described in detail, with the implementations in both languages being as close to each other as possible. This requires some compromises with respect to the more advanced features that are available in the respective languages. The great advantage, however, is that practitioners acquainted with one of the two can compare solutions in the other and even learn some of the subtleties inherent in their own.","PeriodicalId":379614,"journal":{"name":"ACM SIGPLAN Fortran Forum","volume":"100 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2014-03-15","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"124901884","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Object-oriented programming has the reputation of allowing far-reaching abstractions in the source code, so that programs become more comprehensible and general. With the Fortran 2003 standard, the Fortran language has gained that power too, but that does not mean that it was impossible before to write compact code that hides all the implementation details. The user-defined operations and the overloading of standard operations for derived types as defined in the Fortran 90/95 standards already allow you to hide the gory details and stay close to, say, the mathematical formulation. In this note I present a straightforward solver for a simple partial differential equation as well as an implicit solver for an ordinary differential equation using these Fortran 90/95 features only. The attraction to me at least is the possibility to almost completely hide the numerical aspects in a set of routines implementing operations on a grid of data.
{"title":"User-defined and overloaded operations","authors":"A. Markus","doi":"10.1145/2594488.2594490","DOIUrl":"https://doi.org/10.1145/2594488.2594490","url":null,"abstract":"Object-oriented programming has the reputation of allowing far-reaching abstractions in the source code, so that programs become more comprehensible and general. With the Fortran 2003 standard, the Fortran language has gained that power too, but that does not mean that it was impossible before to write compact code that hides all the implementation details. The user-defined operations and the overloading of standard operations for derived types as defined in the Fortran 90/95 standards already allow you to hide the gory details and stay close to, say, the mathematical formulation. In this note I present a straightforward solver for a simple partial differential equation as well as an implicit solver for an ordinary differential equation using these Fortran 90/95 features only. The attraction to me at least is the possibility to almost completely hide the numerical aspects in a set of routines implementing operations on a grid of data.","PeriodicalId":379614,"journal":{"name":"ACM SIGPLAN Fortran Forum","volume":"42 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2014-03-15","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"123230690","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Standardized support of C language interface use, as defined in Fortran 2003, is nowadays implemented in most Fortran compilers. However, there are significant limitations to this interoperability, particularly with respect to Fortran objects for which no C analog exists. Furthermore, the language semantics as defined up to Fortran 2008 do not allow for a conforming implementation of the Message Passing Interface (MPI, [1]) which presently is the most prevalent parallelization approach on large-scale HPC systems. Therefore, a decision was made by the Fortran Standards Committee to develop a Technical Specification (ISO/IEC TS 29113 [2], referred to as “TS” in the following) that significantly extends the scope of the interoperation facilities; this work was concluded in 2012 by a successful WG5 ballot, and the TS was published by ISO shortly afterwards. This article provides an informal overview of the new facilities, which are also targeted for integration into the next release of the Fortran standard, with additional technical corrections if necessary.
{"title":"Extended interoperation with C","authors":"Reinhold Bader","doi":"10.1145/2553038.2553040","DOIUrl":"https://doi.org/10.1145/2553038.2553040","url":null,"abstract":"Standardized support of C language interface use, as defined in Fortran 2003, is nowadays implemented in most Fortran compilers. However, there are significant limitations to this interoperability, particularly with respect to Fortran objects for which no C analog exists. Furthermore, the language semantics as defined up to Fortran 2008 do not allow for a conforming implementation of the Message Passing Interface (MPI, [1]) which presently is the most prevalent parallelization approach on large-scale HPC systems. Therefore, a decision was made by the Fortran Standards Committee to develop a Technical Specification (ISO/IEC TS 29113 [2], referred to as “TS” in the following) that significantly extends the scope of the interoperation facilities; this work was concluded in 2012 by a successful WG5 ballot, and the TS was published by ISO shortly afterwards. This article provides an informal overview of the new facilities, which are also targeted for integration into the next release of the Fortran standard, with additional technical corrections if necessary.","PeriodicalId":379614,"journal":{"name":"ACM SIGPLAN Fortran Forum","volume":"40 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2013-11-26","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"134475041","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
After the long hiatus in the 1980s it was decided, partly to prevent a recurrence and partly to keep more closely to ISO schedules, that future revisions of the Fortran standard should be alternately major and minor. Thus Fortran 2008 was scheduled to be minor especially as vendors were struggling to implement all of the 2003 standard before it was superseded. In the event the 2008 standard turned out to be larger than expected, mainly because the impact of coarrays had not been appreciated. During development of the standard coarrays had proved to be controversial, and there were conflicting proposals to remove them altogether, to put them in a separate part of the standard or to move all or some of the facilities to a Technical Report. In February 2008 in order to achieve consensus it was finally agreed to keep a core set of features in the main language and to develop a TR to “cater for the other features plus possibly those suggested by public comment” with the expectation that the TR would be published some three years later. Subsequently ISO renamed ‘Technical Reports’ to be ‘Technical Specifications’. Incidentally ‘consensus’ is defined by ISO to be ‘absence of sustained opposition’; it does not necessarily imply unanimity.
{"title":"A report on the joint WG5 and PL22.3 meeting June 2013, Delft, Netherlands","authors":"D. Muxworthy","doi":"10.1145/2553038.2553039","DOIUrl":"https://doi.org/10.1145/2553038.2553039","url":null,"abstract":"After the long hiatus in the 1980s it was decided, partly to prevent a recurrence and partly to keep more closely to ISO schedules, that future revisions of the Fortran standard should be alternately major and minor. Thus Fortran 2008 was scheduled to be minor especially as vendors were struggling to implement all of the 2003 standard before it was superseded. In the event the 2008 standard turned out to be larger than expected, mainly because the impact of coarrays had not been appreciated. During development of the standard coarrays had proved to be controversial, and there were conflicting proposals to remove them altogether, to put them in a separate part of the standard or to move all or some of the facilities to a Technical Report. In February 2008 in order to achieve consensus it was finally agreed to keep a core set of features in the main language and to develop a TR to “cater for the other features plus possibly those suggested by public comment” with the expectation that the TR would be published some three years later. Subsequently ISO renamed ‘Technical Reports’ to be ‘Technical Specifications’. Incidentally ‘consensus’ is defined by ISO to be ‘absence of sustained opposition’; it does not necessarily imply unanimity.","PeriodicalId":379614,"journal":{"name":"ACM SIGPLAN Fortran Forum","volume":"112 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2013-11-26","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"124590672","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Compiler support for the Fortran 2003 and 2008 standards revision 14","authors":"I. Chivers, J. Sleightholme","doi":"10.1145/2553038.2553041","DOIUrl":"https://doi.org/10.1145/2553038.2553041","url":null,"abstract":"","PeriodicalId":379614,"journal":{"name":"ACM SIGPLAN Fortran Forum","volume":"2 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2013-11-26","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"128215334","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Exceptions are the rule in some programming languages, notably C++, Java and C#. They are used to create robust programs: if an exceptional situation occurs somewhere inside a library, say we can not find a particular record in a database table (or the table itself), this can be dealt with by raising or throwing an exception. A routine at a higher level is supposed to catch this and act upon the situation, either by presenting the user with a meaningful message or by providing an alternative. Exceptions, in the various forms they are implemented in the various languages, are described extensively in, for instance, Wikipedia [2].
{"title":"Exception handling in Fortran","authors":"A. Markus","doi":"10.1145/2502932.2502933","DOIUrl":"https://doi.org/10.1145/2502932.2502933","url":null,"abstract":"Exceptions are the rule in some programming languages, notably C++, Java and C#. They are used to create robust programs: if an exceptional situation occurs somewhere inside a library, say we can not find a particular record in a database table (or the table itself), this can be dealt with by raising or throwing an exception. A routine at a higher level is supposed to catch this and act upon the situation, either by presenting the user with a meaningful message or by providing an alternative. Exceptions, in the various forms they are implemented in the various languages, are described extensively in, for instance, Wikipedia [2].","PeriodicalId":379614,"journal":{"name":"ACM SIGPLAN Fortran Forum","volume":"53 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2013-07-12","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"125945252","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Compiler support for the Fortran 2003 and 2008 standards revision 12","authors":"I. Chivers, J. Sleightholme","doi":"10.1145/2460236.2460238","DOIUrl":"https://doi.org/10.1145/2460236.2460238","url":null,"abstract":"","PeriodicalId":379614,"journal":{"name":"ACM SIGPLAN Fortran Forum","volume":"77 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2013-03-28","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"121755927","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Introduction This is a repeating article in Fortran Forum. The first version appeared in Fortran Forum in April 2007. The basis for the entries in the original list of features was a report by John Reid. An electronic version can be found at: ftp://ftp.nag.co.uk/sc22wg5/N1601-N1650/N1648.pdf If you are a compiler vendor and would like to be included in future versions of this table please email one of us with details and they will be added to the table and published in Fortran Forum.
{"title":"Compiler support for the Fortran 2003 and 2008 Standards Revision 11","authors":"I. Chivers, J. Sleightholme","doi":"10.1145/2408747.2408749","DOIUrl":"https://doi.org/10.1145/2408747.2408749","url":null,"abstract":"Introduction This is a repeating article in Fortran Forum. The first version appeared in Fortran Forum in April 2007. The basis for the entries in the original list of features was a report by John Reid. An electronic version can be found at: ftp://ftp.nag.co.uk/sc22wg5/N1601-N1650/N1648.pdf If you are a compiler vendor and would like to be included in future versions of this table please email one of us with details and they will be added to the table and published in Fortran Forum.","PeriodicalId":379614,"journal":{"name":"ACM SIGPLAN Fortran Forum","volume":"5 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2012-12-05","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"131899332","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Compiler support for the Fortran 2003 and 2008 standards revision 10","authors":"I. Chivers, J. Sleightholme","doi":"10.1145/2338786.2338789","DOIUrl":"https://doi.org/10.1145/2338786.2338789","url":null,"abstract":"","PeriodicalId":379614,"journal":{"name":"ACM SIGPLAN Fortran Forum","volume":"31 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2012-07-24","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"130275376","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Although the Fortran programming language is evolving steadily, it still lacks a framework for error handling-- not to be confused with floating point exceptions. Therefore, the commonly used techniques for handling errors did not change much since the early days and do not benefit from the new features of Fortran 2003. After discussing some historical approaches, a Fortran 2003 framework for error handling is presented. This framework also proved to be valuable in the context of unit testing and the design-by-contract (DBC) paradigm.
{"title":"Error handling in Fortran 2003","authors":"K. Poppe, R. Cools, Bart Vandewoestyne","doi":"10.1145/2338786.2338787","DOIUrl":"https://doi.org/10.1145/2338786.2338787","url":null,"abstract":"Although the Fortran programming language is evolving steadily, it still lacks a framework for error handling-- not to be confused with floating point exceptions. Therefore, the commonly used techniques for handling errors did not change much since the early days and do not benefit from the new features of Fortran 2003. After discussing some historical approaches, a Fortran 2003 framework for error handling is presented. This framework also proved to be valuable in the context of unit testing and the design-by-contract (DBC) paradigm.","PeriodicalId":379614,"journal":{"name":"ACM SIGPLAN Fortran Forum","volume":"3 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2012-07-24","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"121852238","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}