> Michael wrote:

>> On May 1, 9:28 am, Michael comcast.net> wrote:

>

>> With some additional debug info turned on, this is what we get,

>

>> forrtl: severe (157): Program Exception - access violation
>> Image              PC        Routine            Line        Source
>> ntdll.dll          7C911E58  Unknown               Unknown  Unknown
>> ntdll.dll          7C918251  Unknown               Unknown  Unknown
>> ntdll.dll          7C911C76  Unknown               Unknown  Unknown
>> lodi.exe           00AC0716  Unknown               Unknown  Unknown
>> lodi.exe           00A55481  Unknown               Unknown  Unknown
>> lodi.exe           0056AFB0  _GRIDS_mp_ALLOCAT         283  grids.f90
>> lodi.exe           0056CCF2  _GRIDS_mp_READ_GR         569  grids.f90
>> lodi.exe           007950E7  _LODI_MOD_mp_LODI        4013
>> lodi_mod.f90
>> lodi.exe           0093D879  _MAIN__                    39
>> lodi_main.f90
>> lodi.exe           00AF33DD  Unknown               Unknown  Unknown
>> lodi.exe           00AC02CB  Unknown               Unknown  Unknown
>> kernel32.dll       7C816FD7  Unknown               Unknown  Unknown

>

>> I don't know if this is helpful in diagnosing the issue apart from
>> what has already been traced in the known source code?

>

>>> On May 1, 9:15 am, Michael comcast.net> wrote:

>

>>> I tried /heap-arrays and /Fn options, and this is still yielding a
>>> failing allocate result.

>

>>>> On Apr 30, 6:48 pm, Steve Lionel wrote:
>>>> Thanks. And yessir, even with /traceback (already on) and /
>>>> check:pointer, still failing at run-time.
>>>> Declared as an allocatable,
>>>>      if (not(allocated(grid_dat%%zg))) then
>>>>         write(*, '(/1x, "ALLOCATE_GRID: grid coordinates, allocating
>>>> grid_dat%%zg")')
>>>>         allocate(grid_dat%%zg(idim, jdim), stat = allocerr)
>>>>         if (allocerr /= 0) stop 3
>>>>      endif
>>>> Or as a pointer,
>>>>      if (size(grid_dat%%zg)==0) then

>
> This probably isn't the problem, but you (probably) can't do this.  The
> only way that size(grid_dat%%zg) would be zero is if you previously
> allocated it to size zero or pointed it to something of size
> zero.  It doesn't start out with zero size, nor does deallocating
> it give it a zero size.  Also, pointers start out in an undefined
> status.  You can specifically initialize them, but my recollection
> is that you didn't do that in the snippets you showed.
>
> You could try default initialization for your pointers by
> putting something like
>          real,pointer,whateverelse  ::  zg => null()
> in you type definitions.
>
> Then use the associated(grid_dat%%zg), rather than size, to see
> if the pointer is associated with something or not.  Using default
> initialization has the advantage that all of your type internal
> pointers will start out in a known state.
>
> It's an interesting opportunity in Fortran that there is no
> way to tell if a pointer is in an "undefined" state.  You
> just have to keep track and not reference it if it is in an
> undefined state.  If its status is defined, you can tell if
> it is associated or not.
>
> Dick Hendrickson
>
>
>

>>>>         write(*, '(/1x, "ALLOCATE_GRID: grid coordinates, allocating
>>>> grid_dat%%zg")')
>>>>         allocate(grid_dat%%zg(idim, jdim), stat = allocerr)
>>>>         if (allocerr /= 0) stop 3
>>>>      endif
>>>> Regardless, allocate is failing with the following command line
>>>> feedback,
>>>> forrtl: severe (157): Program Exception - access violation
>>>> Image              PC        Routine            Line        Source
>>>> ntdll.dll          7C911E58  Unknown               Unknown  Unknown
>>>> ntdll.dll          7C918251  Unknown               Unknown  Unknown
>>>> ntdll.dll          7C911C76  Unknown               Unknown  Unknown
>>>> lodi.exe           00B1C521  Unknown               Unknown  Unknown
>>>> Which has to do with something like RtlInitializeCriticalSection(),
>>>> deep within NTDLL.DLL. Not especially productive (i.e. no resolution
>>>> to the issue) here, however thanks all for the insight, really and
>>>> truly. Next place to go appears to be into the Intel Fortran forums.
>>>> That said, I can't say this doesn't have something to do with a
>>>> programmatic issue elsewhere in the code. That's entirely possible
>>>> (i.e. scientists having written the code before we inherited it).
>>>> Nothing against scientists, mind you, but there's something to be said
>>>> about a professional developer's awareness of memory management
>>>> issues.
>>>> Anywho... Neither here nor there, apart from the fact we've got to get
>>>> through the consequences of said issues, of course...

>>>>> Michael wrote:

>>>>>> After taking out the stat from allocate, we get further, but we still
>>>>>> end up failing, same place in NTDLL.DLL.

>>>>> No, you're failing in your application.  Try adding /traceback to the
>>>>> set of options, so you get more detailed information, and you might also
>>>>> try /check:pointer.
>>>>> If you need more help, post in the Intel Fortran user forum or contact
>>>>> Intel support (links below).
>>>>> I am not aware of any bugs related to ALLOCATABLE in the version you are
>>>>> using.
>>>>> --
>>>>> Steve Lionel
>>>>> Developer Products Division
>>>>> Intel Corporation
>>>>> Nashua, NH
>>>>> For email address, replace "invalid" with "com"
>>>>> User communities for Intel Software Development Products
>>>>>    http://softwareforums.intel.com/
>>>>> Intel Fortran Support
>>>>>    http://support.intel.com/support/performancetools/fortran
>>>>> My Fortran blog
>>>>>    http://www.intel.com/software/drfortran-Hidequoted text -

>>>> - Show quoted text -- Hide quoted text -

>>> - Show quoted text -- Hide quoted text -

>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -