Questions about OPENMP to transfer serial to parallel

[alex]

Hi guys,
First ,I am a newbie to learn how to use openmp for my HPC.
then, I want to ask some questions about the OPENMP:
1) in the case I use 'ifort -openmp -o aim.out script.f90', I must 'use omp_lib' in the script? and the omp_lib is already embeded into ifort compiler? that means, I won't install any omp_lib in my linux platform?
2) I have a program which run by serial means, the construct like the follows:
open(10, file=somefile); open(20, file=anotherfile)
do i = 1, numline !numline is the total lines of the somefile
read(10, format1, iostat=stat) x,y,z
if(stat/=0) exit
call subroutine1(x,y,z,val)
write(20, format2) val
enddo
close(10)
close(20)
like this construct , how can I transfer the loop into parallel programming ?

best wishes to you all
thanks
alex

[alex]

NO One knows how to answer the questions?

[ftinetti]

Hi,

1) in the case I use 'ifort -openmp -o aim.out script.f90', I must 'use omp_lib' in the script?

I was rather confused with the "the script"... I'll assume it's about the script.f90 source file. From the spec.

The OpenMP Fortran API runtime library routines are external procedures. The return
values of these routines are of default kind, unless otherwise specified.
Interface declarations for the OpenMP Fortran runtime library routines described in this
chapter shall be provided in the form of a Fortran include file named omp_lib.h or
a Fortran 90 module named omp_lib.

Thus, if you use runtime library routines in your code, then you should have the corresponding "include" or "use".

1) ... and the omp_lib is already embeded into ifort compiler? that means, I won't install any omp_lib in my linux platform?

Yes (you don't have to install any omp_lib in your platform), it is part of being an "OpenMP compliant" compiler, which ifort is.

<code...>
how can I transfer the loop into parallel programming ?

I think it is not possible to parallelize the loop, specifically

Code: Select all

...
if(stat/=0) exit
...


and, copied from the Spec. (2.5.1 Loop Construct)

Restrictions
Restrictions to the loop construct are as follows:
...
• No statement in the associated loops other than the DO statements can cause a branch
out of the loops.

HTH,

Fernando.

[alex]

Thanks Fernando.
I think it is not possible to parallelize the loop, specifically

Code: Select all
...
if(stat/=0) exit

what you said is right. but
I think the item"if(stat/=0) exit" in the statements is no valid. it will be rid from the statement absolutely like this:

open(10, file=somefile); open(20, file=anotherfile)
do i = 1, numline !numline is the total lines of the somefile
read(10, format1) x,y,z
call subroutine1(x,y,z,val)
write(20, format2) val
enddo
close(10)
close(20)

(where, numline is the total lines of this file, and the scripts is written by f90 format)

and for the upper statement, can you give me some advices how to deal with it?

thanks

[alex]

Hi,

1) in the case I use 'ifort -openmp -o aim.out script.f90', I must 'use omp_lib' in the script?

I was rather confused with the "the script"... I'll assume it's about the script.f90 source file. From the spec.

The OpenMP Fortran API runtime library routines are external procedures. The return
values of these routines are of default kind, unless otherwise specified.
Interface declarations for the OpenMP Fortran runtime library routines described in this
chapter shall be provided in the form of a Fortran include file named omp_lib.h or
a Fortran 90 module named omp_lib.

Thus, if you use runtime library routines in your code, then you should have the corresponding "include" or "use".

1) ... and the omp_lib is already embeded into ifort compiler? that means, I won't install any omp_lib in my linux platform?

Yes (you don't have to install any omp_lib in your platform), it is part of being an "OpenMP compliant" compiler, which ifort is.

<code...>
how can I transfer the loop into parallel programming ?

I think it is not possible to parallelize the loop, specifically

Code: Select all

...
if(stat/=0) exit
...


and, copied from the Spec. (2.5.1 Loop Construct)

Restrictions
Restrictions to the loop construct are as follows:
...
• No statement in the associated loops other than the DO statements can cause a branch
out of the loops.

HTH,

Fernando.

Thanks Fernando.
I think it is not possible to parallelize the loop, specifically

Code: Select all
...
if(stat/=0) exit

what you said is right. but
I think the item"if(stat/=0) exit" in the statements is no valid. it will be rid from the statement absolutely like this:

open(10, file=somefile); open(20, file=anotherfile)
do i = 1, numline !numline is the total lines of the somefile
read(10, format1) x,y,z
call subroutine1(x,y,z,val)
write(20, format2) val
enddo
close(10)
close(20)

(where, numline is the total lines of this file, and the scripts is written by f90 format)

and for the upper statement, can you give me some advices how to deal with it?

thanks

[MarkB]

I would advise splitting your loop so that the I/O is done sequentially and only the subroutine calls are done in parallel (promoting x, y, z, and val to arrays):

do i = 1, numline !numline is the total lines of the somefile
read(10, format1, iostat=stat) x(i),y(i),z(i)
if(stat/=0) exit
enddo

!$omp parallel do
do i = 1, numline
call subroutine1(x(i),y(i),z(i),val(i))
enddo

do i = 1, numline
write(20, format2) val(i)
enddo

[ftinetti]

Hi again,

open(10, file=somefile); open(20, file=anotherfile)
do i = 1, numline !numline is the total lines of the somefile
read(10, format1) x,y,z
call subroutine1(x,y,z,val)
write(20, format2) val
enddo
close(10)
close(20)

(where, numline is the total lines of this file, and the scripts is written by f90 format)

and for the upper statement, can you give me some advices how to deal with it?

I would follow MarkB's advise specifically on avoiding I/O inside threads. I think there are too many issues involved, including "shuffling" the output (in the best case). I do not know about memory issues involved in "promoting x, y, z, and val to arrays" but in the worst case (arrays becoming too large, implying out-of-core computing) you can control memory requirements by reading by a fixed number of lines. As always, the final decision would depend on the computing requirements of subroutine1.

Fernando.

[alex]

Hi again,

open(10, file=somefile); open(20, file=anotherfile)
do i = 1, numline !numline is the total lines of the somefile
read(10, format1) x,y,z
call subroutine1(x,y,z,val)
write(20, format2) val
enddo
close(10)
close(20)

(where, numline is the total lines of this file, and the scripts is written by f90 format)

and for the upper statement, can you give me some advices how to deal with it?

I would follow MarkB's advise specifically on avoiding I/O inside threads. I think there are too many issues involved, including "shuffling" the output (in the best case). I do not know about memory issues involved in "promoting x, y, z, and val to arrays" but in the worst case (arrays becoming too large, implying out-of-core computing) you can control memory requirements by reading by a fixed number of lines. As always, the final decision would depend on the computing requirements of subroutine1.

Fernando.

thanks Fernando, what you said is right! I just have the questions to ask you in two cases:
1.if I came across memory issues that the number of data read is so larger (ex. 20,000,000), and I want to use it again in the next time, so the array(ex. array(20000000, 20) or twenty array(20000000) )will exist in the memory till the next time dealing. that will bring the memory consuming , how to deal with this problem.
2.in the upper cases, in the case that I split the program into several parts(I/O reading, computing(parallel), writing) which abides by your suggestions, but if there exists I/O in the subroutine1 which also exists in the parallel computing block, is there any problems and how to solve this problem?

yours alex

[alex]

I would advise splitting your loop so that the I/O is done sequentially and only the subroutine calls are done in parallel (promoting x, y, z, and val to arrays):

do i = 1, numline !numline is the total lines of the somefile
read(10, format1, iostat=stat) x(i),y(i),z(i)
if(stat/=0) exit
enddo

!$omp parallel do
do i = 1, numline
call subroutine1(x(i),y(i),z(i),val(i))
enddo

do i = 1, numline
write(20, format2) val(i)
enddo

Thanks MarkB for you kind advice.
I just have the questions to ask you and ftinetti for suggestions again in two cases:
1.if I came across memory issues that the number of data read is so larger (ex. 20,000,000), and I want to use it again in the next time, so the array(ex. array(20000000, 20) or twenty array(20000000) )will exist in the memory till the next time dealing. that will bring the memory consuming , how to deal with this problem.
2.in the upper cases, in the case that I split the program into several parts(I/O reading, computing(parallel), writing) which abides by your suggestions, but if there exists I/O in the subroutine1 which also exists in the parallel computing block, is there any problems and how to solve this problem?

yours alex

[ftinetti]

thanks Fernando, what you said is right! I just have the questions to ask you in two cases:
1.if I came across memory issues that the number of data read is so larger (ex. 20,000,000), and I want to use it again in the next time, so the array(ex. array(20000000, 20) or twenty array(20000000) )will exist in the memory till the next time dealing. that will bring the memory consuming , how to deal with this problem.
2.in the upper cases, in the case that I split the program into several parts(I/O reading, computing(parallel), writing) which abides by your suggestions, but if there exists I/O in the subroutine1 which also exists in the parallel computing block, is there any problems and how to solve this problem?

I do not understand 1. would you explain/give other details?
About 2.: if you have I/O in several threads, the minimum I suggest is protecting the I/O with the critical synchronization construct (other issues would depend on the application). However, remember that threads will make interleaved I/O, which, in particular, usually produces different output data (more specifically: the same output in different relative order). Thus, it would be necessary to take into account the interleaved output when reading/using the generated data.

HTH,

Fernando.