My code base is organized as follows. I basically put one derived-types and its associated subroutine (as type-bound procedures) inside a module file. A collection of (related) module files is put into directory, and then I have a "super"-module file in each directory in which all of the module inside that directory is USE-d. This way, subsequent directory can just USE that "super-module" and get access to everything defined by the modules inside the directory. Here's an example:
directory A/ contains:
A_1.f90 with A_1_Module, with A_1_Type and subroutines defined
A_2.f90 with A_2_Module, with A_2_Type and subroutines define
And finally, A_SuperModule.f90 has something like:
end module A_SuperModule
Now every modules in directory B/ will only need to "USE A_SuperModule" to get all the derived types and procedures in A_1, A_2, ..., etc.
This pattern continues as we build up more and more code. What we found is that with Intel compiler, .mod grows larger and largers as in the "higher-level" code (e.g the sizes in G > F > E ... ). The growth is not linear, and there's some "raggedness" in the size but the trend seems to be there.
What turns out to be a problem is that at higher level enough, the .mod sizes created by the compiler seems to hit around 7MB and then the next file that uses that module cannot be compiled. The compiler keeps churning when trying to compile the file, CPU usage for ifort process hit 100%, and memory usage for the compiler process keeps increasing.
I am not sure if this is caused by something in the file themselves or by the pattern of how we use modules. Or a combination of both. We uses a lot of F2003 features including abstract type and type-extension. But I don't see this issue with another compiler we've tried so I suspect this is an issue with Intel compiler.
Is this a known issue or have anyone seen this before ?