the array .... has value ... which is less than the lower bound of .....

[hana_K_]

Hi

I wrote my program in Fortran 90 and complied it successfully, but when I run it this error was appeared.

the array ENERGY has value -3689348814741910323 which is less than the lower bound of 1.

Does someone have an idea about this problem?

My code is something like this:

SUBROUTINE A (energy,....)

DOUBLE PRECISION, POINTER, DIMENSION(:,:), INTENT(IN) ::energy

…...

…....

END SUBROUTINE A

!-****************

DOUBLE PRECISION FUNCTION B(x,addMember)

CALL A(energy,...)

DOUBLE PRECISION, POINTER, DIMENSION(:,:) :: energy

ALLOCATE (energy(....))

…...

…...

DEALLOCATE (energy)

END FUNCTION B

!--******************

SUBROUTINE C(energy,....)

DOUBLE PRECISION, POINTER, DIMENSION(:,:), INTENT(IN) ::energy

…..

…..

END SUNROUTINE C

!-****************

DOUBLE PRECISION FUNCTION D(.....)

DOUBLE PRECISION, POINTER, DIMENSION(:,:) :: energy

ALLOCATE (energy(....))

CALL A(energy,...)

DEALLOCATE(energy)

END FUNCTION D

many thanks in advanced

Hana

[TimP]

It looks as if you are calling the subroutine with the array argument before allocating it, so your result seems unsurprising.

[Lorri_M_Intel]

These routines all contained deferred shape arguments, which means that an interface must be available at the call site.

I appreciate that this is just truncated code, but none of the subroutines here have any knowledge that the routine they're calling is expecting a deferred shape argument.   Make sure your actual code is correct.

                   --Lorri

[mecej4]

There are a couple of sobering conclusions to be drawn from this thread: 

• If an explicit interface is not provided when one is needed, the runtime error messages may say very misleading things. If a user reports only these errors without showing the complete  sources (or at least the relevant parts thereof), any cure that may be suggested is likely to make the headache worse.
• If you are going to use assumed shape arrays, optional arguments, etc., consider using a self-imposed rule to place subprograms using these features into modules and USE the modules in the callers. It would be a good idea to forswear using implicit typing when you have such subprograms in a project.

[hana_K_]

TimP (Intel) wrote:

It looks as if you are calling the subroutine with the array argument before allocating it, so your result seems unsurprising.

Thank you, but as you see I allocate my argumment, just the INTENT(IN) and INTENT(OUT) argument.

[hana_K_]

mecej4 wrote:

There are a couple of sobering conclusions to be drawn from this thread: 

• If an explicit interface is not provided when one is needed, the runtime error messages may say very misleading things. If a user reports only these errors without showing the complete  sources (or at least the relevant parts thereof), any cure that may be suggested is likely to make the headache worse.
• If you are going to use assumed shape arrays, optional arguments, etc., consider using a self-imposed rule to place subprograms using these features into modules and USE the modules in the callers. It would be a good idea to forswear using implicit typing when you have such subprograms in a project.

Thank you.

This is a part of my code. and this part comes in aMODULE which I call  this MODULE and others in my main program also I used IMPLICT NONE in my code.

[Casey]

hana K. wrote:

Quote:

TimP (Intel)wrote:

It looks as if you are calling the subroutine with the array argument before allocating it, so your result seems unsurprising.

Thank you, but as you see I allocate my argumment, just the INTENT(IN) and INTENT(OUT) argument.

Presumably what Tim is referring to is you inconsitancy in allocating energy.  For example, subroutine A declares energy as intent in, but we do not know what it does, so we infer from the other procedures.  Subroutine B calls A, then allocates energy.  Subroutine D allocates energy, then calls A. At then end of both B and D, energy is deallocated.  From what code we can see, the only inferences that can be made are that when A is called, energy may either be allocated or not.  When B or D are called, energy is unallocated upon exit.  With only that information I have to agree with Tim's statement.   Posting a complete code example would allow for more helpful feedback to be provided.