[Wien] memory managment and ifc 8.0

[Ilya Elfimov]

Sorry, actual compiler version is 8.1 build 20040803 Z
To make it consistent with 7.1 I use -FR -fpstkchk -pc80 -mp options.
Optimization can be on or off. This does not affect that part of code.

Ilya
 
-------Original Message-------
 
From: wien at zeus.theochem.tuwien.ac.at
Date: 10/08/04 06:54:04
To: wien at zeus.theochem.tuwien.ac.at
Subject: Re: [Wien] memory managment and ifc 8.0
 
Perhaps the simplest patch -- try ifc 8.1. The Intel documentation says of
8.1 "The primary focus of this release is improvement in compiler
stability and run-time performance". Version 8.1 is more conservative
about some of the optimizations, and I read Intel's statement as meaning
that they've backed off on some overaggressive (buggy) optimizations in
8.0.
 
On Thu, 7 Oct 2004, Ilya Elfimov wrote:
 
> Dear Wien developers and users,
>
>
>
> Did anybody test the code compiled with intel fortran compiler 8.0 on
large
> unit cells?
>
> By large I mean unit cells which do not fit into default parameters. For
> example, in
>
> my test calculation of Cu 111 surface I need KMAX3START to be large than
> ~170 and
>
> default value is 50. Of course one can simply change it and recompile the
> whole program
>
> but this is not interesting. What interesting is that lapw1 will crash in
>
> doreallocate_warp_c16_d2x3 when it is called from setwarts. This is a line
>
> where it happens
>
> hilfsfeld(-n1a:n1a,-n2a:n2a,-n3a:n3a)=tf(-n1a:n1a,-n2a:n2a,-n3a:n3a)
>
> Note that this is ifc 8.0 specific behavior. In 7.1 everything is fine.
>
>
>
> Okay, here is my question. Although I like the idea but is this a legal
use
> of pointers in fortran?
>
> Probably I miss something but hilfsfeld isn't a globally defined pointer
> (like one could have in C)
>
> and therefore the result might depend on how compiler interpret this code.
>
> actually, I mean the whole memory manager. Does anyone know an option
which
> would
>
> make 8.0 to understand this part of code properly?
>
>
>
> If not, does any one have any good idea how to solve this? A quick tweak,
>
> which works, is something like this
>
>           subroutine doreallocate_warp_c16_d2x3(tf, n1a, n1b, n2a, n2b,
n3a,
> n3b)
>
>             implicit none
>
>             complex*16, allocatable, target  :: tmp(:,:,:)
>
>             complex*16, pointer :: tf(:,:,:),ptmp(:,:,:)
>
>             integer ndim
>
>             integer min1, n1a, n1b, n2a, n2b, n3a, n3b
>
>             ndim=(2*n1a+1)*(2*n2a+1)*(2*n3a+1)
>
>             allocate(tmp(-n1a:n1a,-n2a:n2a,-n3a:n3a))
>
>             call zcopy(ndim,tf,1,tmp,1)
>
>             deallocate(tf)
>
>             allocate(tf(-n1b:n1b,-n2b:n2b,-n3b:n3b))
>
>             tf(-n1b:n1b, -n2b:n2b, -n3b:n3b)=(0.0D0,0.0D0)
>
>             ptmp=>tf(-n1a:n1a,-n2a:n2a,-n3a:n3a)
>
>             call zcopy(ndim,tmp,1,ptmp,1)
>
>             deallocate(tmp)
>
>           end subroutine
>
> but it requires double copying and therefore inefficient.
>
>
>
> Thanks,
>
> Ilya
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>
 
-----------------------------------------------
Laurence Marks
Department of Materials Science and Engineering
MSE Rm 2036 Cook Hall
2225 N Campus Drive
Northwestern University
Evanston, IL 60201, USA
Tel: (847) 491-3996 Fax: (847) 491-7820
mailto:L-marks at northwestern.edu
http://www.numis.northwestern.edu
-----------------------------------------------
 
_______________________________________________
Wien mailing list
Wien at zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20041008/22c2701f/attachment.html