Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

silo.inc incompatible with free-format F9x; other Fortran standards issues #14

Closed
aowen87 opened this issue Feb 26, 2019 · 0 comments
Closed
Assignees

Comments

@aowen87
Copy link

aowen87 commented Feb 26, 2019

When attempting to build sample code using libsilodev shipped with Linux Mint(Ubuntu/Debiam) (v4.813) I had compilation issues because silo.inc is formatted as a hybrid F77/F9x fixedformat file. Specifically, F9x freeformat expects a continuation character of '&' placed at the end of a line to be continued, rather than prepending a character in column 6 on the subsequent line(s). There are also issues with comment characters, case, and stringlength (see Bug #503). I checked if this issue was still present in the current build and it is, though it's not apparent since no lines were wrapped duringmy testing. Attached to Bug #503 is an updated version of mkinc which seems to address the above issues. The full summary of the changes are as follows: Enhanced F77 and F9Xstyle output. Specifically: Better estimate of C string length (fix for Bug #503). Leading and trailing delimiters are ignored in length calculation as are escaped entities (\n, \r, etc.) Accepts commandline argument of f90 to produce F9xstyle output compatible with both fixed and freeformat F9x code Improved standards compliance. Changed comment and continuation characters to be appropriate for both F77 and F9x. Note that lower-case is an extension to F77 so F77 identifiers have been upcased Converted standalone EXTERNAL and PARAMETER statements to attributes of type declarations for F9x. This is a F9x best practice by putting all variable properties in one place as attributes to the variable declaration. Removed line-wrapping code; declarations have been burst into one per line. This obviates the need for line wrapping and makes differences in the exposed API clearer between versions. It seems to work after cursory testing (visual inspection of output). While it's technically more of a feature request, I'd suggest writing two separate include files, one for F77 and one for F9x. The modified mkinc writes F90 with a six space indent, continuation characters ('&') are appended to lines which are continued, and prepended in column 6 of subsequent lines, allowing the resulting file to work unmodified with both free and fixedformat F9x code. Again, I've attached the modified mkinc to a response to Bug #503 rather than duplicate it here. Please let me know if you have anycomments or questions. Bob

-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.

Ticket number: 1546
Status: Resolved
Project: VisIt
Tracker: Bug
Priority: Normal
Subject: silo.inc incompatible with free-format F9x; other Fortran standards issues
Assigned to: Mark Miller
Category: -
Target version: 4.9.2
Author: Bob Apthorpe
Start: 07/28/2013
Due date:
% Done: 0%
Estimated time:
Created: 07/28/2013 11:08 pm
Updated: 02/27/2014 12:33 am
Likelihood: 5 - Always
Severity: 2 - Minor Irritation
Found in version: 4.8
Impact:
Expected Use:
OS: All
Support Group: Any
Description:
When attempting to build sample code using libsilodev shipped with Linux Mint(Ubuntu/Debiam) (v4.813) I had compilation issues because silo.inc is formatted as a hybrid F77/F9x fixedformat file. Specifically, F9x freeformat expects a continuation character of '&' placed at the end of a line to be continued, rather than prepending a character in column 6 on the subsequent line(s). There are also issues with comment characters, case, and stringlength (see Bug #503). I checked if this issue was still present in the current build and it is, though it's not apparent since no lines were wrapped duringmy testing. Attached to Bug #503 is an updated version of mkinc which seems to address the above issues. The full summary of the changes are as follows: Enhanced F77 and F9Xstyle output. Specifically: Better estimate of C string length (fix for Bug #503). Leading and trailing delimiters are ignored in length calculation as are escaped entities (\n, \r, etc.) Accepts commandline argument of f90 to produce F9xstyle output compatible with both fixed and freeformat F9x code Improved standards compliance. Changed comment and continuation characters to be appropriate for both F77 and F9x. Note that lower-case is an extension to F77 so F77 identifiers have been upcased Converted standalone EXTERNAL and PARAMETER statements to attributes of type declarations for F9x. This is a F9x best practice by putting all variable properties in one place as attributes to the variable declaration. Removed line-wrapping code; declarations have been burst into one per line. This obviates the need for line wrapping and makes differences in the exposed API clearer between versions. It seems to work after cursory testing (visual inspection of output). While it's technically more of a feature request, I'd suggest writing two separate include files, one for F77 and one for F9x. The modified mkinc writes F90 with a six space indent, continuation characters ('&') are appended to lines which are continued, and prepended in column 6 of subsequent lines, allowing the resulting file to work unmodified with both free and fixedformat F9x code. Again, I've attached the modified mkinc to a response to Bug #503 rather than duplicate it here. Please let me know if you have anycomments or questions. Bob

Comments:
Apply Bob's changes. Thanks, Bob!

@aowen87 aowen87 closed this as completed Feb 26, 2019
@biagas biagas transferred this issue from visit-dav/visit Mar 21, 2019
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants