OpenMP® Forum

Discussion on the OpenMP specification run by the OpenMP ARB. OpenMP and the OpenMP logo are registered trademarks of the OpenMP Architecture Review Board in the United States and other countries. All rights reserved.

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 ?

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 returnvalues of these routines are of default kind, unless otherwise specified.Interface declarations for the OpenMP Fortran runtime library routines described in thischapter shall be provided in the form of a Fortran include file named omp_lib.h ora 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.

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 returnvalues of these routines are of default kind, unless otherwise specified.Interface declarations for the OpenMP Fortran runtime library routines described in thischapter shall be provided in the form of a Fortran include file named omp_lib.h ora 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.

(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.

(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?

MarkB wrote: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 somefileread(10, format1, iostat=stat) x(i),y(i),z(i)if(stat/=0) exitenddo

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

do i = 1, numlinewrite(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?

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.