Comp.lang.fortran Group Discussion

Hello,

I’m somewhat new to Fortran, so this is partly tutorial as well as
troubleshooting. Consider: we have a derived type looking something
like the following.

type grid
real(kind = rkind), pointer :: x(:)
real(kind = rkind), pointer :: y(:)
real(kind = rkind), pointer :: sigmaz(:)
real(kind = rkind), allocatable :: zg(:,:)
end type grid

We then declare a couple of variables using this as the type.

type (grid), allocatable, target, dimension(:) :: m_grid
type (grid), target :: c_grid

m_grid ends up being of a single dimension. On the other hand, c_grid
doesn’t appear to be allocated anywhere.

We pass the each grid through a couple of functions as a parameter
looking like the following,

type (grid), intent(out) :: grid_dat

On 30 avr, 23:05, Michael comcast.net> wrote:

Michael wrote:

In reference to the questions asked,

Compiler Version: Intel(R) Fortran Compiler Integration for Microsoft
Visual Studio 2005, 10.1.3885.2005, Copyright (C) 2002-2007 Intel
Corporation

Yessir, I'm sure of the idim and jdim values; placed write statements
throughout in an effort to identify the nature of the issue.

In reference to the questions asked,

Compiler Version: Intel(R) Fortran Compiler Integration for Microsoft
Visual Studio 2005, 10.1.3885.2005, Copyright (C) 2002-2007 Intel
Corporation

Yessir, I'm sure of the idim and jdim values; placed write statements
throughout in an effort to identify the nature of the issue.

I'll try taking the stat out of the allocate statement. Without this,
this is producing what look like better results, at least initially,
in the sense that we're allocating something. Am I to read, then, "the
compiler sometimes provides clear diagnostics", that it cannot always
do this? In fact, sometimes this is problematic? Especially from a
portability standpoint where code might operate well in Linux and not
in Windows?

Michael comcast.net> wrote:

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

Here's an output from the log reporting the resulting sizes.

ALLOCATE_GRID: grid coordinates, idim = 141
jdim = 141
kdim = 20
idim*jdim= 19881

ALLOCATE_GRID: grid coordinates, size(grid_dat%%x) = 141
size(grid_dat%%y) = 141
size(grid_dat%%sigmaz)= 20
size(grid_dat%%zg) = 19881

ALLOCATE_GRID: grid coordinates, size(grid_dat%%delta_x)= 140
size(grid_dat%%delta_y)= 140
size(grid_dat%%delta_z)= 372400

And then we fail allocating another ~19881.

We're working with pointers here, not allocatables per se, defined in
a derived type, so I couldn't perform checks on allocated(). Some
limitation of component derived types, or something like this. I'll
try deallocating just in case to see if that helps.

On Apr 30, 5:25 pm, Michael comcast.net> wrote:

Definitely deallocated. As soon as we attempt to deallocate, we see a
run-time error.

Michael comcast.net> wrote:

You said that the problem was with the sg component, which your
derived-type definition shows as allocatable, not pointer. That's
exactly what my comment was based on.

On Apr 30, 5:38 pm, nos...@see.signature (Richard Maine) wrote:

My apologies, that was my mistake. It should be pointer in the
original code, before we inherited responsibilityh for it.

Michael wrote:

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"