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

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

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

Hana
7 posts / novo 0
Último post
Para obter mais informações sobre otimizações de compiladores, consulte Aviso sobre otimizações.

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

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

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.

Citação:

TimP (Intel) escreveu:

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

Citação:

mecej4 escreveu:

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.

Hana

Citação:

hana K. escreveu:

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.

Deixar um comentário

Faça login para adicionar um comentário. Não é membro? Inscreva-se hoje mesmo!