|
|
 |
 |
 |
 |
Fortran Programming Language
|
 |
 |
 |
 |
 |
 |
 |
 |
Two problems
Main problem - I have a fortran CVF code that I run on two Intel machines on windows platform - one a 32 bit and other a 64 bit workstation. I develop and compile the code in the 32 bit platform, and just use the 64 bit workstation to run it. Normally this works fine, but starting today, I am always getting a run-time error (sqrt error) when I am trying to run the executable from command prompt. Second problem - I have also an IVF compiler on the 64 bit machine. When I port the project from CVF, and build the solution in IVF (changing it to x64 platform to seek performance improvement), and try to execute it, I get a memory error at a subroutine like this - (ALLOC_ERR=1332). This does not ocur in the CVF version. There, in the Project properties, I had added the stack size as /stack:0xfffffff. What should I be doing in the IVF? More importantly though, why is the exectauble running in a 32 bit environment, but crashing on this x64 machine - I thought Windows x64 was backward compatible - and handles all programs that run on 32 bit environment. Is this not the case? COMPLEX*16, DIMENSION(:,:), ALLOCATABLE:: TA,TB IF (.NOT.(ALLOCATED(TA))) ALLOCATE(TA(NEig,NEig)) IF (ALLOC_ERR .ne. 0) PRINT *, 'Error in allocating TA : TB_Basis' Thanks. Basu.
Let me add - Even if the 32 bit m/c, where I develop the prog, I am able to run the project from Developer Studio, but on trying to execute the .exe file with same set of parameter files from a command prompt, the program crashes with a run-time error from Math error as in the x64 m/c. How / why can't I run the exe from a command prompt if CVF is able to run it ? On Apr 23, 11:21 pm, basu wrote:
> Main problem - > I have a fortran CVF code that I run on two Intel machines on windows > platform - one a 32 bit and other a 64 bit workstation. I develop and > compile the code in the 32 bit platform, and just use the 64 bit > workstation to run it. > Normally this works fine, but starting today, I am always getting a > run-time error (sqrt error) when I am trying to run the executable > from command prompt. > Second problem - > I have also an IVF compiler on the 64 bit machine. When I port the > project from CVF, and build the solution in IVF (changing it to x64 > platform to seek performance improvement), and try to execute it, I > get a memory error at a subroutine like this - (ALLOC_ERR=1332). This > does not ocur in the CVF version. There, in the Project properties, I > had added the stack size as /stack:0xfffffff. What should I be doing > in the IVF? > More importantly though, why is the exectauble running in a 32 bit > environment, but crashing on this x64 machine - I thought Windows x64 > was backward compatible - and handles all programs that run on 32 bit > environment. Is this not the case? > COMPLEX*16, DIMENSION(:,:), ALLOCATABLE:: TA,TB > IF (.NOT.(ALLOCATED(TA))) ALLOCATE(TA(NEig,NEig)) > IF (ALLOC_ERR .ne. 0) PRINT *, 'Error in allocating TA : TB_Basis' > Thanks. > Basu.
Moreover, I find that the crash occurs at different points depending on what parameters I put in to the simulation - this is a electronic device simulator that i am trying to excute - when i change the transport conditions, it sometimes gives me an array bounds exceeded - error. However, for these same set of parameters, the program runs fine from CVF environment. What can I do to make sure that the standalone executable runs as good as from the development IDE? Thanks for any help. On Apr 23, 11:46 pm, basu wrote:
> Let me add - > Even if the 32 bit m/c, where I develop the prog, I am able to run the > project from Developer Studio, but on trying to execute the .exe file > with same set of parameter files from a command prompt, the program > crashes with a run-time error from Math error as in the x64 m/c. > How / why can't I run the exe from a command prompt if CVF is able to > run it ? > On Apr 23, 11:21 pm, basu wrote: > > Main problem - > > I have a fortran CVF code that I run on two Intel machines on windows > > platform - one a 32 bit and other a 64 bit workstation. I develop and > > compile the code in the 32 bit platform, and just use the 64 bit > > workstation to run it. > > Normally this works fine, but starting today, I am always getting a > > run-time error (sqrt error) when I am trying to run the executable > > from command prompt. > > Second problem - > > I have also an IVF compiler on the 64 bit machine. When I port the > > project from CVF, and build the solution in IVF (changing it to x64 > > platform to seek performance improvement), and try to execute it, I > > get a memory error at a subroutine like this - (ALLOC_ERR=1332). This > > does not ocur in the CVF version. There, in the Project properties, I > > had added the stack size as /stack:0xfffffff. What should I be doing > > in the IVF? > > More importantly though, why is the exectauble running in a 32 bit > > environment, but crashing on this x64 machine - I thought Windows x64 > > was backward compatible - and handles all programs that run on 32 bit > > environment. Is this not the case? > > COMPLEX*16, DIMENSION(:,:), ALLOCATABLE:: TA,TB > > IF (.NOT.(ALLOCATED(TA))) ALLOCATE(TA(NEig,NEig)) > > IF (ALLOC_ERR .ne. 0) PRINT *, 'Error in allocating TA : TB_Basis' > > Thanks. > > Basu.- Hide quoted text - >
basu wrote: > I have also an IVF compiler on the 64 bit machine. When I port the > project from CVF, and build the solution in IVF (changing it to x64 > platform to seek performance improvement), and try to execute it, I > get a memory error at a subroutine like this - (ALLOC_ERR=1332). This > does not ocur in the CVF version. There, in the Project properties, I > had added the stack size as /stack:0xfffffff. What should I be doing > in the IVF?
/link /stack options have not changed. Of course, the required numerical values could change, but we can't predict that from this distance.
Check: Can you execute the code with a few entry parameters on CVF (I hope 6.6c) under the Development Studio? Can you link this same code and get an executable which will run with the same parametrs input? -if not you have a link problem which may be the same cause on the IVF attempts. If you pass this point, can you compile and run the UNCHANGED code on IVF (and use the same parameters to test)? If you pass this point then there is a problem in the changes you made to the source to go X64.
As if by magic, basu appeared !
> Second problem - > I have also an IVF compiler on the 64 bit machine. When I port the > project from CVF, and build the solution in IVF (changing it to x64 > platform to seek performance improvement), and try to execute it, I > get a memory error at a subroutine like this - (ALLOC_ERR=1332). This > does not ocur in the CVF version. There, in the Project properties, I > had added the stack size as /stack:0xfffffff. What should I be doing > in the IVF? > More importantly though, why is the exectauble running in a 32 bit > environment, but crashing on this x64 machine - I thought Windows x64 > was backward compatible - and handles all programs that run on 32 bit > environment. Is this not the case? > COMPLEX*16, DIMENSION(:,:), ALLOCATABLE:: TA,TB > IF (.NOT.(ALLOCATED(TA))) ALLOCATE(TA(NEig,NEig)) > IF (ALLOC_ERR .ne. 0) PRINT *, 'Error in allocating TA : TB_Basis'
Where is alloc_err set ? Ian
On Apr 24, 12:21 am, basu <dipanjan.b@gmail.com> wrote: > Main problem - > I have a fortran CVF code that I run on two Intel machines on windows > platform - one a 32 bit and other a 64 bit workstation. I develop and > compile the code in the 32 bit platform, and just use the 64 bit > workstation to run it. > Normally this works fine, but starting today, I am always getting a > run-time error (sqrt error) when I am trying to run the executable > from command prompt.
There's not enough information here to understand the problem. Please submit an issue to Intel Premier Support and attach a ZIP of your project(s), including all sources and instructions for how to reproduce the problem. Steve Lionel Developer Products Division Intel Corporation Nashua, NH User communities for Intel Software Development Products http://softwareforums.intel.com/ Intel Fortran Support http://developer.intel.com/software/products/support/ My Fortran blog http://www.intel.com/software/drfortran
basu wrote: > Main problem - > I have a fortran CVF code that I run on two Intel machines on windows > platform - one a 32 bit and other a 64 bit workstation. I develop and > compile the code in the 32 bit platform, and just use the 64 bit > workstation to run it. > Normally this works fine, but starting today, I am always getting a > run-time error (sqrt error) when I am trying to run the executable > from command prompt.
Almost invariably when program execution changes when you run under different circumstances, you've got one or more uninitialized variables. In one case they are (magically) set to zero or some other harmless value. In the other they are set to some harmful value. This is likely to happen to variables that live on the stack; sometimes the stack area is cleared to zero, sometimes it isn't. Try compiling with all of the run-time error checking you can find enabled and turn on all of the compile time warnings you can. Dick Hendrickson
> Second problem - > I have also an IVF compiler on the 64 bit machine. When I port the > project from CVF, and build the solution in IVF (changing it to x64 > platform to seek performance improvement), and try to execute it, I > get a memory error at a subroutine like this - (ALLOC_ERR=1332). This > does not ocur in the CVF version. There, in the Project properties, I > had added the stack size as /stack:0xfffffff. What should I be doing > in the IVF? > More importantly though, why is the exectauble running in a 32 bit > environment, but crashing on this x64 machine - I thought Windows x64 > was backward compatible - and handles all programs that run on 32 bit > environment. Is this not the case? > COMPLEX*16, DIMENSION(:,:), ALLOCATABLE:: TA,TB > IF (.NOT.(ALLOCATED(TA))) ALLOCATE(TA(NEig,NEig)) > IF (ALLOC_ERR .ne. 0) PRINT *, 'Error in allocating TA : TB_Basis' > Thanks. > Basu.
On Apr 24, 6:39 am, Terence <tbwri@cantv.net> wrote: > Check: > Can you execute the code with a few entry parameters on CVF (I hope > 6.6c) under the Development Studio? > Can you link this same code and get an executable which will run with > the same parametrs input? > -if not you have a link problem which may be the same cause on the > IVF attempts. > If you pass this point, can you compile and run the UNCHANGED code on > IVF (and use the same parameters to test)? > If you pass this point then there is a problem in the changes you made > to the source to go X64.
My CVF is 6.5, but I don't understand what you mean by 'few entry parameters'. I have some input files, fromwhich it reads in parameters. The parameters are read correctly in the command prompt as well, as I can check from the screen output. As I said, I can compile, link and create an executable - and then run the executable from CVF IDE. But the moment I go to command prompt, in the same machine, with the same input parameters (as read from file), it crashes. The point where it crashes is variable - sometimes it is a math error, sometimes array out of bounds(allocation fail - i suppose, but i check for the status field in all the allocations, they aren't set, as then i would see my custom message).
Can you elaborate what you mean by few entry parameters? I am using some parameters all of which are read from some input files. They are read all right, in both command propt executionas well as execution from IDE, as I can see their values from the screen output. The file is compiled, linked and exceuted all in the IDE and that works good. Howver the executable made this way crashes in the command prompt. On Apr 24, 6:39 am, Terence <tbwri@cantv.net> wrote:
> Check: > Can you execute the code with a few entry parameters on CVF (I hope > 6.6c) under the Development Studio? > Can you link this same code and get an executable which will run with > the same parametrs input? > -if not you have a link problem which may be the same cause on the > IVF attempts. > If you pass this point, can you compile and run the UNCHANGED code on > IVF (and use the same parameters to test)? > If you pass this point then there is a problem in the changes you made > to the source to go X64.
Dick Hendrickson wrote: > basu wrote: >> Main problem - >> I have a fortran CVF code that I run on two Intel machines on windows >> platform - one a 32 bit and other a 64 bit workstation. I develop and >> compile the code in the 32 bit platform, and just use the 64 bit >> workstation to run it. >> Normally this works fine, but starting today, I am always getting a >> run-time error (sqrt error) when I am trying to run the executable >> from command prompt. > Almost invariably when program execution changes when you run under > different circumstances, you've got one or more uninitialized > variables.
ALLOC_ERR?
"basu" <dipanjan.b @gmail.com> wrote in message news:1177441845.101883.280150@s33g2000prh.googlegroups.com... <snip> > The point where it crashes is variable - sometimes it is a math error, > sometimes array out of bounds(allocation fail - i suppose, but i check > for the status field in all the allocations, they aren't set, as then > i would see my custom message).
Note : Since you state that you test for an allocation failure, then "array out of bounds" may simply be just that. You appear to have a subscript with a value outside the lower or upper bound of the array. Uninitialised variables could cause this, and/or the math error, depending on the memory contents of those variable(s) at run time. Les
"basu" <dipanjan.b @gmail.com> wrote in message news:1177388466.530957.200190@p77g2000hsh.googlegroups.com... > COMPLEX*16, DIMENSION(:,:), ALLOCATABLE:: TA,TB > IF (.NOT.(ALLOCATED(TA))) ALLOCATE(TA(NEig,NEig)) > IF (ALLOC_ERR .ne. 0) PRINT *, 'Error in allocating TA : TB_Basis'
should be COMPLEX*16, DIMENSION(:,:), ALLOCATABLE:: TA,TB integer :: ALLOC_ERR = 0 IF (.NOT.(ALLOCATED(TA))) ALLOCATE(TA(NEig,NEig), stat=ALLOC_ERR ) IF (ALLOC_ERR .ne. 0) PRINT *, 'Error in allocating TA : TB_Basis' Regards, Mike Metcalf
So running under debug in CVF 6.5 under Development Studio works. In the same environment you can now choose to produce a RELEASE version, which you can execute while still in the Development studio. See if this works. If it does, copy the execute file out to antoher directory and double- click on it. If this DOESn't work you may have a stack problem which I have found occurs if your computer is W2000 or XP and has been updated by Microsoft patches on-line. But I would expect the run to abort, not to run and give unexpected results - which is more likely to be caused by incomplete initialization of variables.
Thanks Dick, this makes good sense to me. I have plenty of uninitialised variables that I really should be clearing to zero value, but every time I debug in the IDE, I see them set to 1e-26, and I thought - whoa, I don't need a statement clearing the variable values. I realize that can be a source of error. I will look into this. Btw, is there some smart way to set huge arrays to 0. I presently just use variable=0.0 (something like clear variable?) -Basu On Apr 24, 10:51 am, Dick Hendrickson <> wrote:
> basu wrote: > > Main problem - > > I have a fortran CVF code that I run on two Intel machines on windows > > platform - one a 32 bit and other a 64 bit workstation. I develop and > > compile the code in the 32 bit platform, and just use the 64 bit > > workstation to run it. > > Normally this works fine, but starting today, I am always getting a > > run-time error (sqrt error) when I am trying to run the executable > > from command prompt. > Almost invariably when program execution changes when you run under > different circumstances, you've got one or more uninitialized > variables. In one case they are (magically) set to zero or some other > harmless value. In the other they are set to some harmful value. > This is likely to happen to variables that live on the stack; > sometimes the stack area is cleared to zero, sometimes it isn't. > Try compiling with all of the run-time error checking you can find > enabled and turn on all of the compile time warnings you can. > Dick Hendrickson > > Second problem - > > I have also an IVF compiler on the 64 bit machine. When I port the > > project from CVF, and build the solution in IVF (changing it to x64 > > platform to seek performance improvement), and try to execute it, I > > get a memory error at a subroutine like this - (ALLOC_ERR=1332). This > > does not ocur in the CVF version. There, in the Project properties, I > > had added the stack size as /stack:0xfffffff. What should I be doing > > in the IVF? > > More importantly though, why is the exectauble running in a 32 bit > > environment, but crashing on this x64 machine - I thought Windows x64 > > was backward compatible - and handles all programs that run on 32 bit > > environment. Is this not the case? > > COMPLEX*16, DIMENSION(:,:), ALLOCATABLE:: TA,TB > > IF (.NOT.(ALLOCATED(TA))) ALLOCATE(TA(NEig,NEig)) > > IF (ALLOC_ERR .ne. 0) PRINT *, 'Error in allocating TA : TB_Basis' > > Thanks. > > Basu.- Hide quoted text - >
"basu" <dipanjan.b @gmail.com> wrote in message news:1177555358.354725.41150@c18g2000prb.googlegroups.com... > Thanks Dick, this makes good sense to me. I have plenty of > uninitialised variables that I really should be clearing to zero > value, but every time I debug in the IDE, I see them set to 1e-26, and > I thought - whoa, I don't need a statement clearing the variable > values. I realize that can be a source of error. I will look into > this. > Btw, is there some smart way to set huge arrays to 0. I presently just > use variable=0.0 (something like clear variable?)
Yours is the smart way. You can be more specific about the kind, but variable=0.0 is a remarkably flexible statement.
> -Basu > On Apr 24, 10:51 am, Dick Hendrickson <> wrote: >> basu wrote: >> > Main problem - >> > I have a fortran CVF code that I run on two Intel machines on windows >> > platform - one a 32 bit and other a 64 bit workstation. I develop and >> > compile the code in the 32 bit platform, and just use the 64 bit >> > workstation to run it. >> > Normally this works fine, but starting today, I am always getting a >> > run-time error (sqrt error) when I am trying to run the executable >> > from command prompt. >> Almost invariably when program execution changes when you run under >> different circumstances, you've got one or more uninitialized >> variables. In one case they are (magically) set to zero or some other >> harmless value. In the other they are set to some harmful value. >> This is likely to happen to variables that live on the stack; >> sometimes the stack area is cleared to zero, sometimes it isn't. >> Try compiling with all of the run-time error checking you can find >> enabled and turn on all of the compile time warnings you can. >> Dick Hendrickson >> > Second problem - >> > I have also an IVF compiler on the 64 bit machine. When I port the >> > project from CVF, and build the solution in IVF (changing it to x64 >> > platform to seek performance improvement), and try to execute it, I >> > get a memory error at a subroutine like this - (ALLOC_ERR=1332). This >> > does not ocur in the CVF version. There, in the Project properties, I >> > had added the stack size as /stack:0xfffffff. What should I be doing >> > in the IVF? >> > More importantly though, why is the exectauble running in a 32 bit >> > environment, but crashing on this x64 machine - I thought Windows x64 >> > was backward compatible - and handles all programs that run on 32 bit >> > environment. Is this not the case? >> > COMPLEX*16, DIMENSION(:,:), ALLOCATABLE:: TA,TB >> > IF (.NOT.(ALLOCATED(TA))) ALLOCATE(TA(NEig,NEig)) >> > IF (ALLOC_ERR .ne. 0) PRINT *, 'Error in allocating TA : TB_Basis' >> > Thanks. >> > Basu.- Hide quoted text - >>
It makes me grumpy to see the google portal misused. Thanks for stopping by, Basu! -- WW
Mike, how does this improve the code? Should not the flag alloc_err touched whether allocation is succesful or not? Also, I ran into a problem with ALLOCATED - DEALLOCATE today. Inside a subroutine, I have several allocatables that I allocate in the way given below - COMPLEX*16, DIMENSION(:,:), ALLOCATABLE:: Var1,Var2 IF(.NOT.(ALLOCATED(Var1)) ) ALLOCATE(Var1) do computation IF(ALLOCATE(var1)) DEALLOCATE(var1) The program crashes when trying to deallocate one of the allocatable variables. I checked that at the beginning of the suroutine, every allocatable is an uninitialised pointer/array status (in CVF 6.5 debugger), and ALLOCATED(var1) returns .false. However, even after a succesful allocation, (which I can tell since the status of the flag alloc_err is 0, and that i can access the elements in the array, and do work on them), the value of "ALLOCATED(Var1) remains 0". I found users reporting similar issues in earlier threads, but reading those, i could not get a clear solution/fix to the problem. I should add that I would like to stay with allocatables (i.e., avoid pointers). Since I was explicitly deallocating the memories only at the end of the subroutine, and fortran would have done so automatically as soon as I exit the subroutine, so in principle I could get away with the problem by taking away the offending DEALLOCATE statement(s). However, that does not work. I still get "Access Violation". Do you have any suggestions? Thanks, Basu. On Apr 25, 6:48 am, "Michael Metcalf" <michaelmetc@compuserve.com> wrote:
> "basu" <dipanjan.b @gmail.com> wrote in message > news:1177388466.530957.200190@p77g2000hsh.googlegroups.com... > > COMPLEX*16, DIMENSION(:,:), ALLOCATABLE:: TA,TB > > IF (.NOT.(ALLOCATED(TA))) ALLOCATE(TA(NEig,NEig)) > > IF (ALLOC_ERR .ne. 0) PRINT *, 'Error in allocating TA : TB_Basis' > should be > COMPLEX*16, DIMENSION(:,:), ALLOCATABLE:: TA,TB > integer :: ALLOC_ERR = 0 > IF (.NOT.(ALLOCATED(TA))) ALLOCATE(TA(NEig,NEig), stat=ALLOC_ERR ) > IF (ALLOC_ERR .ne. 0) PRINT *, 'Error in allocating TA : TB_Basis' > Regards, > Mike Metcalf
As if by magic, basu appeared ! > Mike, how does this improve the code? Should not the flag alloc_err > touched whether allocation is succesful or not?
No ! In the code you posted ALLOC_ERR will never be set, only read, and so anything can happen. You need to use the STAT clause on the allocate statement to set it, and further because of your use of the ALLOCATED intrinsic in this fashion you have to be extra careful that you have initialized alloc_err before hand. Mike's code achieves all of this. > Also, I ran into a problem with ALLOCATED - DEALLOCATE today. Inside a > subroutine, I have several allocatables that I allocate in the way > given below - > COMPLEX*16, DIMENSION(:,:), ALLOCATABLE:: Var1,Var2 > IF(.NOT.(ALLOCATED(Var1)) ) ALLOCATE(Var1) > do computation > IF(ALLOCATE(var1)) DEALLOCATE(var1)
This won't compile - I assume you mean ALLOCATED in the above line. > The program crashes when trying to deallocate one of the allocatable > variables. I checked that at the beginning of the suroutine, every > allocatable is an uninitialised pointer/array status (in CVF 6.5 > debugger), and ALLOCATED(var1) returns .false. However, even after a > succesful allocation, (which I can tell since the status of the flag > alloc_err is 0,
This means nothing as you never set ALLOC_ERR. > and that i can access the elements in the array, and > do work on them), the value of "ALLOCATED(Var1) remains 0". > I found users reporting similar issues in earlier threads, but reading > those, i could not get a clear solution/fix to the problem. I should > add that I would like to stay with allocatables (i.e., avoid > pointers). Since I was explicitly deallocating the memories only at > the end of the subroutine, and fortran would have done so > automatically as soon as I exit the subroutine, so in principle I > could get away with the problem by taking away the offending > DEALLOCATE statement(s). However, that does not work. I still get > "Access Violation". > Do you have any suggestions?
Not quite sure what you mean here, why should you freeing the memory be any different from them being freed automagically ? Anyway Deallocate failing is, in my experience, always due to an out of bounds error on an array. Try compiling with bound checking ( in fact I would recommend always using this when developing code ) and see what you get. Also do you really need to use the ALLOCATED intrinsic so much ? This is more a question of style, but again in my experience this is often, but not always, a sign that somebody has not thought through the algorithm quite as well as they might and is being lazy. This might not be an issue, but it can hide the execution path through the code taking an unexpected route due to a bug somewhere, Ian
|
 |
 |
 |
 |
|