I am getting a strange error when compiling abcpar.f in gfortran:
Compiling .\CHM\VALIEQ\abcpar.f
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - -
dii.inc:30:10:
Error: 'abcpar' of module 'aaa_modules', imported at (1), is also the
name of the current program unit
Error: Last command making (build\abcpar.o) returned a bad status
Error: Make execution terminated
* Failed *
C aaa_modules.f
C list of interfaces in a module for CHM / DII code compiling
MODULE aaa_modules
implicit none
INTERFACE
SUBROUTINE ABCPAR(ISW,IRETST,IR,IC,PAR,IPHASE)
INTEGER(KIND=8) :: ISW
INTEGER(KIND=8) :: IRETST
INTEGER(KIND=8) :: IR
INTEGER(KIND=8) :: IC
REAL(KIND=8) :: PAR
INTEGER(KIND=8) :: IPHASE
END SUBROUTINE ABCPAR
END INTERFACE
...
END MODULE aaa_modules
SUBROUTINE ABCPAR (ISW, IRETST, IR, IC, PAR, IPHASE)
INCLUDE 'dii.inc'
...
return
end
C dii.inc
use aaa_modules
C force all variables to be declared
implicit none
Thanks,
Lynn McGuire
On 11/11/2024 4:35 PM, Lynn McGuire wrote:
I am getting a strange error when compiling abcpar.f in gfortran:
Compiling .\CHM\VALIEQ\abcpar.f
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - -
dii.inc:30:10:
Error: 'abcpar' of module 'aaa_modules', imported at (1), is also the
name of the current program unit
Error: Last command making (build\abcpar.o) returned a bad status
Error: Make execution terminated
* Failed *
C aaa_modules.f
C list of interfaces in a module for CHM / DII code compiling
MODULE aaa_modules
implicit none
INTERFACE
SUBROUTINE ABCPAR(ISW,IRETST,IR,IC,PAR,IPHASE)
INTEGER(KIND=8) :: ISW
INTEGER(KIND=8) :: IRETST
INTEGER(KIND=8) :: IR
INTEGER(KIND=8) :: IC
REAL(KIND=8) :: PAR
INTEGER(KIND=8) :: IPHASE
END SUBROUTINE ABCPAR
END INTERFACE
...
END MODULE aaa_modules
SUBROUTINE ABCPAR (ISW, IRETST, IR, IC, PAR, IPHASE)
INCLUDE 'dii.inc'
...
return
end
C dii.inc
use aaa_modules
C force all variables to be declared
implicit none
Thanks,
Lynn McGuire
Apparently, the current subroutine being compiled cannot have an
interface in the module being USEd.
The Metcalf Fortran 95 book says that I can exempt the current
subroutine from the USE by:
USE module_name, exempt_this_one => name
where name is the name of current subroutine or function without the
file suffix and without the path.
I just need a way to generalize the name and __FILE__ does not work.
Lynn
On 11/11/2024 4:35 PM, Lynn McGuire wrote:
I am getting a strange error when compiling abcpar.f in gfortran:
Compiling .\CHM\VALIEQ\abcpar.f
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - -
dii.inc:30:10:
Error: 'abcpar' of module 'aaa_modules', imported at (1), is also the
name of the current program unit
Error: Last command making (build\abcpar.o) returned a bad status
Error: Make execution terminated
* Failed *
C aaa_modules.f
C list of interfaces in a module for CHM / DII code compiling
MODULE aaa_modules
implicit none
INTERFACE
SUBROUTINE ABCPAR(ISW,IRETST,IR,IC,PAR,IPHASE)
INTEGER(KIND=8) :: ISW
INTEGER(KIND=8) :: IRETST
INTEGER(KIND=8) :: IR
INTEGER(KIND=8) :: IC
REAL(KIND=8) :: PAR
INTEGER(KIND=8) :: IPHASE
END SUBROUTINE ABCPAR
END INTERFACE
...
END MODULE aaa_modules
SUBROUTINE ABCPAR (ISW, IRETST, IR, IC, PAR, IPHASE)
INCLUDE 'dii.inc'
...
return
end
C dii.inc
use aaa_modules
C force all variables to be declared
implicit none
Thanks,
Lynn McGuire
Apparently, the current subroutine being compiled cannot have an
interface in the module being USEd.
The Metcalf Fortran 95 book says that I can exempt the current
subroutine from the USE by:
USE module_name, exempt_this_one => name
where name is the name of current subroutine or function without the
file suffix and without the path.
I just need a way to generalize the name and __FILE__ does not work.
Lynn
On 11/11/2024 7:57 PM, Lynn McGuire wrote:
On 11/11/2024 4:35 PM, Lynn McGuire wrote:If all of your general purpose subroutines and functions are in modules,
I am getting a strange error when compiling abcpar.f in gfortran:
Compiling .\CHM\VALIEQ\abcpar.f
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - -
dii.inc:30:10:
Error: 'abcpar' of module 'aaa_modules', imported at (1), is also the
name of the current program unit
Error: Last command making (build\abcpar.o) returned a bad status
Error: Make execution terminated
* Failed *
C aaa_modules.f
C list of interfaces in a module for CHM / DII code compiling
MODULE aaa_modules
implicit none
INTERFACE
SUBROUTINE ABCPAR(ISW,IRETST,IR,IC,PAR,IPHASE)
INTEGER(KIND=8) :: ISW
INTEGER(KIND=8) :: IRETST
INTEGER(KIND=8) :: IR
INTEGER(KIND=8) :: IC
REAL(KIND=8) :: PAR
INTEGER(KIND=8) :: IPHASE
END SUBROUTINE ABCPAR
END INTERFACE
...
END MODULE aaa_modules
SUBROUTINE ABCPAR (ISW, IRETST, IR, IC, PAR, IPHASE)
INCLUDE 'dii.inc'
...
return
end
C dii.inc
use aaa_modules
C force all variables to be declared
implicit none
Thanks,
Lynn McGuire
Apparently, the current subroutine being compiled cannot have an
interface in the module being USEd.
The Metcalf Fortran 95 book says that I can exempt the current
subroutine from the USE by:
USE module_name, exempt_this_one => name
where name is the name of current subroutine or function without the
file suffix and without the path.
I just need a way to generalize the name and __FILE__ does not work.
Lynn
you don't need interfaces for them (one of the advantages of modules).
On 11/12/2024 12:06 AM, baf wrote:
On 11/11/2024 7:57 PM, Lynn McGuire wrote:
On 11/11/2024 4:35 PM, Lynn McGuire wrote:If all of your general purpose subroutines and functions are in
I am getting a strange error when compiling abcpar.f in gfortran:
Compiling .\CHM\VALIEQ\abcpar.f
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - -
dii.inc:30:10:
Error: 'abcpar' of module 'aaa_modules', imported at (1), is also
the name of the current program unit
Error: Last command making (build\abcpar.o) returned a bad status
Error: Make execution terminated
* Failed *
C aaa_modules.f
C list of interfaces in a module for CHM / DII code compiling
MODULE aaa_modules
implicit none
INTERFACE
SUBROUTINE ABCPAR(ISW,IRETST,IR,IC,PAR,IPHASE) >>>> INTEGER(KIND=8) :: ISW
INTEGER(KIND=8) :: IRETST
INTEGER(KIND=8) :: IR
INTEGER(KIND=8) :: IC
REAL(KIND=8) :: PAR
INTEGER(KIND=8) :: IPHASE
END SUBROUTINE ABCPAR
END INTERFACE
...
END MODULE aaa_modules
SUBROUTINE ABCPAR (ISW, IRETST, IR, IC, PAR, IPHASE)
INCLUDE 'dii.inc'
...
return
end
C dii.inc
use aaa_modules
C force all variables to be declared
implicit none
Thanks,
Lynn McGuire
Apparently, the current subroutine being compiled cannot have an
interface in the module being USEd.
The Metcalf Fortran 95 book says that I can exempt the current
subroutine from the USE by:
USE module_name, exempt_this_one => name
where name is the name of current subroutine or function without the
file suffix and without the path.
I just need a way to generalize the name and __FILE__ does not work.
Lynn
modules, you don't need interfaces for them (one of the advantages of
modules).
I have 6,000 subroutines in 5,000 files. All I did was put interfaces
for about 2,600 of the subroutines into a single module.
Lynn
On 11/11/2024 10:40 PM, Lynn McGuire wrote:
On 11/12/2024 12:06 AM, baf wrote:A better alternative would be to put the subroutines in the module and
On 11/11/2024 7:57 PM, Lynn McGuire wrote:
On 11/11/2024 4:35 PM, Lynn McGuire wrote:If all of your general purpose subroutines and functions are in
I am getting a strange error when compiling abcpar.f in gfortran:
Compiling .\CHM\VALIEQ\abcpar.f
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >>>>> - - - - - -
dii.inc:30:10:
Error: 'abcpar' of module 'aaa_modules', imported at (1), is also
the name of the current program unit
Error: Last command making (build\abcpar.o) returned a bad status
Error: Make execution terminated
* Failed *
C aaa_modules.f
C list of interfaces in a module for CHM / DII code compiling
MODULE aaa_modules
implicit none
INTERFACE
SUBROUTINE ABCPAR(ISW,IRETST,IR,IC,PAR,IPHASE) >>>>> INTEGER(KIND=8) :: ISW
INTEGER(KIND=8) :: IRETST
INTEGER(KIND=8) :: IR
INTEGER(KIND=8) :: IC
REAL(KIND=8) :: PAR
INTEGER(KIND=8) :: IPHASE
END SUBROUTINE ABCPAR
END INTERFACE
...
END MODULE aaa_modules
SUBROUTINE ABCPAR (ISW, IRETST, IR, IC, PAR, IPHASE)
INCLUDE 'dii.inc'
...
return
end
C dii.inc
use aaa_modules
C force all variables to be declared
implicit none
Thanks,
Lynn McGuire
Apparently, the current subroutine being compiled cannot have an
interface in the module being USEd.
The Metcalf Fortran 95 book says that I can exempt the current
subroutine from the USE by:
USE module_name, exempt_this_one => name
where name is the name of current subroutine or function without the
file suffix and without the path.
I just need a way to generalize the name and __FILE__ does not work.
Lynn
modules, you don't need interfaces for them (one of the advantages of
modules).
I have 6,000 subroutines in 5,000 files. All I did was put interfaces
for about 2,600 of the subroutines into a single module.
Lynn
USE the module. Then you don't need the interfaces (the compiler gets
all of the interface information "automagically").
A better alternative would be to put the subroutines in the module andIf all of your general purpose subroutines and functions are in
modules, you don't need interfaces for them (one of the advantages
of modules).
I have 6,000 subroutines in 5,000 files. All I did was put
interfaces for about 2,600 of the subroutines into a single module.
Lynn
USE the module. Then you don't need the interfaces (the compiler gets
all of the interface information "automagically").
850,000 lines of code in a single file ? That would be a mess.
Lynn
On 11/12/2024 12:43 PM, Lynn McGuire wrote:
I wasn't suggesting a single module. Partition the subprograms into meaningful subgroups. Also, as was indicated, you can use submodules to avoid cascading compilation issues with a large number of modules.A better alternative would be to put the subroutines in the moduleIf all of your general purpose subroutines and functions are in
modules, you don't need interfaces for them (one of the advantages
of modules).
I have 6,000 subroutines in 5,000 files. All I did was put
interfaces for about 2,600 of the subroutines into a single module.
Lynn
and USE the module. Then you don't need the interfaces (the compiler
gets all of the interface information "automagically").
850,000 lines of code in a single file ? That would be a mess.
Lynn
On 11/12/2024 4:01 PM, baf wrote:
On 11/12/2024 12:43 PM, Lynn McGuire wrote:
I wasn't suggesting a single module. Partition the subprograms intoA better alternative would be to put the subroutines in the moduleIf all of your general purpose subroutines and functions are in
modules, you don't need interfaces for them (one of the advantages >>>>>> of modules).
I have 6,000 subroutines in 5,000 files. All I did was put
interfaces for about 2,600 of the subroutines into a single module.
Lynn
and USE the module. Then you don't need the interfaces (the compiler
gets all of the interface information "automagically").
850,000 lines of code in a single file ? That would be a mess.
Lynn
meaningful subgroups. Also, as was indicated, you can use submodules
to avoid cascading compilation issues with a large number of modules.
My father and two other engineer profs started developing the software
back in 1968 on a Univac 1108. It had 32K words of data space and 32K words of code space. To build large software, we had to manually
partition the software ourselves so that it would fit into those 32K
words of code space. It was a major pain when somebody would update a subroutine and mess up the partition map.
When I personally started working on the software in 1975, it was one of
my jobs to update the huge partition map on the wall outside my bosses office. I used the big computer sheets and taped them together, about a hundred or so of the sheets.
Never again.
Lynn
Lynn McGuire wrote:
On 11/12/2024 4:01 PM, baf wrote:
On 11/12/2024 12:43 PM, Lynn McGuire wrote:
I wasn't suggesting a single module. Partition the subprograms intoA better alternative would be to put the subroutines in the moduleIf all of your general purpose subroutines and functions are in >>>>>>> modules, you don't need interfaces for them (one of the
advantages of modules).
I have 6,000 subroutines in 5,000 files. All I did was put
interfaces for about 2,600 of the subroutines into a single module. >>>>>>
Lynn
and USE the module. Then you don't need the interfaces (the
compiler gets all of the interface information "automagically").
850,000 lines of code in a single file ? That would be a mess.
Lynn
meaningful subgroups. Also, as was indicated, you can use submodules
to avoid cascading compilation issues with a large number of modules.
My father and two other engineer profs started developing the software
back in 1968 on a Univac 1108. It had 32K words of data space and 32K
words of code space. To build large software, we had to manually
partition the software ourselves so that it would fit into those 32K
words of code space. It was a major pain when somebody would update a
subroutine and mess up the partition map.
When I personally started working on the software in 1975, it was one
of my jobs to update the huge partition map on the wall outside my
bosses office. I used the big computer sheets and taped them
together, about a hundred or so of the sheets.
Never again.
Lynn
Were you using @FOR (Fielddata) or @FTN (Ascii)?
Things became much simpler when multiple Ibanks and addresses over 0200
000 became possible (for @ftn, @for was abandoned at some point). I
think @ftn also permitted multiple Dbanks but I never used that, the
code generated was - by necessity - horrific.
On 11/18/2024 5:50 AM, R Daneel Olivaw wrote:
Lynn McGuire wrote:
On 11/12/2024 4:01 PM, baf wrote:
On 11/12/2024 12:43 PM, Lynn McGuire wrote:
I wasn't suggesting a single module. Partition the subprograms intoA better alternative would be to put the subroutines in the module >>>>>> and USE the module. Then you don't need the interfaces (theIf all of your general purpose subroutines and functions are in >>>>>>>> modules, you don't need interfaces for them (one of the
advantages of modules).
I have 6,000 subroutines in 5,000 files. All I did was put
interfaces for about 2,600 of the subroutines into a single module. >>>>>>>
Lynn
compiler gets all of the interface information "automagically").
850,000 lines of code in a single file ? That would be a mess.
Lynn
meaningful subgroups. Also, as was indicated, you can use submodules
to avoid cascading compilation issues with a large number of modules.
My father and two other engineer profs started developing the
software back in 1968 on a Univac 1108. It had 32K words of data
space and 32K words of code space. To build large software, we had
to manually partition the software ourselves so that it would fit
into those 32K words of code space. It was a major pain when
somebody would update a subroutine and mess up the partition map.
When I personally started working on the software in 1975, it was one
of my jobs to update the huge partition map on the wall outside my
bosses office. I used the big computer sheets and taped them
together, about a hundred or so of the sheets.
Never again.
Lynn
Were you using @FOR (Fielddata) or @FTN (Ascii)?
Things became much simpler when multiple Ibanks and addresses over
0200 000 became possible (for @ftn, @for was abandoned at some
point). I think @ftn also permitted multiple Dbanks but I never used
that, the code generated was - by necessity - horrific.
It has been 49 years ago, I do not remember. Too many computers, too
many languages. I have written software in around dozen languages and a dozen platforms now. Fortran, IBM 370 Assembly, Basic, Pascal, C, HTML, Perl, C++, Smalltalk, bsh, Visual Basic, etc.
We gave up on the Univac 1108 in 1981 ??? and the CDC 7600 in 1982. I started working at another company in 1982 when I finished my degree in Mechanical Engineering at TAMU. I went back to the engineering software company in 1989.
Lynn
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 991 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 119:42:14 |
| Calls: | 12,958 |
| Files: | 186,574 |
| Messages: | 3,265,638 |