brendanarnold / py-fortranformat

MIT License
31 stars 7 forks source link

Enhancement to include default * format on write and read #30

Open derry43 opened 1 year ago

derry43 commented 1 year ago

Found this to be incredibly useful for porting of Fortran code to python. Not sure how possible, but would be great if this module could handle default formats for output (and maybe input) e.g.

header_line = FortranRecordWriter(*) or perhaps header_line = FortranRecordWriter()

(for reading ... header_line = FortranRecordReader(*) or perhaps header_line = FortranRecordReader())

Where providing either an asterisk or empty argument list would use a set of default formats. For example, Oracle Fortran uses the following default formats for List Directed Output

Type Format
BYTE Two blanks followed by the number
CHARACTER*n An {n = length of character expression}
COMPLEX Two blanks followed by '(', 1PE14.5E2, ',', 1PE14.5E2, ')'
COMPLEX*16 Two blanks followed by '(', 1PE22.13.E2, ',', 1PE22.13.E2, ')'
COMPLEX*32 Two blanks followed by '(', 1PE44.34E3, ',', 1PE44.34E3, ')'
INTEGER*2 Two blanks followed by the number
INTEGER*4 Two blanks followed by the number
INTEGER*8 Two blanks followed by the number
LOGICAL*1 Two blanks followed by the number
LOGICAL*2 L3
LOGICAL*4 L3
LOGICAL*8 L3
REAL 1PE14.5E2
REAL*8 1PE22.13.E2
REAL*16 1PE44.34E4
brendanarnold commented 6 months ago

For reading, we would need to pass in the field width information and the number of fields to delimit the data and at that point you might as well be specifying the G edit descriptor which then does what you are asking.

For writing I think it could be done bu I can see a couple of obstacles here to overcome ...

  1. To do this we would need to give Python some hints as to what kind of FORTRAN data type to use since there are far fewer Python data types. For example, python has only one float type so we would need to know if we should use REAL, REAL*8 or REAL*16. We could use the biggest size by default but this could generate excessively large text files, too small risks losing important precision in some cases.

  2. The CHARACTER being variable length I think would provide some problems when outputting records since many FORTRAN outputs tend to rely on being fixed width rather than looking for delimiters - certainly this library wouldn't be able to re-read files with variable width

For both of these I think being able to configure globally which edit descriptor is used for each Python type would get around that. So there would be sensible defaults chosen from the list above but people could override them e.g.

config.DEFAULT_CHARACTER_EDIT_DESCRIPTOR= '32A' or config.DEFAULT_FLOAT_EDIT_DESCRIPTOR = '1PE44.34E4'

Thoughts?