NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
On Tue, 2009-07-14 at 17:35 +0200, Thomas Orgis wrote: > > > Would such an "educated header" package be feasible? I really > think > > the problem is that the module file format is not standardised. > > I was speaking of a common source file, actually. To be compiled with > the compiler you are currently using. > The same way as the Fortran 77 interface (if I understand it > correctly). > If the binary is not portable, but the source is, then use the source. > Instead of the .mod file, NetCDF could construct one big source file > for Fortran 90 that creates the interface module when compiled in the > local source tree. > I see that it makes sense to keep the Fortran 90 interface code > distributed in several files for development, though. > this big source file is exactly what you get with the f90 netCDF interface. Unfortunately, you cannot win > But then, I can try to locate other Fortran 90 libraries (people > around here don't seem to use many) and see what's "the standard way". > there are not that many fortran libs (luckily). MPI is one of the worst ones since that also depends on the kind of interconnects you have.... > > The trick is to install fortran libraries into compiler-arch > dependent > > locations. > > So... there we are again. Since I copy my around between different > systems a lot, it might be less of an inconvenience to actually ditch > the Fortran 90 interface and use the Fortran 77 interface include file > instead. > Just like I used the NetCDF C API in C++. But there it was because of > some strangeness/problems of me understanding the C++ API, not because > of binary incompatibility ... I didn't think that far, back then. > this doesn't help you since it also applies to the f77 lib. Here it is a name mangling issue since different compilers expect different numbers of under scores appended to procedure names. you cannot win this one... > In the end, one might ask why one needs differing compilers on one > system. But well, for one it is the disturbing amount of compiler bugs > I encounter in Fortran (few people seem to actually use (more modern > parts of) the language), prompting me to quickly build with a > different compiler (gfortran instead of ifort, for example) to check > if it's not just some obscure construct in my code and not a compiler > fault. > yes, I prefer to use gfortran because: a) it comes with the system b) it's very picky c) produces excellent error messages unfortunately it doesn't produce the fastest of code (in many cases). although they are catching up here as well. newer versions of ifort are not too bad either. pgi is a pain. nag is quite good as well. > Also, I should inquire on what compiler has been used for NetCDF on > one of our Linux systems... it's neither the installed gfortran, nor > the ifort:-/ Given that, I suspect, though many people are working > with Fortran here, external Fortan 90 libraries do not seem to be a > big issue. > do you have the same build for each machine? or are they updated/installed individually? there is something to be said for having the same built of an OS on every machine. Cheers magi -- Magnus Hagdorn Specialist Computing Officer School of GeoSciences The University of Edinburgh Grant Institute West Mains Road Edinburgh EH9 3JW Scotland PHONE: (+44) 131 650 5894 FAX: (+44) 131 668 3184 email: Magnus.Hagdorn@xxxxxxxx
netcdfgroup archives: