- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I have defined a dynamic array like this:
integer, dimension(:), allocatable::nCommonIndex
But still could not figure out how I can make it a global variable. I tried this syntax just after the decleration:
common /nCommon/ nCommonGrainIndex
But it gives me the error saying:
error #6406: Conflicting attributes or multiple declaration of name. [NCOMMONGRAININDEX]
common /nCommon/ nCommonGrainIndex
-----------------------^
Appreciate if you can help me with this issue.
Thanks,
HR.
Link Copied
9 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You should be aware that Fortran does not have truly global variables. You can share
variables byCOMMON blocks (the ancient way that you should avoid) and modules.
Try:
module commons
integer, dimension(:), allocatable :: nCommonIndex
end module commons
And wherever you need this array:
subroutine needToUseCommons
use commons ! The name of the module
...
allocate( nCommonIndex(10) ) ! Allocate it for further use
...
end subroutine needToUSeCommons
Regards,
Arjen
variables byCOMMON blocks (the ancient way that you should avoid) and modules.
Try:
module commons
integer, dimension(:), allocatable :: nCommonIndex
end module commons
And wherever you need this array:
subroutine needToUseCommons
use commons ! The name of the module
...
allocate( nCommonIndex(10) ) ! Allocate it for further use
...
end subroutine needToUSeCommons
Regards,
Arjen
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ThanksArjen! But what I really need is a shared memory (an array with dynamic size), similar to a singleton pattern we can define in JAVA or C++ through "static" decleration. One of my subroutines can be invoked by multiple threads and this is an array I am sharing among them. I doubt that the module-methodology you suggest (which are essencially classes in new Fortran) acts the same way, whereas a COMMON block (though deprecated) does it well. Am I missing something?
Rgds,
HR
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
No, a module variable is a singleton, to use "patternspeak". There can be only one copy in the
entire program. In that way it behaves as a COMMON block - but from the point of view of
robustness and maintainability, it is much more convenient than COMMON blocks as you
define it in one single place and use it anywhere via the USE statement without any chance
of not exactly using the same declarations, as can happen with COMMON blocks.
Regards,
Arjen
entire program. In that way it behaves as a COMMON block - but from the point of view of
robustness and maintainability, it is much more convenient than COMMON blocks as you
define it in one single place and use it anywhere via the USE statement without any chance
of not exactly using the same declarations, as can happen with COMMON blocks.
Regards,
Arjen
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks! Let me modify my code and try it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I created a file (commonVars.f90) and defined a module like this:
[bash]module commonVarsModule CHARACTER::command*200 module commonVarsModule[/bash]
in another file, I have a subroutine using this module as:
[bash]subroutine testSub() !{ !IMPLICIT double precision (A-H,O-Z) use commonVarsModule implicit none command = "" !} end subroutine testSub[/bash]
It is compiled well, but I am getting linker error. Sounds like no where any reference is defined by the fortran compiler.
Umat-Main-Mgr-Test-0032.obj : error LNK2019: unresolved external symbol COMMONVARSMODULE_mp_COMMAND referenced in function TESTSUB
Do I need to define a variable of this type (module) somewhere esplicitly?
Thanks,
HR.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
When you compile the file containing the module, a .MOD file and a .OBJ file are produced. At link time, you should include the .OBJ file in the command line to avoid the "unresolved external symbol" message for the module-level variables.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks. I included both F90 files after ifort command line and it compiled and linked them together.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
May I ask one more question? I would like to statically link the obj files into a single obj file as I need to finally have only a single (stand-alone) obj file. I know I can concatenate themusing "Lib" command, but then I miss the debug-information file (*.pdb) which are creadted along with the obj files in full debug mode. I am using pdb file to debug my code by attaching the runing process to VS2008 debugger. Is it any way to go around this problem?
Thanks,
HR.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm pretty sure that when you build a static library project that all the PDB information gets merged into one PDB file. This would be better than a single .obj.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page