When setting up a module, what is the difference between defining variables within the derived type definition, versus within a subroutine for that module? Specifically I will need to 'pass' data from one module to another. For example MathStuffModule adds some numbers within a subroutine, and then PrintStuffModule prints those numbers (actual problem is much more complex, but I'm still trying to understand the basics).
For example in the code below, what is the difference between the variable "answer" and "AddThis" as far as how they each relate to the module, how/if they can be called outside of the module (and say passed to a PrintStuffModule), and calling/defining the variables within the actual program?
module MathStuffModule
type MathStuffType
integer :: answer
contains
procedure :: mathstuff1
end type MathStuffType
contains
subroutine mathstuff1(m,AddThis,number)
class(MathStuffType) :: m
real :: AddThis,number,answer
m%answer = number + AddThis
end subroutine mathstuff1
end module MathStuffModule
This is more of an extended comment than an answer, I'm not 100% sure what OP is asking about.
Module entities are available within any scope that includes a use statement; in this example it would be use mathstuffmodule.
This business of one scope being able to manipulate entities defined in another scope is called use-association, it's all about associating entities in (possibly complex and long) programs by clever use of use statements.
Optionally a use statement can restrict the module entities associated, by using an only clause, or it can rename module entities so they are known by a different name in the using scope.
To keep things simple think only, at this stage, of program's using modules. If a program includes a use statement, then any module entities are in scope whenever any program entity is in scope. Program entities (and entities use-associated into a program) are typically in scope throughout the program's execution, but may get masked in sub-scopes.
I wouldn't call answer a variable, I'd call it a member of the derived type mathstufftype. If an entity of that type is declared in a program scope, then the member can be accessed by a term something like entity%answer.
I wouldn't call addthis a variable either, it's a dummy argument name for the routine mathstuff1. It would be an error to use the name addthis outside the routine to refer to that argument. (It would be possible to declare a variable called addthis in another scope, if you want to confuse matters.)
In isolation, there is nothing called answer nor anything called addthis which can be used by a client of the module and manipulated like a variable.
It's probably also not helpful to think of passing data between modules. If a program uses two modules, then it has access to any entities defined in either, and can use, say, a variable defined in one module as a parameter to a routine defined in the other. It's also possible for module A to use module B; then (a) code in B can manipulate entities use-associated from A and (b) any other module (or program) which uses B also gets (transitively) access to the entities in A.