# NetCDF Fortran on Conda Forge for Windows **URL:** \ **Category:** Uncategorized\ **Created:** [March 1, 2023, 9:26pm UTC](https://fortran-lang.discourse.group/t/netcdf-fortran-on-conda-forge-for-windows/5312 "2023-03-01T21:26:01Z")\ **Posts on this page:** 18\ **Page:** 1
**Author:** ![samharrison7](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/samharrison7/32/3868_2.png) [@samharrison7](https://fortran-lang.discourse.group/u/samharrison7)\ **Post date:** [March 1, 2023, 9:26pm UTC](https://fortran-lang.discourse.group/t/netcdf-fortran-on-conda-forge-for-windows/5312/1 "2023-03-01T21:26:01Z")
I just spotted that about a month or so ago, the netcdf-fortran Conda package from Conda Forge got a Windows build (there has been Linux and Mac versions for ages, but Windows had some issues): [Netcdf Fortran :: Anaconda.org](https://anaconda.org/conda-forge/netcdf-fortran) This is, potentially, awesome. An easy way to install NetCDF Fortran on Windows! However, after giving it a quick test, I stumbled across the age old issue of incompatible GFortran versions: `cannot read module file netcdf.mod because it was created by a different version of GNU Fortran`. Correct me if I’m wrong, but this basically means that the only way to use this Conda package in the usual `use netcdf` way is to use the same version of GFortran as the Conda build used. Which from what I can tell is the old m2w64 version 5.3. I know @lkedward has mentioned his NetCDF interfaces package before as an awesome solution for this in a lot of cases ([GitHub - LKedward/netcdf-interfaces: fpm package containing module interfaces for netcdf-fortran](https://github.com/LKedward/netcdf-interfaces)). But it still left me wondering whether the situation is as I’ve summarised here, and I’m not missing some other solution? ---
**Author:** ![jacobwilliams](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jacobwilliams/32/10_2.png) [@jacobwilliams](https://fortran-lang.discourse.group/u/jacobwilliams)\ **Post date:** [March 3, 2023, 1:24am UTC](https://fortran-lang.discourse.group/t/netcdf-fortran-on-conda-forge-for-windows/5312/2 "2023-03-03T01:24:34Z")
Ancient compilers and incompatible mod files: two of the albatrosses around Fortran’s neck. ---
**Author:** ![rwmsu](https://avatars.discourse-cdn.com/v4/letter/r/48db29/32.png) [@rwmsu](https://fortran-lang.discourse.group/u/rwmsu)\ **Post date:** [March 3, 2023, 1:19pm UTC](https://fortran-lang.discourse.group/t/netcdf-fortran-on-conda-forge-for-windows/5312/3 "2023-03-03T13:19:26Z")
I’m always surprised that a standard transportable mod file format is not a higher priority when it comes to new Fortran features. Take it from someone who got stuck with the task of supporting multiple versions of MPI, HDF5, netCDF etc. just because of the mod file incompatability problem a transportable mod file format will solve a lot more problems for Fortran developers than a some of things that will sadly end up in Fortran 2023 and Fortran will be stuck with forever. For example, I refer everyone to @jacobwilliams (excellent) March 27, 2022 post on [Degenerate Conic | The New Features of Fortran 202x](https://degenerateconic.com/the-new-features-of-fortran-202x.html) and his comments about the new “multiple subscript” and using an integer array to specify rank and bounds. I am in total agreement with Jacob on these two new “features”. In 40 plus years of developing and modifying CFD and Finite element codes I have never seen a case where either of these two features would lead to a better code. ---
**Author:** ![zoziha](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/zoziha/32/582_2.png) [@zoziha](https://fortran-lang.discourse.group/u/zoziha)\ **Post date:** [March 4, 2023, 2:10am UTC](https://fortran-lang.discourse.group/t/netcdf-fortran-on-conda-forge-for-windows/5312/5 "2023-03-04T02:10:30Z")
The question is whether it is possible for the Fortran Standards Committee to provide some basic standards for Fortran’s .mod files to ensure compatibility, C/C++ uses text files as header files, and Fortran’s .mod seems to be some kind of binary code, resulting in differences in .mod files in different historical versions of the same compiler, and .mod files between compilers from different vendors are not interoperable. ---
**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\ **Post date:** [March 4, 2023, 3:14am UTC](https://fortran-lang.discourse.group/t/netcdf-fortran-on-conda-forge-for-windows/5312/6 "2023-03-04T03:14:47Z")
> [@kargl](#): > > One column of numbers above is wrong. That program is a nice demo of the difference between `sin()` and `sinpi()`. However, I would not say that the first column is “wrong”. I would expect those numbers are the closest number to the exact value of `sin(x)` for those values of `x`. If they are, then they are not “wrong”, they are “right”, and if the first column were all zeros, like the second column, then they would in fact be “wrong”. ---
**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\ **Post date:** [March 4, 2023, 5:53pm UTC](https://fortran-lang.discourse.group/t/netcdf-fortran-on-conda-forge-for-windows/5312/8 "2023-03-04T17:53:13Z")
> [@kargl](#): > > Yes, those wrong numbers are less than 1 ULP in double precision. If one looks at relevant standards `sinpi(x)` is mandated to be exact if `x` is integral; while `sin(M_PI * x)` will raise `FE_INEXACT`. Can you elaborate on these statements a little? If one considers 0.0\_dp to be the mathematically exact resullt for both columns of numbers, then spacing(0.0\_dp) is many orders of magnitude smaller than the values on the left from sin(x). My previous post explains why those values are what they are. Namely, x is a fp value near the mathematical vaue of PI. Whatever that value is (which of course depends on the floating point representation), the exact sin(x) value is nonzero. The slope of sin(x) is about -1 in that neighborhood, so whatever the difference is between the floating point value and the exact value will then result in an exact sin(x) value of that same magnitude. The values in the first column are presumably the correctly rounded values of those differences. There are other issues involved with range reduction, particularly for large values of the arguments, but I don’t think that is a central part of this issue regarding the difference between `sin(x)` and `sinpi(x)` and what the “exact” values should be for the two columns. The other issue you mention is FE\_INEXACT. I think that occurs for any floating point multiplication that involves rounding (i.e. where bits are lost in the representation of the result). There are some cases, such as when an operand is a power of 2, that do not involve rounding, but most multiplications do involve rounding. So in a complicated function like `sin(x),` some or all of the multiplications involved in the evaluation are going to raise that exception. ---
**Author:** ![Robpk](https://avatars.discourse-cdn.com/v4/letter/r/8797f3/32.png) [@Robpk](https://fortran-lang.discourse.group/u/Robpk)\ **Post date:** [March 4, 2023, 10:45pm UTC](https://fortran-lang.discourse.group/t/netcdf-fortran-on-conda-forge-for-windows/5312/10 "2023-03-04T22:45:22Z")
> [@kargl](#): > > ```auto > libm = 1.9643867237284719e-15, /* 0x3ce1b191, 0x40c0c0d5 */ > mpfr = 1.9643867237284719e-15, /* 0x3ce1b191, 0x40c0c0d5 */ > ULP = 0.00926 > > ``` Could you elaborate how do you compute ULP in there? I’ve seen a couple formulas for it, but perhaps you have a different approach. I am writing some code for computing non-elementary functions. I am also comparing the computed value with a higher precision one, but then the error checking has merely consisted in plotting the relative error and checking it is below `5e-8` (for floats; or at least, below `1e-7`). ---
**Author:** ![samharrison7](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/samharrison7/32/3868_2.png) [@samharrison7](https://fortran-lang.discourse.group/u/samharrison7)\ **Post date:** [March 5, 2023, 9:38am UTC](https://fortran-lang.discourse.group/t/netcdf-fortran-on-conda-forge-for-windows/5312/12 "2023-03-05T09:38:06Z")
> [@zoziha](#): > > The question is whether it is possible for the Fortran Standards Committee to provide some basic standards for Fortran’s .mod files to ensure compatibility. This sounds very sensible. Do we know if something like this has been proposed before? I can’t believe it hasn’t been, it’s surely not just a handful of us that struggle with this `.mod` file incompatibility. What are the barriers? I’m guessing back compatibility is the main one. ---
**Author:** ![rwmsu](https://avatars.discourse-cdn.com/v4/letter/r/48db29/32.png) [@rwmsu](https://fortran-lang.discourse.group/u/rwmsu)\ **Post date:** [March 5, 2023, 1:15pm UTC](https://fortran-lang.discourse.group/t/netcdf-fortran-on-conda-forge-for-windows/5312/13 "2023-03-05T13:15:30Z")
My answer to a transportable mod file would be to base it on something like a markup language (XML or a derivative maybe). Compiler options could select between native or standard format for output. I’m willing to allow the compiler vendors native format and a standard format to coexist just as long a there are options to read and write the standard format. You could view the standard format as something like using the COO sparse matrix format as a bridge for converting between other formats. The vendors could write their own translators to their native formats. There is probably a way to have some kind of encryption decryption capabilty for folks selling commercial libraries to protect their IP. As to why this hasn’t been done before, anything I say would be speculation. ---
**Author:** ![zoziha](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/zoziha/32/582_2.png) [@zoziha](https://fortran-lang.discourse.group/u/zoziha)\ **Post date:** [March 5, 2023, 1:47pm UTC](https://fortran-lang.discourse.group/t/netcdf-fortran-on-conda-forge-for-windows/5312/14 "2023-03-05T13:47:27Z")
The specific reasons may be familiar to some of the old Fortran users, I’m just a beginner, but I think there’s always a way to change, the key is who drives it? We don’t have to get to this point right away, maybe we can look for a unified interface mod file for Fortran for the next decade. It is clearly fragmented at the moment, and the lack of intercommunication of .mod files is one of the reasons why some well-known libraries like MKL, IMSL, LAPACK, FFTW tend to use F77 style interfaces. HDF5 and NetCDF have compatibility risks because they use F90 `module` functions. On Windows, I was able to use MSYS2-gfortran to call mkl’s F77 dynamic link library, but once mkl was F90-style and used module functionality, the `.mod` interface would not necessarily be parsed by MSYS2-gfortran. ---
**Author:** ![mecej4](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/mecej4/32/855_2.png) [@mecej4](https://fortran-lang.discourse.group/u/mecej4)\ **Post date:** [March 5, 2023, 1:47pm UTC](https://fortran-lang.discourse.group/t/netcdf-fortran-on-conda-forge-for-windows/5312/15 "2023-03-05T13:47:59Z")
Most Fortran compilers use .mod as the file suffix for the module files that they generate. Until recently, the Absoft compiler would attempt to read and use .mod files if they existed, rather than regenerate them in the course of compilation. There were times when it would attempt to read .mod files produced by Gfortran (which are plain text) and the ensuing behavior was entertaining. Thus, some provision will be needed to enable each compiler to distinguish between its own module files from other compiler’s module files, unless there is complete compatibility of mod files across all compilers. ---
**Author:** ![rwmsu](https://avatars.discourse-cdn.com/v4/letter/r/48db29/32.png) [@rwmsu](https://fortran-lang.discourse.group/u/rwmsu)\ **Post date:** [March 5, 2023, 1:54pm UTC](https://fortran-lang.discourse.group/t/netcdf-fortran-on-conda-forge-for-windows/5312/16 "2023-03-05T13:54:54Z")
Maybe I’m missing something but I’m not asking for vendors to read other vendors formats. I’m asking for a standard format that everyone can read (and translate to their native format if so desired). Even then how hard would it be to add a string to a vendors current mod file (I’m guessing they all have a header block of some kind at the start of the file) that says what compiler produced the file. ---
**Author:** ![cmaapic](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/cmaapic/32/659_2.png) [@cmaapic](https://fortran-lang.discourse.group/u/cmaapic)\ **Post date:** [March 5, 2023, 3:26pm UTC](https://fortran-lang.discourse.group/t/netcdf-fortran-on-conda-forge-for-windows/5312/17 "2023-03-05T15:26:18Z")
A bit of history. I’ve worked with another language that used modules - Modula 2. Here is a link to a page about the language. > **[Modula-2](https://en.wikipedia.org/wiki/Modula-2)** > > Modula-2 is a structured, procedural programming language developed between 1977 and 1985/8 by Niklaus Wirth at ETH Zurich. It was created as the language for the operating system and application software of the Lilith personal workstation. It was later used for programming outside the context of the Lilith. > Wirth viewed Modula-2 as a successor to his earlier programming languages Pascal and Modula. The main concepts are: > The language design was influenced by the Mesa language and the Xerox A... Modules created by these compilers weren’t compatible with the compilers I used. ---
**Author:** ![jacobwilliams](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jacobwilliams/32/10_2.png) [@jacobwilliams](https://fortran-lang.discourse.group/u/jacobwilliams)\ **Post date:** [March 5, 2023, 3:52pm UTC](https://fortran-lang.discourse.group/t/netcdf-fortran-on-conda-forge-for-windows/5312/18 "2023-03-05T15:52:04Z")
Perhaps the more solvable problem is how to work with Conda Forge to get them to support more recent compilers? I too have these issues. I can’t use the ancient gfortran compilers because they don’t support the language features I use (or they have show stopping bugs). Also I need to be able to support the intel compiler. In some cases, there will be a conda package (e.g. HDF5) that has built in fortran bindings, but I can’t use it because it was compiled with gfortran. So I’m back to having to compile it myself on multiple platforms. In a future where all Fortran libraries are FPM compatible, these issues may go away since it could be trivial to just compile everything you need very easily. Right now, it’s still very chaotic and tedious (make files, cmake, scons, random build scripts, downloading and manually editing files from some random webpage, poor Windows support, etc.) ---
**Author:** ![samharrison7](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/samharrison7/32/3868_2.png) [@samharrison7](https://fortran-lang.discourse.group/u/samharrison7)\ **Post date:** [March 5, 2023, 5:00pm UTC](https://fortran-lang.discourse.group/t/netcdf-fortran-on-conda-forge-for-windows/5312/19 "2023-03-05T17:00:51Z")
> [@jacobwilliams](#): > > Perhaps the more solvable problem is how to work with Conda Forge to get them to support more recent compilers? Agreed. On a similar note, I noticed when building a Conda package on Windows just now that you get a warning message that… `WARNING:conda_build.windows:Using legacy MSVC compiler setup. This will be removed in conda-build 4.0. If this recipe does not use a compiler, this message is safe to ignore. Otherwise, use {{compiler('')}} jinja2 in requirements/build.` …if you use the MSYS2 GFortran (v5.3). If you do as they suggest and use `{{ compiler('fortran') }}`, I think you get an even more ancient version of classic Flang. I hope we have some success getting more modern Fortran compilers onto Conda Forge before they enact that threat! ---
**Author:** ![ashe](https://avatars.discourse-cdn.com/v4/letter/a/ce73a5/32.png) [@ashe](https://fortran-lang.discourse.group/u/ashe)\ **Post date:** [March 6, 2023, 6:12pm UTC](https://fortran-lang.discourse.group/t/netcdf-fortran-on-conda-forge-for-windows/5312/20 "2023-03-06T18:12:15Z")
> [@samharrison7](#): > > > [@zoziha](#): > > > > The question is whether it is possible for the Fortran Standards Committee to provide some basic standards for Fortran’s .mod files to ensure compatibility. > > This sounds very sensible. Do we know if something like this has been proposed before? I can’t believe it hasn’t been, it’s surely not just a handful of us that struggle with this `.mod` file incompatibility. What are the barriers? I’m guessing back compatibility is the main one. Even if `.mod` files were compatible across compilers, wouldn’t there still be a problem with object files? As far as I know there are no standard calling conventions for Fortran, and runtime library calls would also not be compatible. ---
**Author:** ![Jian](https://avatars.discourse-cdn.com/v4/letter/j/7ba0ec/32.png) [@Jian](https://fortran-lang.discourse.group/u/Jian)\ **Post date:** [September 29, 2023, 4:01am UTC](https://fortran-lang.discourse.group/t/netcdf-fortran-on-conda-forge-for-windows/5312/21 "2023-09-29T04:01:48Z")
I have a question about the netcdf-fortran installed by conda in windows. It shows the error of “undefined reference to `\_\_netcdf\_MOD\_nf90\_create’” and other “\__netcdf\_MOD\_nf90_” errors. I have set the -I"xxxx/include" and -L"xxxx/lib" -lnetcdff -lnetcdf. ---
**Author:** ![MuellerSeb](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/muellerseb/32/7568_2.png) [@MuellerSeb](https://fortran-lang.discourse.group/u/MuellerSeb)\ **Post date:** [April 16, 2026, 9:32am UTC](https://fortran-lang.discourse.group/t/netcdf-fortran-on-conda-forge-for-windows/5312/22 "2026-04-16T09:32:13Z")
They will switch to flang on windows in the near future: > > > This PR has been triggered in an effort to update \[\*\*flang21\*\*\](https://conda-fo…rge.org/status/migration/?name=flang21). > > Notes and instructions for merging this PR: > 1. Please merge the PR only after the tests have passed. > 2. Feel free to push to the bot's branch to update this PR if needed. > > \*\*Please note that if you close this PR we presume that the feedstock has been rebuilt, so if you are going to perform the rebuild yourself don't close this PR until the your rebuild has been merged.\*\* > > \ > > Here are some more details about this specific migrator: > > \> > \> TL;DR: We are trying to switch our Fortran compilers on windows to flang. > \> This is not 100% guaranteed to work, but should be fine in the majority of cases. > \> > \> The new LLVM-based flang has become mature enough that it should be possible to > \> broadly switch over our Fortran compilers on windows to it (until now we only had > \> an ancient pre-LLVM flang 5, or alternatively the GCC-based \`m2w64\_fortran\`). > \> > \> As such, this PR attempts to homogenize any use of \`m2w64\_fortran\` and other \`m2w64\_\*\` > \> compilers to our default stack (which would then be MSVC + flang on windows), with > \> the exception of feedstocks for R-packages, which stay on the \`m2w64\_\` compilers. > \> > \> Recipes that have hard-coded expectations about the name of the fortran compiler > \> will need to adjust to use \`%FC%\` or \`flang\` for the compiler name. Similarly, > \> you may need to change the linker to \`%FC\_LD%\` or use \`lld-link\`. > \> > \> It is also possible that you run into compilation errors due to differences in > \> compiler behaviour, bugs or as-yet unimplemented features. In case of compilation > \> errors due to stricter default language standards, you should be able to fix things > \> by passing \`-std=legacy\` to \`FFLAGS\`. > \> > \> If you have problems with this PR, feel free to ping the @c-f/flang-activation team. > \> In case you have convinced yourself that flang really is not ready yet to be used to > \> compile a given feedstock, you may also close this migrator PR. > > \ > > If this PR was opened in error or needs to be updated please add the \`bot-rerun\` label to this PR. The bot will close this PR and schedule another one. If you do not have permissions to add this label, you can use the phrase \@\conda-forge-admin, please rerun bot\ in a PR comment to have the \`conda-forge-admin\` add it for you. > > \This PR was created by the \[regro-cf-autotick-bot\](https://github.com/regro/cf-scripts). The \*\*regro-cf-autotick-bot\*\* is a service to automatically track the dependency graph, migrate packages, and propose package version updates for conda-forge. Feel free to drop us a line if there are any \[issues\](https://github.com/regro/cf-scripts/issues)! This PR was generated by https://github.com/regro/cf-scripts/actions/runs/19917055956 - please use this URL for debugging.\