[FLASH-USERS] Compiling LaserSlab for FLASH 4.4 error in Diffuse_computeFluxLimiter.F90
Marissa Adams
madams at pas.rochester.edu
Tue Jan 3 13:47:35 EST 2017
Thank you very much Klaus. Your patch actually did not apply successfully,
it says that Hunk #2 Failed at 194.
However looking at the file, I just took the changes and suggestions you've
implied in your e-mail, edited that bit of the code, and it made it through
the part of the compilation where it normally stops (as mentioned in my
previous e-mail), however right at the end it spit out these errors, saying
that the math functions have multiple definitions:
e.g.
> /opt/ibmcmp/xlf/bg/14.1/bglib64/libxlfmath.a(math.o): In function `_pow':
> math.c:(.opd+0x408): multiple definition of `_pow'
>
Surely as a result of my change. Would you suggest I talk to the system
admins at this point?
Thank you for your help.
On Fri, Dec 30, 2016 at 4:32 PM, Klaus Weide <klaus at flash.uchicago.edu>
wrote:
> On Fri, 30 Dec 2016, Marissa Adams wrote:
>
> > mpixlf90_r -I/usr/local/hypre/2.8.0b-MPI-XL-No-Global-Partition/include
> -g
> > > -O3 -qnohot -qrealsize=8 -qnosave -qfixed -c -qthreaded
> > > -qsuffix=f=F90:cpp=F90 -qfree=f90 -WF,-DFLASH_3T -WF,-DMAXBLOCKS=1000
> > > -WF,-DNXB=16 -WF,-DNYB=16 -WF,-DNZB=1 -WF,-DN_DIM=2
> > > Diffuse_computeFluxLimiter.F90
> > > "Diffuse_computeFluxLimiter.F90", line 200.37: 1513-041 (S) Arguments
> of
> > > the wrong type were specified for the INTRINSIC procedure "min".
> > > ** diffuse_computefluxlimiter === End of Compilation 1 ===
> > > 1501-511 Compilation failed for file Diffuse_computeFluxLimiter.F90.
> > > make: *** [Diffuse_computeFluxLimiter.o] Error 1
> >
> >
> > The line in question is:
> >
> > dcoef = min(dcoefOld, fl/(maggrad + 1.0D-100))
>
> Apply the attached patch (patch -p0 < r25554.diff in the top directory
> should do it).
>
>
> > It seems to me that min does not like the mixture of two data types:
> > variables *dcoefold*, *fl*, *maggrad* being reals, and a double precision
> > number. I tried converting to and from double precision, and it still
> > yields the same error but up upward in the file at line 162.40, which
> > doesn't include a *min* at all. Gah!
>
>
> It's a problem because different compilers handle the automatic
> propagation of Fortran default REAL to 8-byte REAL differently.
> We could make the problem go away for IBM's XLF compiler by replacing
> all 'D' exponents in real constants by 'E'. But then some other
> compiler complains (for values outside the 4-byte IEEE single
> precision real range).
>
> The approach taken in the patch should work in the maximum number
> of compilers.
>
> Klaus
--
Marissa Adams E-mail:
madams at pas.rochester.edu
PhD Student Ph: (585) 402-5779
University of Rochester Website:
http://www.pas.rochester.edu/~madams/
Department of Physics & Astronomy
108 Bausch & Lomb Hall
P.O. Box 270171
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://flash.rochester.edu/pipermail/flash-users/attachments/20170103/336401f5/attachment.htm>
More information about the flash-users
mailing list