Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28446 Discussions

GetOpenFileName gives error in virtual memory

Nata_pri
Novice
2,679 Views

Dear Colleagues! Please help me overcome the problem. As soon as I turn to the GetOpenFileName program, an error "forrtl: severe (41): usufficiant virtual memory" immediately occurs when opening the test file "test.dat". does not work on all versions of compilers (11,18,19). I would be grateful for your help!

program fileopenroot
use nozspe
call initarrs
end 
subroutine fileopen(file_spec,ilen)

use comdlg32
use user32 
implicit none
character(512) :: file_spec
integer ilen
type(T_OPENFILENAME) ofn
integer*4 NFOBR,status
integer*4 in1
character(*),parameter :: filter_spec = &
  "Text Files"C//"*.dat"C// &
  "Fortran Files"C//"*.dat;"C
character*512   OIFIL
ofn%lStructSize = SIZEOF(ofn)
ofn%hwndOwner = GetForegroundWindow()
ofn%hInstance = NULL  ! For Win32 applications, you
                      ! can set this to the appropriate
                      ! hInstance
                      !
ofn%lpstrFilter = loc(filter_spec)
ofn%lpstrCustomFilter = NULL
ofn%nMaxCustFilter = 0
ofn%nFilterIndex = 1 ! Specifies initial filter value
ofn%lpstrFile = loc(file_spec)
ofn%nMaxFile = sizeof(file_spec)
ofn%nMaxFileTitle = 0
ofn%lpstrInitialDir = NULL  ! Use Windows default directory
ofn%lpstrTitle = loc(""C)
ofn%Flags = OFN_PATHMUSTEXIST
ofn%lpstrDefExt = loc("txt"C)
ofn%lpfnHook = NULL
ofn%lpTemplateName = NULL

status = GetOpenFileName(ofn)

if (status .eq. 0) then
  type *,'No file name specified'
else
  ilen = INDEX(file_spec,CHAR(0))
  type *,'Filespec is ',file_spec(1:ilen-1)
  if (IAND(ofn%flags,OFN_READONLY) /= 0) &
    type *,'Readonly was requested'
  end if
  NFOBR=58
         OIFIL="d:/test.dat"C
        in1=108000000
        OPEN(NFOBR,FILE=trim(OIFIL),STATUS='unknown',ACCESS='DIRECT',RECL=in1,FORM='UNFORMATTED',SHARED)
        WRITE(NFOBR,REC=1) IN1
        CLOSE(NFOBR)
        OPEN(NFOBR,FILE=trim(OIFIL),STATUS='unknown',ACCESS='DIRECT',RECL=in1,FORM='UNFORMATTED',SHARED)
        READ(NFOBR,REC=1) IN1
        CLOSE(NFOBR)
return
end 
          subroutine InitArrs
           use nozspe
           character*512 :: file_spec = ""C
           integer*4 ilen
           allocate (ASHM(Ndim1D),ASHN(Ndim1D),SHM(Ndim1D),SHN(Ndim1D),AASHM(Ndim1D+1),AASHN(Ndim1D+1))
           allocate (D(ndimB),P(ndimB),T(ndimB),E(ndimB),WM(ndimB),WN(ndimB),TMPARR((ndimB+Ndim1D)*2),TMPARR2((ndimB+Ndim1D)*2))
           allocate (DFUEL(ndimB))
           allocate (EP1(ndimB))
           allocate (ASHL(Ndim1D),VLine(Ndim1D*20),DENS(ndimB))
           allocate (ninfpl(ndimB),ninf(ndimB))
           allocate (NWaveV(Ndim1D),ovol(ndimB),OWaveV(Ndim1D))
           call fileopen(file_spec,ilen)
           return
          end
      
      module nozspe
      IMPLICIT REAL*8 (A-H,P-Z), LOGICAL*1 (O)
      INTEGER,parameter :: ndim=3000,LdimB=3000,ndimB=10000000
      INTEGER,parameter :: Ndim1D=10001
	  real(8), allocatable, dimension(:):: ASHM,ASHN,SHM,SHN,AASHM,AASHN,D
      real(8), allocatable, dimension(:):: P,T,E,WM,WN,TMPARR
      real(8), allocatable, dimension(:):: DFUEL,TMPARR2,EP1,ASHL
      real(8), allocatable, dimension(:):: VLine,DENS
      integer, allocatable, dimension(:):: NWaveV,ninfpl,ninf
      logical(1), allocatable, dimension(:):: ovol,OWaveV
      end module nozspe

  

Nata_pri_0-1594850470718.png

 

0 Kudos
1 Solution
Steve_Lionel
Honored Contributor III
2,611 Views

I think that for your particular system, that 400KB allocation is right on the edge of what your system can handle, and calling GetOpenFileName caused Windows to allocate some more, pushing you over the edge. On my PC, it made no difference - it failed either way.

Do you really need a RECL that long? What exactly are you trying to do here?  I agree that Xeffort is not yet 64-bit ready (and may never be.)

View solution in original post

25 Replies
Steve_Lionel
Honored Contributor III
2,612 Views

I think that for your particular system, that 400KB allocation is right on the edge of what your system can handle, and calling GetOpenFileName caused Windows to allocate some more, pushing you over the edge. On my PC, it made no difference - it failed either way.

Do you really need a RECL that long? What exactly are you trying to do here?  I agree that Xeffort is not yet 64-bit ready (and may never be.)

Nata_pri
Novice
593 Views

Arrays for visualizing the results of numerical simulations, each 10 million cells (3D modelling). With direct access for fast reading.

0 Kudos
Steve_Lionel
Honored Contributor III
587 Views

I might suggest instead a memory-mapped file. A bit more work on your part, but very efficient. https://docs.microsoft.com/en-us/windows/win32/memory/memory-management-functions#file-mapping-functions

GVautier
New Contributor II
581 Views

There is no miracle, if you want speed, you need memory.

So if you cannot upgrade to X64 environment, you will probably not be able to got enough memory to reach your goal in term of speed unless you adapt your algorithm to the memory shortage.

 

0 Kudos
Nata_pri
Novice
848 Views

P.S. The error occur at the first operator 

OPEN(NFOBR,FILE=trim(OIFIL),STATUS='unknown',ACCESS='DIRECT',RECL=in1,FORM='UNFORMATTED',SHARED)

0 Kudos
Reply