MODULE M3UTILIO
Fortran-90 styleMODULE M3UTILIO
does the "proper F90 way" of encapsulating the Models-3 I/O API parameter, data structure, and function-declarations, in a way that nested FortranUSE <module>
constructs do not interact with older FortranINCLUDE
statements to generate multiple-declaration errors at compile time.The issue is that when one has two or more Fortran-90
MODULE
s, sayMODULE A
thatUSE
sMODULE B
, where both of these need access to facilities provded by the standard I/O APIINCLUDE
filesPARMS3.EXT
,FDESC3.EXT
, and/orIODECL3.EXT
, there is a problem: ifMODULE B
INCLUDE
s these, it introduces an artificial dependency ofMODULE A
uponMODULE B
: where should theINCLUDE
statements be placed (if they appear in bothMODULE
s, the compiler will complain that variables and functions have repeated declarations, which is illegal. The problem is even worse ifMODULE A
USE
s a thirdMODULE C
, independent ofB
, that also needs I/O APIINCLUDE
files: one can't necessarily makeC USE B
, or vice versa.However, the Fortran-90
USE
construct does not have this problem:MODULE
sA
,B
, andC
can all have statementsUSE M3UTILIO
without causing multiple-declaration problems: the recognition that these statements provide one common set of declarations is now built into the Fortran-90 (and later) language, in a way not possible at all for Fortran-77 (and that must be managed manually by the programmer with #ifdefs for the corresponding C #include construct).
MODULE M3UTILIO
MODULE M3UTILIO
itself includes, and therefore replaces theINCLUDE
of the following Models-3 I/O APIINCLUDE
files:It further provides Fortran-90 style
PARMS3.EXT
FDESC3.EXT
IODECL3.EXT
INTERFACE
blocks for the following list of routines (basically, all of the public routines in the I/O API whose usage does not require "void pointer" arguments -- note that theBUFFER
argument for WRITE3() does not have a single specified type; it may beINTEGER, REAL,
orDOUBLE PRECISION
, and may have an arbitrary number of dimensions, instead of being restricted (as anINTERFACE
would require) to one single possibility like a 3-DREAL BUFFER(:,:,:)
, or requiring over three thousand lines of "wrapper" code to support the implied polymorphism. (IODECL3.EXT
is invoked from thisMODULE
to provide theEXTERNAL
declarations for these polymorphic routines, but not full interface blocks.)It also provides four cleanly-coded public parsing-utility routines that replace various less-well-conceived SMOKE 1.x library-routines,and new utility routines for grid-description checking and for integer unsorted-table lookup:
BILIN
BMATVEC
CURREC
CURSTEP
DAYMON
DMATVEC
DSCGRID and DSCOORD
DT2STR
ENVDBLE
ENVINT
ENVREAL
ENVSTR
ENVYN
FINDC
FIND1
FIND2
FIND3
FIND4
FINDR1
FINDR2
FINDR3
FINDR4
GCD
GETDATE
GETDBLE
GETDFILE
GETEFILE
GETFFILE
GETMENU
GETNUM
GETREAL
GETSTR
GETYN
GRDCHK3
HHMMSS
INDEX1
INDEXINT1
INTLIST
ISDST
JSTEP3
JULIAN
JUNIT
LAMBERT
and related routinesLBLANK
LOCAT1
LOCAT2
LOCAT3
LOCAT4
LOCATC
LOCATR1
LOCATR2
LOCATR3
LOCATR4
LUSTR
M3EXIT
M3FLUSH
M3MESG
M3MSG2
M3PARAG
M3PROMPT
M3WARN
MMDDYY
NEXTIME
PCOEF
PMATVEC
POLY
PROMPTDFILE
PROMPTFFILE
PROMPTMFILE
PROMPTGRID()
REALIST
SCANINT()
SEC2TIME
SECSDIFF
SETENVVAR
SORTIC
SORTI1
SORTI2
SORTI3
SORTI4
SORTR1
SORTR2
SORTR3
SORTR4
STR2DBLE
STR2INT
STR2REAL
STRLIST
TIME2SEC
UNGRIDB
UNGRIDI
UPCASE()
WKDAY
YEAR4
YR2DAY
- and more...
SUBROUTINE SPLITLINE( LINE, NMAX, N, FIELD, EFLAG )
CHARACTER(LEN=*), INTENT( IN ):: LINE
INTEGER, INTENT( IN ):: NMAX
INTEGER, INTENT( OUT ):: N
CHARACTER(LEN=*), INTENT( OUT ):: FIELD( NMAX )
LOGICAL, INTENT( OUT ):: EFLAG- split a line into fields, ignoring comments
SUBROUTINE FIXFIELD
CHARACTER(LEN=*), INTENT( INOUT ):: FIELD
- fixup, replacing blanks and "missing"s in character-string fields by zeros
REAL FUNCTION KEYVAL
CHARACTER(LEN=*), INTENT( IN ) :: KEY
- search for
REAL
key-value in I/O API file descriptive headerFDESC3D
array.
KEYSTR
- search for REAL key-value in I/O API file descriptive header
FDESC3D
array.
Note that in retro-fitting
MODULE M3UTILIO
into existing codes, one must not only remove all of theINCLUDE
statements associated with the standard I/O APIPARMS3.EXT
,FDESC3.EXT
, and/orIODECL3.EXT
, one must also remove any (now extra) declarations of the functions with explicitINTERFACE
s from the list given above.
Send comments to
Carlie J. Coats, Jr.
cjcoats@email.unc.edu