Automatic interface generation

[Peter_A_1]

My apologies if this should have piggy backed on another forum..

I am trying to utilize Automatic Interfaces (to help tidy, maintain and develop my code) and I am having difficulties understanding "the rules" [I have not found any documentation of it] It seems thattypicallyXXX.90 will get an XXX_mod.f90and possibly an XXX_mod.mod created in DEBUG directory and that, I assume, is seen by the linker.

1. What governs if and when an XXX_mod is made?

2. Am I correct that order matters? (order in routines file and order of the files)

My "problem" is a bit tedious but a very simple example my help. As it stands it gets:

FAILS: with subroutine order vadd, vadd2:

Z:\Visual Studio Projects\Lexus00\test\test.f90(6) : Error: Error in opening the compiled module file. Check INCLUDE paths. [VADD_MOD]

WORKS: with subroutine order vadd, vadd2:

Andin /debug directoryone gets vadd2_mod.f90 vadd2_mod.mod vadd_mod.f90 vadd_mod.mod

Subroutine vadd(a,b,c)

Use nrtype

Implicit None

Real(DP), Intent(IN) :: a(:),b(:)

Real(DP), Intent(OUT) :: c(:)

! Local

c=a+b

end Subroutine vadd

Subroutine vadd2(a,b,c)

Use nrtype

Use vadd_mod

Implicit None

Real(DP), Intent(IN) :: a(:),b(:)

Real(DP), Intent(OUT) :: c(:)

! Local

call vadd(a,b,c)

end Subroutine vadd2

Hopefully understanding this will allow me to fix a more complex program

Thanks, Peter

[tropfen]

Quoting - peter_aptaker

My apologies if this should have piggy backed on another forum..

I am trying to utilize Automatic Interfaces (to help tidy, maintain and develop my code) and I am having difficulties understanding "the rules" [I have not found any documentation of it] It seems that typically XXX.90 will get an XXX_mod.f90 and possibly an XXX_mod.mod created in DEBUG directory and that, I assume, is seen by the linker.

1. What governs if and when an XXX_mod is made?

2. Am I correct that order matters? (order in routines file and order of the files)

My "problem" is a bit tedious but a very simple example my help. As it stands it gets:

FAILS: with subroutine order vadd, vadd2:

Z:Visual Studio ProjectsLexus00testtest.f90(6) : Error: Error in opening the compiled module file. Check INCLUDE paths. [VADD_MOD]

WORKS: with subroutine order vadd, vadd2:

And in /debug directory one gets vadd2_mod.f90 vadd2_mod.mod vadd_mod.f90 vadd_mod.mod

Subroutine vadd(a,b,c)

Use nrtype

Implicit None

Real(DP), Intent(IN) :: a(:),b(:)

Real(DP), Intent(OUT) :: c(:)

! Local

c=a+b

end Subroutine vadd

Subroutine vadd2(a,b,c)

Use nrtype

Use vadd_mod

Implicit None

Real(DP), Intent(IN) :: a(:),b(:)

Real(DP), Intent(OUT) :: c(:)

! Local

call vadd(a,b,c)

end Subroutine vadd2

Hopefully understanding this will allow me to fix a more complex program

Thanks, Peter

the statement 'use' is used for accessing subroutines/functions from modules.

In your exemple the subroutine vadd2 is looking for the module vadd_mod. Those module is not listet inside your post.

One solution would be to add your subroutine to add the subroutine to a new createt module vadd_mod.

Frank

[Peter_A_1]

Quoting - tropfen

the statement 'use' is used for accessing subroutines/functions from modules.

In your exemple the subroutine vadd2 is looking for the module vadd_mod. Those module is not listet inside your post.

One solution would be to add your subroutine to add the subroutine to a new createt module vadd_mod.

Frank

Thanks for the quick reply Frank but .. the code ABOVE works!! The point is that Automatic Interfaces can (and do) generate the Modules . My question concrens "taming" this useful beast.

What doYOU think Steve Lione (I suspect you have enough to do without responding that fast!)

Cheers

[Steven_L_Intel1]

Please do not use the automatically generated modules directly in your code. You can use them as a reference for creating your own modules, but we do not support their use in this manner. Furthermore, the names of the modules will be changing in 11.0 to avoid conflicts with a common naming convention.

[Peter_A_1]

Quoting - Steve Lionel (Intel)

Please do not use the automatically generated modules directly in your code. You can use them as a reference for creating your own modules, but we do not support their use in this manner. Furthermore, the names of the modules will be changing in 11.0 to avoid conflicts with a common naming convention.

Hi Steve

I am very disappointed that you "you do not support" my using the generated modules as I planned I hoped it would help me avoid Module/ Interface problems that have blighted my intermittent Fortran 90 development. I feel Automatically generating Interfaces, and then using them still allows some useful arguments checking but facilitates much faster (and I would claim reliable) prototyping...

I assume from geninterface documentation that the files would be created ready for use, but I admit it gives no hint of sequencing . Without knowiing "the rules"I can neither work within them or even know if there is a "problem". I guess I will ahve to concede !

Might I email you?

Peter Aptaker

[Kevin_D_Intel]

The compiler uses the generated interfaces when using: /warn:interfaces

The two options can be used simultaneously such that each re-compilation after source edits generates new interfaces the compiler then uses to produce warnings about interface mismatches. Maybe the use of /gen-interfaces /warn:interfaces will help with your interests.

[Peter_A_1]

Quoting - Kevin Davis (Intel)

The compiler uses the generated interfaces when using: /warn:interfaces

The two options can be used simultaneously such that each re-compilation after source edits generates new interfaces the compiler then uses to produce warnings about interface mismatches. Maybe the use of /gen-interfaces /warn:interfaces will help with your interests.

Thanks Kevin. But Visual Studio 8 default options that I am using does this e.g.

/nologo /Zi /Od /gen-interfaces /warn:interfaces /module:"Debug" /object:"Debug" /traceback /check:bounds /libs:dll /threads /dbglibs /c

Might you have any ideas on my questions above? In my, not yet reavealed, example all is compilingfine but only after I have "hand added" selected XXXmod.f90 files that were curiously not generaed as "expected/ desired". Would you look at my example and, if so, what is the best way to send it? If I "Add files" here, are they public?

Cheers, Peter

[Kevin_D_Intel]

I believe adding files in the forum makes them public. I'd be happy to look at your example. If you prefer to keep it private, then you are welcome open an Intel Premier issue here, attach the file to the issue, and request it be directed to my attention, or try sending me private email.

Regarding your questions, based on my experiments:

For Question #1:

In the absence of user-defined modules, the compiler generates the _mod.f90 .mod files the first time a source file is compiled with /gen-interfaces, and with each re-compilation preceded by a "clean" (which removes only the .mod files).

In the absence of a "clean" and source edits affecting the interfaces to any defined subprograms, re-compilation of the source file only re-generates the _mod.f90 file with /gen-interfaces. The pre-existing .mod does not require rebuilding since no interfaces were changed. If any interface is changed, the .mod is also re-created.

For user-defined modules, a .mod file is generated for each defined module when the source file is re-compiled without regard for using the compiler interface options, making any edits, or preceding with "clean".

For Question #2:

I do not believe there are restrictions on the USE statement order within a file but issues can arise with name conflicts where modules use the same public names.

Order of compilation of files does matter when using modules.

I do not fully understand how it works, but when rebuilding an entire Solution/project under the IDE, it determines the required compilation order to avoid the error you showed. This is true whether the interface compiler options are used or not, and also true with user-defined modules.

In a case of an explicit USE statement, if you manually compile a USE-ing source file before compiling the source containing the module definition, then the .mod does not exist and you can suffer the error you showed.

Please keep Steve's reply in mind when considering my answers here. For the earlier cited example, the 'Use vadd_mod' in Subroutine vadd2 is not valid based on Steve's reply since it uses the compiler generated interface in an unintended manner. The USE would be valid if you had a source file named vadd.f90, where you declare the module "vadd_mod" containing Subroutine vadd.

I hope that helps.

[Peter_A_1]

Quoting - Kevin Davis (Intel)

I believe adding files in the forum makes them public. I'd be happy to look at your example. If you prefer to keep it private, then you are welcome open an Intel Premier issue here, attach the file to the issue, and request it be directed to my attention, or try sending me private email.

Regarding your questions, based on my experiments:

For Question #1:

In the absence of user-defined modules, the compiler generates the _mod.f90 .mod files the first time a source file is compiled with /gen-interfaces, and with each re-compilation preceded by a "clean" (which removes only the .mod files).

In the absence of a "clean" and source edits affecting the interfaces to any defined subprograms, re-compilation of the source file only re-generates the _mod.f90 file with /gen-interfaces. The pre-existing .mod does not require rebuilding since no interfaces were changed. If any interface is changed, the .mod is also re-created.

For user-defined modules, a .mod file is generated for each defined module when the source file is re-compiled without regard for using the compiler interface options, making any edits, or preceding with "clean".

For Question #2:

I do not believe there are restrictions on the USE statement order within a file but issues can arise with name conflicts where modules use the same public names.

Order of compilation of files does matter when using modules.

I do not fully understand how it works, but when rebuilding an entire Solution/project under the IDE, it determines the required compilation order to avoid the error you showed. This is true whether the interface compiler options are used or not, and also true with user-defined modules.

In a case of an explicit USE statement, if you manually compile a USE-ing source file before compiling the source containing the module definition, then the .mod does not exist and you can suffer the error you showed.

Please keep Steve's reply in mind when considering my answers here. For the earlier cited example, the 'Use vadd_mod' in Subroutine vadd2 is not valid based on Steve's reply since it uses the compiler generated interface in an unintended manner. The USE would be valid if you had a source file named vadd.f90, where you declare the module "vadd_mod" containing Subroutine vadd.

I hope that helps.

Thanks, I may send an example privately some time