Home     |     .Net Programming    |     cSharp Home    |     Sql Server Home    |     Javascript / Client Side Development     |     Ajax Programming

Ruby on Rails Development     |     Perl Programming     |     C Programming Language     |     C++ Programming     |     IT Jobs

Python Programming Language     |     Laptop Suggestions?    |     TCL Scripting     |     Fortran Programming     |     Scheme Programming Language


 
 
Cervo Technologies
The Right Source to Outsource

MS Dynamics CRM 3.0

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:

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:

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 !

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

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:

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" <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.

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:

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

Add to del.icio.us | Digg this | Stumble it | Powered by Megasolutions Inc