Omp

[jguterl]

Implementation of OpenMP directives in the Fortran module generator (in wrappergenerator.c only, not implemented for derived types).
New Function: Read an input file which contains the list of variables which are:

1. declared threadprivate in the module where they are declared
2. added to initialization/clear routines where they are associated/cleared (if pointer) and initialized in each thread
3. add to copy routines created for each package where variables from the master thread are copied into variables in each thread (equivalent to an OpenMP directive copyprivate).
   New Forthon flags:
   --omppackage XXX,YYY,ZZZ : looks to implement omp directives for packages XXX,YYY,ZZZ
   --ompvarlistfile path/to/list.txt : where list.txt is a single column/multiple rows ascii file containing a list of variables which will be treated as threadprivate
   --ompverbose : Verbose mode
   --ompforceall : all variables declared in modules built with Forthon will be declared threadprivate(for debug purpose only, use with caution)

Tested only for UEDGE

[dpgrote]

Thanks for the changes. There's a lot here and it'll take a bit of time to understand what it is doing. Something that would be very helpful is to add general comments to the code describing what the additions are doing. For example, what is the function writef90ompcopyhelper doing and why are the OmpCopy modules needed?

I do have some general questions. Will the list of variables change? If it is a static list (for each package), could this be handled by using variables attribute instead of having a separate file listing the variables?

Is the ompackage needed, since each call to Forthon is creating one package?

Unfortunately, however, Forthon still needs to support python2. I know you put in some work to convert the code to python3, but I can't accept those changes. Please only make changes in parts of the code that are relevant to the main changes. With many small changes elsewhere, it makes it difficult to verify the changes and could lead to unexpected subtle bugs. I would much prefer multiple small PRs rather than one big one.

[jguterl]

- Sorry for the big commit. I have not cleaned up my additions yet. I just wanted to push what I have to start a discussion. I will edit this commit to make it more readible. Please - Everything that I added in the core of the wrapper is wrapped with if statements so that when omp is not requested, it should be not modified at all the behavior of Forthon. I will reorganize this commit to make it easier to verify. - The omppackage flag was initially intended for allowing multiple lists of variables which need to be threadprivate and in case of the same variable name is used in more than one package when using a single list. For UEDGE, I think there was one instance where the same variable name was used in two different packages. If you want to do a zoom meeting to discuss in person some details, you can find me with guterlj@fusion.gat.com

…

On Tue, Apr 14, 2020 at 6:06 PM David Grote ***@***.***> wrote: Thanks for the changes. There's a lot here and it'll take a bit of time to understand what it is doing. Something that would be very helpful is to add general comments to the code describing what the additions are doing. For example, what is the function writef90ompcopyhelper doing and why are the OmpCopy modules needed? I do have some general questions. Will the list of variables change? If it is a static list (for each package), could this be handled by using variables attribute instead of having a separate file listing the variables? Is the ompackage needed, since each call to Forthon is creating one package? Unfortunately, however, Forthon still needs to support python2. I know you put in some work to convert the code to python3, but I can't accept those changes. Please only make changes in parts of the code that are relevant to the main changes. With many small changes elsewhere, it makes it difficult to verify the changes and could lead to unexpected subtle bugs. I would much prefer multiple small PRs rather than one big one. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#21 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEESMZDGAUTIJB64PD7WXQDRMUB75ANCNFSM4MIEE52Q> .

[jguterl]

Hello, I send a pull request for a clean addition of the openmp features to Forthon. I hope this is clear enough without documentation. I haven't look up whether it allows backward compatibility with python 2. Maybe that can be dealt with an if condition for the print statements (these are the only statement raising error when compiling with python3)? On Tue, Apr 14, 2020 at 6:27 PM Jerome Guterl <guterlj@fusion.gat.com> wrote:

…

- Sorry for the big commit. I have not cleaned up my additions yet. I just wanted to push what I have to start a discussion. I will edit this commit to make it more readible. Please - Everything that I added in the core of the wrapper is wrapped with if statements so that when omp is not requested, it should be not modified at all the behavior of Forthon. I will reorganize this commit to make it easier to verify. - The omppackage flag was initially intended for allowing multiple lists of variables which need to be threadprivate and in case of the same variable name is used in more than one package when using a single list. For UEDGE, I think there was one instance where the same variable name was used in two different packages. If you want to do a zoom meeting to discuss in person some details, you can find me with ***@***.*** On Tue, Apr 14, 2020 at 6:06 PM David Grote ***@***.***> wrote: > Thanks for the changes. There's a lot here and it'll take a bit of time > to understand what it is doing. Something that would be very helpful is to > add general comments to the code describing what the additions are doing. > For example, what is the function writef90ompcopyhelper doing and why are > the OmpCopy modules needed? > > I do have some general questions. Will the list of variables change? If > it is a static list (for each package), could this be handled by using > variables attribute instead of having a separate file listing the variables? > > Is the ompackage needed, since each call to Forthon is creating one > package? > > Unfortunately, however, Forthon still needs to support python2. I know > you put in some work to convert the code to python3, but I can't accept > those changes. Please only make changes in parts of the code that are > relevant to the main changes. With many small changes elsewhere, it makes > it difficult to verify the changes and could lead to unexpected subtle > bugs. I would much prefer multiple small PRs rather than one big one. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#21 (comment)>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AEESMZDGAUTIJB64PD7WXQDRMUB75ANCNFSM4MIEE52Q> > . >