How to pass derived type argument to a subroutine

AI Thread Summary
The discussion centers on the challenges of passing a derived type array in Fortran to a subroutine. The user encountered errors related to the derived type not being declared within the interface and type mismatches. Suggestions included using include files to define common data types, which would allow for easier management of type definitions across multiple modules. However, the preferred solution discussed was to create a module that contains the derived type and the array. This approach not only resolved the errors but also simplified function calls by reducing the number of arguments needed, demonstrating the benefits of modular programming in Fortran.
shitij
Messages
19
Reaction score
0
Hi all !

I have a derived type as:

Code:
TYPE type_atom_type_info
		integer:: type_code
		character(len=4)::type_cname
		real(kind=dbl)::mass
	end TYPE type_atom_type_info
I have an array of this type as:
Code:
TYPE(type_atom_type_info) atom_type_info(250)

I want to pass this array to a subroutine. I have made an interface in the same file for the subroutine

Code:
interface
		subroutine cname_to_code(atom_type_info,cname,code)
			TYPE(type_atom_type_info),intent(in)::atom_type_info(250)
			character(len=4),intent(in)::cname
			integer,intent(out)::code
		end subroutine cname_to_code		
	end interface

But I am getting an error as:
Code:
nma.f90:234.60:

   TYPE(type_atom_type_info),intent(in)::atom_type_info(250)
                                                            1
Error: the type of 'atom_type_info' at (1) has not been declared within the interface
nma.f90:1496.20:

 call cname_to_code(atom_type_info,'NH1',temp_k)
                    1
Error: Type mismatch in argument 'atom_type_info' at (1); passed TYPE(type_atom_type_info) to REAL(4)
nma.f90:4072.26:

 TYPE(type_atom_type_info),intent(in)::atom_type_info(250)
                          1
Error: Derived type 'type_atom_type_info' at (1) is being used before it is defined

I tried redefining the whole TYPE in the interface, but that didn't work.
How do I make the type 'global' ? Or is there any other way to pass derived type arguments to functions?

Thank you in advance !
 
Technology news on Phys.org
Hey garbageij.

You will need to reference this definition in each module. In C/C++ We use include files to include definitons for the source files and also for other header files that use those definitions.

I just searched google and I believe the statement is INCLUDE 'file'. What you should do is save your definitions to some file (all your common data types) and include this file everytime you need to use and work with data of that type.
 
Hmm...so I guess there's no other way, huh?
Thanks !
 
garbageij said:
Hmm...so I guess there's no other way, huh?
Thanks !

You can copy the type statement and throw it in the module, but that's not a good thing to do.

It's better to update one include file than trying to search for every single instance. Imagine if you had 20 classes that used the one definition and then imagine having to each everything 20 times!

This is why we have include files.
 
A couple of comments.

Writing a separate file with such declaration and including it everywhere you need it, it's one thing...if just like that...you will simply get a local variable everywhere

BUT,

If you include the declaration and a common block THEN, you will get all those subroutines to use the same varaibles...even if it is not 'global'

The Fortran 90 way of making some variables global is via a MODULE...you just create a module, put in there all the variables you need to use in your various subroutines...then, wherever you need them, instead of the "include" statement, you do "use modulename"
 
Thank you so much for your replies !

So I have made a module, in which I have put the derived type as well as the array, and now it's working fine. Making a module it seems was a good idea to begin with as now some of my function take less arguments (a few arguments were common to many functions)


Thanks again !
 
Thread 'Is this public key encryption?'
I've tried to intuit public key encryption but never quite managed. But this seems to wrap it up in a bow. This seems to be a very elegant way of transmitting a message publicly that only the sender and receiver can decipher. Is this how PKE works? No, it cant be. In the above case, the requester knows the target's "secret" key - because they have his ID, and therefore knows his birthdate.
I tried a web search "the loss of programming ", and found an article saying that all aspects of writing, developing, and testing software programs will one day all be handled through artificial intelligence. One must wonder then, who is responsible. WHO is responsible for any problems, bugs, deficiencies, or whatever malfunctions which the programs make their users endure? Things may work wrong however the "wrong" happens. AI needs to fix the problems for the users. Any way to...

Similar threads

Replies
5
Views
8K
Replies
3
Views
2K
Replies
59
Views
11K
Replies
6
Views
3K
Replies
8
Views
4K
Replies
7
Views
2K
Replies
2
Views
2K
Replies
5
Views
3K
Back
Top