#49accepted - Defect (None)

erf.f90 type mismatch with newer gfortran compilers


Hello, I'm pasting in an error report that I emailed to a few people on 11 February 2013. I see that the error is still present in the most recent v9.2 downloaded from flexpart.eu.

I listed priority as "major" because if you're using the newer gfortran, well, it's not going to compile. Other than that, though, it's probably not a big deal.

--- Email from 11 Feb 2013 ---

I've been installing and running the latest FLEXPART v9.02, compiled with gfortran 4.7.1 and 4.7.2.

As I mentioned to Delia and Jerome recently, the newer gfortran compilers are very strict (I think starting somewhere around 4.6 or so). I spent a lot of time last summer and autumn working with NCEP on some porting to gfortran. Stuff that would compile and run fine with Intel, Portland Group, and even older versions of gfortran had to be modified to compile and run correctly with the newest gfortran compilers. In my humble opinion, this is generally a good thing - it means that if you can get your code through the gfortran 4.7.1+ gauntlet, you might have some pretty solid code. Always better to have problems caught by the compiler than to have to spend lots of time debugging elusive runtime problems.

So, in compiling FLEXPART v9.02 tonight, I ran into some type mismatch issues in erf.f90 where double precision values were being stored in single precision variables. I know, it's all petty, but the newer gfortran wants you to be aware of these. My "quick fix" was just to declare an offending external function as type double precision and convert an argument to double precision before passing into a function.

diff erf.f90 erf.f90.ORIG
106c106
< double precision, external :: gammln
---
> real, external :: gammln
111c111
< gln=gammln(DBLE(a))
---
> gln=gammln(a)
140c140
< double precision, external :: gammln
---
> real, external :: gammln
145c145
< gln=gammln(DBLE(a))
---
> gln=gammln(a)


I don't feel like the changes I made adhered to your paradigm of using a "dp" KIND as defined in par_mod.f90, but I didn't want to make assumptions. I just wanted a quick fix, which I would notify you of, and then let you decide if/how you want to modify things.