1
votes

I am trying to use REFPROPs HSFLSH subroutine to compute properties for steam.

When the same state property is calculated over multiple iterations
(fixed enthalpy and entropy (Enthalpy = 50000 J/mol & Entropy = 125 J/mol),
the time taken to compute using HSFLSH after every 4th/5th iteration increases to about 0.15 ms against negligible amount of time for other iterations. This is turning problematic because my program places call to this subroutine over several thousand times. Thus leading to abnormally huge program run times.

enter image description here

The program used to generate the above log is here:

 C refprop check
       program time_check
       parameter(ncmax=20)
       dimension x(ncmax)
       real hkj,skj
       character hrf*3, herr*255
       character*255 hf(ncmax),hfmix
 C
 C     SETUP FOR WATER
 C
       nc=1                      !Number of components
       hf(1)='water.fld'      !Fluid name
       hfmix='hmx.bnc'           !Mixture file name
       hrf='DEF'                 !Reference state (DEF means default)
       call setup(nc,hf,hfmix,hrf,ierr,herr)
       if (ierr.ne.0) write (*,*) herr
       call INFO(1,wm,ttp,tnbp,tc,pc,dc,zc,acf,dip,rgas)
       write(*,*) 'Mol weight ', wm
       h = 50000.0
       s = 125.0
 c
 C
       DO I=1,NCMAX
       x(I) = 0
       END DO
 C ******************************************************
 C  THIS IS THE ACTUAL CALL PLACE
 C ******************************************************
       do I=1,100
       call cpu_time(tstrt)
       CALL HSFLSH(h,s,x,T_TEMP,P_TEMP,RHO_TEMP,dl,dv,xliq,xvap,
      &            WET_TEMP,e,
      &            cv,cp,VS_TEMP,ierr,herr)
       call cpu_time(tstop)
       write(*,*),I,'  time taken to run hsflsh routine= ',tstop - tstrt
       end do
       stop
       end

(of course you will need the FORTRAN FILES, which unfortunately I cannot share since REFPROP isn't open source)
Can someone help me figure out why is this happening.?

P.S : The above code was compiled using gfortran -fdefault-real-8

UPDATE
I tried using system_clock to time my computations as suggested by @Ross below. The results are uniform across the loop (image below). I will have to find alternate ways to improve computation speed I guess (Sigh!)

enter image description here

1
Where is implicit none? Make tstart and tstop double precision. - Vladimir F
I compiled using -fdefault-real-8 setting everything to double precision. (Updated likewise) - Ash Sharma
Without others being able to reproduce this I think it's going to be difficult for anyone to offer much help. Have you tried contacting the software customer support? It might be helpful to know what sort of system you're running this on (e.g. how many physical cores available/used, multi-user/single-user machine etc.). - d_1999
@d_1999 Yes I have written to them, thought will check with the community (since REFPROP is widely used) while I wait for their reply. The machine is Windows 7 64 bit, 4 cores, sinlge user. Also gfortran from MinGW. - Ash Sharma
Is this at all sensitive to the timing method? It wouldn't surprise me if 15 us is the smallest time resolvable by CPU_TIME. Would it be different if you used a system_clock? - Ross

1 Answers

1
votes

I don't have a concrete answer, but this sort of behaviour looks like what I would expect if all calls really took around 3 ms, but your call to CPU_TIME doesn't register anything below around 15 ms. Do you see any output with time taken less than, say 10 ms? Of particular interest to me is the approximately even spacing between calls that return nonzero time - it's about even at 5.

CPU timing can be a tricky business. I recommended in a comment that you try system_clock, which can be higher precision than CPU_TIME. You said it doesn't work, but I'm unconvinced. Did you pass a long integer to system_clock? What was the count_rate for your system? Were all the times still either 15 or 0 ms?