This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
>To: address@hidden >From: Ryo Furue <address@hidden> >Subject: f90 suggestion: optional status code? >Organization: University of Hawaii >Keywords: 200407170841.i6H8fVaW021751 netCDF Fortran90 Hi Ryo, > Thank you for the wonderful library, which is extremely useful in my > work. I'm wondering if I could make a little suggestion for > possible improvement. > > I'm using the f90 interfaces of netcdf-3.5.1. I found it very awkward > to check the status code every time, as in > > i=nf90_def_dim(id, name = 'longitude', len = nx, dimid = xid) > if (i /= nf90_noerror) then > write(*,*) trim(nf90_strerror(i)) > stop 1 > end if > i=nf90_ . . . > if (i /= nf90_noerror) then > . . . . > > I have nearly thirty calls to netCDF functions in a single short > program. I know this is a traditional style of the C language. > But, since we use Fortran 90, which is more powerful than C in this > respect, we don't need to follow the (awkward) convention of C. > > What's the solution? We already have a nice answer in the Fortran > I/O statements (OPEN, READ, etc.). For example, the OPEN > statement has an optional argument named "iostat": > > open(unit = . . ., iostat = ios) > if (ios /= 0) then > write(*,*) "open error. iostat = ", ios > stop 1 > end if > > But, if you omit iostat when you "call" OPEN and if error occurs, > then the Fortran runtime system will issue an error message and > terminates the program. (I don't know if this is mandated by the > Fortran 90/95 standard, but most Fortran implementations do this > anyway.) On the other hand, if you specify the iostat argument and if > error occurs, the Fortran runtime remains silent and continues the > execution of the program. (I think this continuation is mandated by > the standard.) In this case, it's the programmer's responsibility > to handle (or not handle) the error. In this way, you can handle > the error for yourself if you want to, or if you don't, you can let > the Fortran runtime to take an appropriate action. > > We can mimic this behavior for the netCDF f90 interfaces; e.g., > > subroutine nf90s_def_dim(. . . , stat) ! <-- Not a function. > . . . . > integer, intent(out), optional:: stat > i=nf90_def_dim(. . .) > if (present(stat)) then > stat = i > else if (i /= nf90_noerror) then > write(*,*) trim(nf90_strerror(i)) > clean up and abort; or if the error is not severe > we just continue. > end if > end subroutine nf90s_def_dim > > I could write a set of wrappers myself but there are simply too many > functions. If I would write wrappers for myself, I would write them > only for the small number of functions I use, and so my effort would > be kind of wasted because the wrappers woudl be used only by me. > If, on the other hand, this interface style becomes official, many > users will be benefited from it. Thanks for the suggestion. I've forwarded it to the primary developer of the Fortran-90 interface, Robert Pincus. If he agrees that the benefits of your suggested change would be worth the cost of implementing and documenting the wrappers, we will consider adding such wrappers to a future release. Regards, --Russ _____________________________________________________________________ Russ Rew UCAR Unidata Program address@hidden http://www.unidata.ucar.edu/staff/russ