Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28384 Discussions

How to deal with big fortran programme

ollehyas
Beginner
359 Views

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?
0 Kudos
6 Replies
Steven_L_Intel1
Employee
359 Views
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.
0 Kudos
jimdempseyatthecove
Honored Contributor III
359 Views
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

c
DEC$ 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
0 Kudos
Arjen_Markus
Honored Contributor I
359 Views
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
0 Kudos
Jugoslav_Dujic
Valued Contributor II
359 Views
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.

0 Kudos
jimdempseyatthecove
Honored Contributor III
359 Views
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
0 Kudos
Arjen_Markus
Honored Contributor I
359 Views
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
0 Kudos
Reply