Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Modules and the use of the EXTERNAL statement in F90

0 views
Skip to first unread message

jgri...@yahoo.com

unread,
Jan 10, 2009, 10:48:30 AM1/10/09
to

Folks,

I am new to F90 and would like some help on a new thing I
came across this week. I use the Sun Studio 11 F90 compiler.

I am using a canned subprogramme to solve an ODE problem
(details are not really important). The user has to supply
a subprogramme (any name can be used) that will be called
by the ODE solver. Naturally, the *name* of the user
defined subprogramme has to be passed to the ODE solver.
This is where I am confused.

This canned software comes with various examples. In these
the subprogramme defining the ODE system is defined
within a module which is used my the (main) programme that
calls the solver. The solver itself is defined within a
module that is USEd by the main programme.

The layout is as follows:

================================

module probdef

.. some definitions ...

contains
subroutine odesys(.......)
....
....
end

end module probdef


program main

use probdef
use solver
....
....
solution = odesolver(.., odesys, ...)
....
....
end program main

================================

This compiles and executes without a hitch. However, I
chose not to embed the subroutine 'odesys' in a module
and so my layout is as follows (with the system
parameters defined in the above module now being
put in another module -- syspars -- and USEd by the
MAIN program):

================================

subroutine odesys(.......)
....
....
end

program main

use syspars
use solver
....
....
solution = odesolver(.., odesys, ...)
....
....
end program main

================================

This does NOT compile. The compiler says that it cannot
find the "generic function ODESOLVER". However, a
little monkeying revealed that the real issue is the name
'odesys' in the call to 'odesolver'. If I put an

EXTERNAL odesys

in the above, everything appears to work.

So the question: How is it that when odesys is contained
in a module the EXTERNAL statement is not required, but
if odesys not contained in a module, it has to be declared
external. I would have thought that odesys is local to the
module and is not visible in the main programme.

In any case, I am familiar with the use of EXTERNAL in
such cases in F77, but I do not 'get it' in F90. (Further,
I have read that the EXTERNAL statement is kind of
'redundant' in F90 in some web pages -- but I will
leave that for later!)

Would greatly appreciate anyone throwing light on this.

thanks
jg

michael...@compuserve.com

unread,
Jan 10, 2009, 11:16:53 AM1/10/09
to
On Jan 10, 4:48 pm, jgrimm...@yahoo.com wrote:

>So the question: How is it that when odesys is contained
>in a module the EXTERNAL statement is not required,

Because odesys is *not* external: it is a module procedure that is
accessible in the main program via use association.

>but if odesys not contained in a module, it has to be declared
>external.

Because it *is* external, and the statement is needed to tell the
compiler that odesys is the name of an external procedure rather than
being the name of a local variable with default type (see also
"Fortran 95/2003 Explained", Sections 5.11 and 5.12).

Regards,

Mike Metcalf


jgri...@yahoo.com

unread,
Jan 10, 2009, 12:04:34 PM1/10/09
to
Michael,

On Sat, 10 Jan 2009 08:16:53 -0800 (PST),
michael...@compuserve.com wrote:

>On Jan 10, 4:48 pm, jgrimm...@yahoo.com wrote:
>
>>So the question: How is it that when odesys is contained
>>in a module the EXTERNAL statement is not required,
>
> Because odesys is *not* external: it is a module procedure that is
>accessible in the main program via use association.

This is the point about modules that I have not fully come to
grips with! Thanks for pointing it out.

>>but if odesys not contained in a module, it has to be declared
>>external.
>
> Because it *is* external, and the statement is needed to tell the
>compiler that odesys is the name of an external procedure rather than
>being the name of a local variable with default type (see also
>"Fortran 95/2003 Explained", Sections 5.11 and 5.12).

Will do ... I have it on my desk and looked at it all the time
as I wrote my first F90 programme!

After I wrote, it hit me that the contained procedure is not
private and so is available outside the module. But, I did not
appreciate the fact that the USE statement makes the names
of subprogrammes available. I did come across the statement
that the use of an explicit INTERFACE will also make the
EXTERNAL statement unnecessary. Is that true?

thanks
jg

michael...@compuserve.com

unread,
Jan 10, 2009, 12:09:52 PM1/10/09
to
>But, I did not
>appreciate the fact that the USE statement makes the names
of subprogrammes available.

In the absence of a private statement, all entities are accessed
(op. cit. Section 5.5).

>I did come across the statement
>that the use of an explicit INTERFACE will also make the
>EXTERNAL statement unnecessary. Is that true?

Yes.

Regards,

Mike Metcalf


jgri...@yahoo.com

unread,
Jan 10, 2009, 2:31:12 PM1/10/09
to
On Sat, 10 Jan 2009 09:09:52 -0800 (PST),
michael...@compuserve.com wrote:

>>I did come across the statement
>>that the use of an explicit INTERFACE will also make the
>>EXTERNAL statement unnecessary. Is that true?
>
>Yes.

Thanks.

jg

robert....@sun.com

unread,
Jan 12, 2009, 1:24:27 AM1/12/09
to
On Jan 10, 7:48 am, jgrimm...@yahoo.com wrote:
> Folks,
>
> I am new to F90 and would like some help on a new thing I
> came across this week. I use the Sun Studio 11 F90 compiler.

Sun's Studio 12 compiler is available for download at no
cost from Sun's website. Sun's Studio 12 compiler is
available at no cost for both commercial and noncommercial
use.

Bob Corbett

jgri...@yahoo.com

unread,
Jan 23, 2009, 6:54:45 PM1/23/09
to
On Sun, 11 Jan 2009 22:24:27 -0800 (PST), robert....@sun.com
wrote:


>Sun's Studio 12 compiler is available for download at no
>cost from Sun's website. Sun's Studio 12 compiler is
>available at no cost for both commercial and noncommercial
>use.
>
>Bob Corbett

Thanks, but we have the stuff at work.

jg

0 new messages