topic How to deal with big fortran programme in Intel® Fortran Compiler

How to deal with big fortran programme

ollehyas — Sun, 07 Nov 2010 03:28:05 GMT

Hi, black belts,

If the functions and subroutines in the module are so many and so big, I want to disperse the module into

different files, is it possible ? if yes, How to implement?

by the way, what integrated editor enviroment can display the function and subroutine in module in the list

form like VS displays class member?

How to deal with big fortran programme

Steven_L_Intel1 — Sun, 07 Nov 2010 22:26:21 GMT

If the functions and subroutines are in a module, you cannot separate them at this time. The Fortran 2008 "submodules" feature would allow you to do this, but Intel Fortran does not yet support this.

There is no tool in the editor that will list the functions and subroutines. The next major release, due soon, will have an option to generate a listing file with cross reference, so you could look at that to find procedures.

How to deal with big fortran programme

jimdempseyatthecove — Mon, 08 Nov 2010 00:29:13 GMT

You could experiment withmoving the functions and subroutines to seperate files, named with a prefix name of the module name followed by the subroutine name as used within the module. Replace the subroutines and functions with interfaces to the now aliased entry point name using

cDEC$ ATTRIBUTES ALIAS: external-name:: subprogram

to rename the module familial name to the external module prefixed name.

module foo
...
contains
... ! data here
subroutine bar()
...

---------- becomes ------------
module foo
...
contains
... ! data here
! was subroutine bar()
!DEC$ ATTRIBUES ALIAS: foo_bar:: bar
interface
subroutine bar()
end subroutine bar
end interface
...

Then create a library project named foo_lib
holding the foo_bar, foo_tweedledee, ...

Jim Dempsey

How to deal with big fortran programme

Arjen_Markus — Mon, 08 Nov 2010 07:59:02 GMT

I am not a black belt :), but I do have a few suggestions:
- The simplest is to use the INCLUDE statement (or what is the proper term?) to split the
source file into smaller ones.The module could then look like:
module mymodule
... derivedtypes and whatever
contains
include "source1.f90"
include "source2.f90"
...
endmodule

- Another solution is to split the module into smaller modules. Common derived types
can be put into a module of their own. To create a single overall module that contains
everything andcan be used as the original one:

module mymodule
use mydatamodule
use mysubmodule1
use mysubmodule2
...
end module

The advantage of the second method is that each source file contains a proper module and
therefore contains eveything you need to know.

Regards,

Arjen

How to deal with big fortran programme

Jugoslav_Dujic — Mon, 08 Nov 2010 09:16:39 GMT

Quoting arjenmarkus

The advantage of the second method is that each source file contains a proper module and
therefore contains eveything you need to know.

...and the additional disadvantage of the first method is that it's likely to confuse the debugger and/or dependency analysis.

How to deal with big fortran programme

jimdempseyatthecove — Mon, 08 Nov 2010 13:58:26 GMT

Arjen,

I do not believe the original problem was a request to reduce the size of an editable file. Your suggestion resolves this issue.

If the requirement were to reduce the compile time, considering IPO and potentially 1000's of functions/subroutines, then separation into a library, defined and accessible via a module will resolve this issue.

The original poster will have to determine which route is best for them.

Jim Dempsey

How to deal with big fortran programme

Arjen_Markus — Mon, 08 Nov 2010 14:38:18 GMT

If the file indeed contains so many subprograms, then it is bound to be a piling up of all manner of things.
Putting related functions and subroutines in different files, grouping the code should make it all more manageable.

If all these subprograms are interconnected in asuch a way they can not be disentangled, then the OP
is in serious trouble, I'd say.

Regards,

Arjen