fortran-common-block

Common block and subroutine argument

六眼飞鱼酱① 提交于 2019-12-23 03:41:42
问题 If I have a variable called var which is in a common block named myCB may I use the same name to pass an argument between two other subroutines which are not using the common block myCB ? The code is like below. Subroutine SR1(Var) !something here using Var end Subroutine SR1 Subroutine SR2() .... Call SR1(B) .... end Subroutine SR2 Subroutine SR3() common \myCB\ Var ... ! something using the other Var shared with SR4 ...... end Subroutine SR3 Subroutine SR4() common \myCB\ Var .... ... !

Issue with common block in OpenMP parallel programming

孤者浪人 提交于 2019-12-19 11:43:12
问题 I have a few questions about using common blocks in parallel programming in Fortran. My subroutines have common blocks. Do I have to declare all the common blocks and threadprivate in the parallel do region? How do they pass information? I want seperate common clock for each thread and want them to pass information through the end of parallel region. Does it happen here? My Ford subroutine changes some variables in common blocks and Condact subroutine overwrites over them again but the

Issue with common block in OpenMP parallel programming

心已入冬 提交于 2019-12-19 11:43:06
问题 I have a few questions about using common blocks in parallel programming in Fortran. My subroutines have common blocks. Do I have to declare all the common blocks and threadprivate in the parallel do region? How do they pass information? I want seperate common clock for each thread and want them to pass information through the end of parallel region. Does it happen here? My Ford subroutine changes some variables in common blocks and Condact subroutine overwrites over them again but the

Named common block in a shared library

无人久伴 提交于 2019-12-10 16:00:02
问题 I am encountering a problem when I include a Fortran subroutine in a shared library. This subroutine has a named common block. I have a Fortran main program that uses this common block and links with the shared library. The behavior is that variables in the common block set in either the subroutine or main program are not shared between the two. I am using gfortran 4.9.3 under MinGW on windows. Here are the pieces of my very simple example. Main program: program mainp common/whgc/ivar ivar =

Fortran 77 common blocks in multithreading C++ application

廉价感情. 提交于 2019-12-10 10:34:13
问题 I develop one C++ program which calls a Fortran 77 routine. The main C++ program may run multithreaded. However, it happens that the Fortran 77 routine hides several common blocks which are modified on each call depending on its arguments. I am afraid that all common blocks may be shared between multiple threads and that concurrent accesses to these blocks will probably mess everything. First question : Am I right? Would common blocks be shared between multiple threads? Second question : Is

“Saving” a common block

情到浓时终转凉″ 提交于 2019-12-09 03:13:52
问题 I'm dealing with some legacy code that uses COMMON blocks extensively and sometimes uses the SAVE statement. After consulting the Fortran standard, it says: The appearance of a common block name preceded and followed by a slash in a SAVE statement has the effect of specifying all of the entities in that common block. Under what circumstances does placing a variable in a common block not imply SAVE ? Since the variable must be accessible in any other program unit that includes that common

Common block and subroutine argument

做~自己de王妃 提交于 2019-12-08 11:15:35
If I have a variable called var which is in a common block named myCB may I use the same name to pass an argument between two other subroutines which are not using the common block myCB ? The code is like below. Subroutine SR1(Var) !something here using Var end Subroutine SR1 Subroutine SR2() .... Call SR1(B) .... end Subroutine SR2 Subroutine SR3() common \myCB\ Var ... ! something using the other Var shared with SR4 ...... end Subroutine SR3 Subroutine SR4() common \myCB\ Var .... ... ! something using the other Var shared with SR3 .... end Subroutine SR4 I do have problem with Var passing

Fortran 77 common blocks in multithreading C++ application

这一生的挚爱 提交于 2019-12-06 07:50:13
I develop one C++ program which calls a Fortran 77 routine. The main C++ program may run multithreaded. However, it happens that the Fortran 77 routine hides several common blocks which are modified on each call depending on its arguments. I am afraid that all common blocks may be shared between multiple threads and that concurrent accesses to these blocks will probably mess everything. First question : Am I right? Would common blocks be shared between multiple threads? Second question : Is there a simple way to avoid it? Rewriting the Fortran routines seems unaffordable, I am rather looking

Issue with common block in OpenMP parallel programming

旧城冷巷雨未停 提交于 2019-12-01 13:37:50
I have a few questions about using common blocks in parallel programming in Fortran. My subroutines have common blocks. Do I have to declare all the common blocks and threadprivate in the parallel do region? How do they pass information? I want seperate common clock for each thread and want them to pass information through the end of parallel region. Does it happen here? My Ford subroutine changes some variables in common blocks and Condact subroutine overwrites over them again but the function uses the values from Condact subroutine. Do the second subroutine and function copy the variables

“Saving” a common block

耗尽温柔 提交于 2019-12-01 05:10:31
I'm dealing with some legacy code that uses COMMON blocks extensively and sometimes uses the SAVE statement. After consulting the Fortran standard, it says: The appearance of a common block name preceded and followed by a slash in a SAVE statement has the effect of specifying all of the entities in that common block. Under what circumstances does placing a variable in a common block not imply SAVE ? Since the variable must be accessible in any other program unit that includes that common block, how could it not be SAVE ed? I had to look it up, because I was under the same impression as you are