Real type issue

[JohnNichols]

I have a problem I have not encountered before that I remember.  mzaMax is determined from an element of vector, but when I try and use it in the DISLIN GRAF routine - the routine wants a real, so I get a compile error of incorrect type. 

DISLIN is not perfect but it is fast.  

Any help appreciated. 

INTEGER, PARAMETER :: dp = selected_real_kind(15, 307)

    integer :: counter
    REAL (KIND=dp) Eig(ndf,ndf), vector(ndf), mza(ndf), mzaMax
    REAL counterMZA


    call getX(eig,ndf)

    call setEigen(ndf, eig, sda, 1, vector, counter, mza, mzaMax, counterMZA)

    CDEV = 'xwin'
    CALL METAFL(CDEV)
    CALL SETPAG('DA4L')

    FPI=PI/180.
    STEP=360./(N-1)

    DO K=1,N
        XRAY(K)=(K-1)*STEP
        X=XRAY(K)*FPI
        Y1RAY(K)=0.1
        Y2RAY(K)=COS(X)
    END DO

    CALL DISINI()
    CALL PAGERA()
    CALL HWFONT()
    CALL AXSPOS(450,1800)
    CALL AXSLEN(2200,1200)

    CALL NAME('X-axis','X')
    CALL NAME('Y-axis','Y')

    CALL LABDIG(-1,'X')
    CALL TICKS(10,'XY')

    CALL TITLIN('Eigenvector Plot ',1)
    CALL TITLIN(SDA(1),3)

    CALL GRAF(0.,counterMZA + 2.0 ,0.,1.0,-mzaMax,mzaMax,-mzaMax,mzaMax/4.0)

[JohnNichols]

I have a problem I have not encountered before that I remember.  mzaMax is determined from an element of vector, but when I try and use it in the DISLIN GRAF routine - the routine wants a real, so I get a compile error of incorrect type.

DISLIN is not perfect but it is fast. 

Any help appreciated.

---------------------------------------------------------------------------

Make a hash of that post

[Steve_Lionel]

I have never used DISLIN, but the documentation for GRAF I can find says that all arguments are "float", that is, single precision. You declare mzaMax as REAL(DP), which is double precision. This won't match. You can convert to single (REAL(value,KIND(0.0))), or do something else appropriate.

[JohnNichols]

Steve:

Thanks - it worked a treat.

John

[Andreas_Z_]

Hi John,

Steve's advice is correct.

Furthermore, if you prefer to keep your double precision floating point number format, you could also link against the respective Dislin libraries, since they exist both in single precision and double precision versions (compare disifl.lib vs. disifl_d.lib) -- (this may also depend on which version you downloaded from the Dislin distribution website).
For example, in Visual Studio, you would link against the dependencies (Linker > Input > Additional Dependencies) "c:\dislin\disifl_d.lib c:\dislin\disifd_d.lib user32.lib gdi32.lib". This is assuming that you installed dislin at that local path on your system. Of course, the extra precision will usually be of little importance on a graphical output, but it may help in reducing the number of conversions between double and single precision in the code.

Andi

[JohnNichols]

Dear Andi:

Thanks for the comment on DISLIN. 

I will move to all double precision it just takes a while to sort out. 

mecej4 helped a lot last year with modernization of the code so I have slowly been moving this whole program in stages to Modern Fortran from the Very Old Fortran of the original Harrison 1973 program. I keep hoping I could do these things in standard FEM programs, but the obstacles are to significant compared to the joy of Intel Fortran. As these programs are used a lot one does not mess with the "current" production version and the types of changes required for modern Fortran usually requires several weeks to debug. It is a lot of fun, but it can be challenging. 

I noticed that when I use DEBUG Multithreaded instead of just plain Multithreaded in the Runtime Library that I start throwing a lot of linker errors with DISLIN say libcore routines duplicated. 

Is there a significant difference in these libraries to generate the errors?

John

[Andreas_Z_]

Hi John,

I use DISLIN with projects both in Debug and Release configurations without the linker errors you describe, including use of DEBUG Multithreaded (/libs:static ...) in Debug configuration vs. Multithreaded in Release mode.
Note that there is also option DEBUG Multithread DLL instead of the static library one, which may issue errors with Dislin, but this is likely not what you need. 

I recall that in the past sometimes there were linker issues with Dislin when there was some overlap with common libraries already present (if used). However, those issues should have been resolved in the recent versions (less than two years old or so) of Dislin with Intel Fortran.

Andi
 

[JohnNichols]

I am using the latest DISLIN - the 2017 VS and the 2018 Intel Fortran on the latest Windows Preview. 

Teh picture shows the setting that throws the errors. 

I just switched it off and the problem went away. 

john