<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic OpenMp turncation error in Intel® MPI Library</title>
    <link>https://community.intel.com/t5/Intel-MPI-Library/OpenMp-turncation-error/m-p/828790#M1286</link>
    <description>If I run this, I can get answers which differ by much more than the last few places! For instance,&lt;BR /&gt;&lt;BR /&gt;$ ifort -o omp omp.f90 -openmp&lt;BR /&gt;$ ./omp &lt;BR /&gt;$ mv pxx pxx.1&lt;BR /&gt;$ ./omp &lt;BR /&gt;$ mv pxx pxx.2&lt;BR /&gt;$ diff pxx.1 pxx.2&lt;BR /&gt;1c1&lt;BR /&gt;&amp;lt; 1 7.66666666666666 &lt;BR /&gt;---&lt;BR /&gt;&amp;gt; 1 7.00000000000000 &lt;BR /&gt;3c3&lt;BR /&gt;&amp;lt; 3 21.2457309961319 &lt;BR /&gt;---&lt;BR /&gt;&amp;gt; 3 18.2457309961319 &lt;BR /&gt;45,47c45,47&lt;BR /&gt;&amp;lt; 45 302.141127347946 &lt;BR /&gt;&amp;lt; 46 308.817226807276 &lt;BR /&gt;&amp;lt; 47 315.493163426717 &lt;BR /&gt;---&lt;BR /&gt;&amp;gt; 45 272.141127347946 &lt;BR /&gt;&amp;gt; 46 278.150560140610 &lt;BR /&gt;&amp;gt; 47 268.493163426717 &lt;BR /&gt;...&lt;BR /&gt;&lt;BR /&gt;The problem here is in how you're updating the array a:&lt;BR /&gt;!$omp parallel do default(shared) private(i,j)&lt;BR /&gt; do j=1,20 &lt;BR /&gt;  do i=1,9999&lt;BR /&gt;   a(i)=a(i)+i/3.d0&lt;BR /&gt;  enddo&lt;BR /&gt; enddo&lt;BR /&gt;!$omp end parallel do&lt;BR /&gt;&lt;BR /&gt;The loop over j is being broken up into different pieces and assigned to different threads. However, each thread then executes the 'i' loop. This means that potentially many different threads are updating the same a(i) at the same time - a classic example of "a race condition", one of the most common sorts of parallel programming error.&lt;BR /&gt;&lt;BR /&gt;In this particular example, there is a very simple solution; just by flipping the order of the loops, we avoid this:&lt;BR /&gt;&lt;BR /&gt;!$omp parallel do default(shared) private(i,j)&lt;BR /&gt; do i=1,9999&lt;BR /&gt; do j=1,20 &lt;BR /&gt;  a(i)=a(i)+i/3.d0&lt;BR /&gt;  enddo&lt;BR /&gt; enddo&lt;BR /&gt;!$omp end parallel do&lt;BR /&gt;&lt;BR /&gt;In this case, the loop over *i* is split up over threads, so now the different threads are working on independant pieces of a - so there is no longer a race condition, and the results end up being consistent:&lt;BR /&gt;&lt;BR /&gt;$ ifort -o omp omp.f90 -openmp&lt;BR /&gt;$ ./omp &lt;BR /&gt;$ mv pxx pxx.1&lt;BR /&gt;$ ./omp &lt;BR /&gt;$ mv pxx pxx.2&lt;BR /&gt;$ diff pxx.1 pxx.2&lt;BR /&gt;$&lt;BR /&gt;&lt;BR /&gt;Note too that running a case two times and getting the same answer both times doesn't prove there's no race conditions - some can be very subtle and only show up one time in a million.  Intel has development tools available which can help you analyze your code and look for such issues. Any time, as here, you're modifying a shared data structure like the array a, you must be quite sure that there is no way that multiple threads will be modifying the same piece at the same time. (For just this reason, in fact, I prefer that my students don't use the default(shared) construct at all - default(none), much like implicit none in Fortran, is clearly the way to go, as one must make explicit declarations about how each structure is being used. Here, listing shared(a) would make very clear the issues...)&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;</description>
    <pubDate>Mon, 06 Sep 2010 19:18:31 GMT</pubDate>
    <dc:creator>jonathandursi</dc:creator>
    <dc:date>2010-09-06T19:18:31Z</dc:date>
    <item>
      <title>OpenMp turncation error</title>
      <link>https://community.intel.com/t5/Intel-MPI-Library/OpenMp-turncation-error/m-p/828789#M1285</link>
      <description>&lt;B&gt;OpenMp turncation error&lt;/B&gt;&lt;BR /&gt;&lt;HR size="1" /&gt;Hi,&lt;BR /&gt;Im quite new to
openMP and I found that the results of the serial and parallel version
of the following code has a difference at the last decimalplace.&lt;BR /&gt;&lt;BR /&gt;I use intel fortran compiler in an intel 64 bit machine under fedora 10.&lt;BR /&gt;&lt;BR /&gt;Can anybody pls tell me a way how can this be elminated. &lt;BR /&gt;&lt;BR /&gt;----------------------------------------------------------------------------&lt;BR /&gt;program main&lt;BR /&gt; implicit none &lt;BR /&gt; integer i,j,l&lt;BR /&gt; double precision a(9999)&lt;BR /&gt;&lt;BR /&gt;c initialisation&lt;BR /&gt; do i=1,9999&lt;BR /&gt; a(i)=i**(.2)&lt;BR /&gt; enddo&lt;BR /&gt;----------------------------------------------------------  &lt;BR /&gt;!$omp parallel do default(shared) private(i,j)&lt;BR /&gt; do j=1,20 &lt;BR /&gt;  do i=1,9999&lt;BR /&gt;  a(i)=a(i)+i/3.d0&lt;BR /&gt;  enddo&lt;BR /&gt; enddo&lt;BR /&gt;!$omp end parallel do&lt;BR /&gt;-----------------------------------------------------------&lt;BR /&gt; &lt;BR /&gt;open(file='pxx',unit=30)&lt;BR /&gt; do i=1,9999&lt;BR /&gt; write(30,*) i,a(i)&lt;BR /&gt; enddo&lt;BR /&gt;&lt;BR /&gt; end&lt;BR /&gt;-----------------------------------------------------------&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;here is some sample result comparison. &lt;BR /&gt;9959c9959&lt;BR /&gt;&amp;lt; 9959 66399.6377247174 &lt;BR /&gt;---&lt;BR /&gt;&amp;gt; 9959 66399.6377247175 &lt;BR /&gt;9973c9973&lt;BR /&gt;&amp;lt; 9973 66492.9728295009 &lt;BR /&gt;---&lt;BR /&gt;&amp;gt; 9973 66492.9728295008 &lt;BR /&gt;9980c9980&lt;BR /&gt;&amp;lt; 9980 66539.6403811772 &lt;BR /&gt;---&lt;BR /&gt;&amp;gt; 9980 66539.6403811773 &lt;BR /&gt;9985c9985&lt;BR /&gt;&amp;lt; 9985 66572.9743463199 &lt;BR /&gt;---&lt;BR /&gt;&amp;gt; 9985 66572.9743463198 &lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Mon, 06 Sep 2010 17:41:24 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-MPI-Library/OpenMp-turncation-error/m-p/828789#M1285</guid>
      <dc:creator>chat1983</dc:creator>
      <dc:date>2010-09-06T17:41:24Z</dc:date>
    </item>
    <item>
      <title>OpenMp turncation error</title>
      <link>https://community.intel.com/t5/Intel-MPI-Library/OpenMp-turncation-error/m-p/828790#M1286</link>
      <description>If I run this, I can get answers which differ by much more than the last few places! For instance,&lt;BR /&gt;&lt;BR /&gt;$ ifort -o omp omp.f90 -openmp&lt;BR /&gt;$ ./omp &lt;BR /&gt;$ mv pxx pxx.1&lt;BR /&gt;$ ./omp &lt;BR /&gt;$ mv pxx pxx.2&lt;BR /&gt;$ diff pxx.1 pxx.2&lt;BR /&gt;1c1&lt;BR /&gt;&amp;lt; 1 7.66666666666666 &lt;BR /&gt;---&lt;BR /&gt;&amp;gt; 1 7.00000000000000 &lt;BR /&gt;3c3&lt;BR /&gt;&amp;lt; 3 21.2457309961319 &lt;BR /&gt;---&lt;BR /&gt;&amp;gt; 3 18.2457309961319 &lt;BR /&gt;45,47c45,47&lt;BR /&gt;&amp;lt; 45 302.141127347946 &lt;BR /&gt;&amp;lt; 46 308.817226807276 &lt;BR /&gt;&amp;lt; 47 315.493163426717 &lt;BR /&gt;---&lt;BR /&gt;&amp;gt; 45 272.141127347946 &lt;BR /&gt;&amp;gt; 46 278.150560140610 &lt;BR /&gt;&amp;gt; 47 268.493163426717 &lt;BR /&gt;...&lt;BR /&gt;&lt;BR /&gt;The problem here is in how you're updating the array a:&lt;BR /&gt;!$omp parallel do default(shared) private(i,j)&lt;BR /&gt; do j=1,20 &lt;BR /&gt;  do i=1,9999&lt;BR /&gt;   a(i)=a(i)+i/3.d0&lt;BR /&gt;  enddo&lt;BR /&gt; enddo&lt;BR /&gt;!$omp end parallel do&lt;BR /&gt;&lt;BR /&gt;The loop over j is being broken up into different pieces and assigned to different threads. However, each thread then executes the 'i' loop. This means that potentially many different threads are updating the same a(i) at the same time - a classic example of "a race condition", one of the most common sorts of parallel programming error.&lt;BR /&gt;&lt;BR /&gt;In this particular example, there is a very simple solution; just by flipping the order of the loops, we avoid this:&lt;BR /&gt;&lt;BR /&gt;!$omp parallel do default(shared) private(i,j)&lt;BR /&gt; do i=1,9999&lt;BR /&gt; do j=1,20 &lt;BR /&gt;  a(i)=a(i)+i/3.d0&lt;BR /&gt;  enddo&lt;BR /&gt; enddo&lt;BR /&gt;!$omp end parallel do&lt;BR /&gt;&lt;BR /&gt;In this case, the loop over *i* is split up over threads, so now the different threads are working on independant pieces of a - so there is no longer a race condition, and the results end up being consistent:&lt;BR /&gt;&lt;BR /&gt;$ ifort -o omp omp.f90 -openmp&lt;BR /&gt;$ ./omp &lt;BR /&gt;$ mv pxx pxx.1&lt;BR /&gt;$ ./omp &lt;BR /&gt;$ mv pxx pxx.2&lt;BR /&gt;$ diff pxx.1 pxx.2&lt;BR /&gt;$&lt;BR /&gt;&lt;BR /&gt;Note too that running a case two times and getting the same answer both times doesn't prove there's no race conditions - some can be very subtle and only show up one time in a million.  Intel has development tools available which can help you analyze your code and look for such issues. Any time, as here, you're modifying a shared data structure like the array a, you must be quite sure that there is no way that multiple threads will be modifying the same piece at the same time. (For just this reason, in fact, I prefer that my students don't use the default(shared) construct at all - default(none), much like implicit none in Fortran, is clearly the way to go, as one must make explicit declarations about how each structure is being used. Here, listing shared(a) would make very clear the issues...)&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Mon, 06 Sep 2010 19:18:31 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-MPI-Library/OpenMp-turncation-error/m-p/828790#M1286</guid>
      <dc:creator>jonathandursi</dc:creator>
      <dc:date>2010-09-06T19:18:31Z</dc:date>
    </item>
    <item>
      <title>OpenMp turncation error</title>
      <link>https://community.intel.com/t5/Intel-MPI-Library/OpenMp-turncation-error/m-p/828791#M1287</link>
      <description>Than you very much for your comprehensive answer.I could correct the error thanks to you. also many thanks for your advices as well.</description>
      <pubDate>Tue, 07 Sep 2010 12:43:15 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-MPI-Library/OpenMp-turncation-error/m-p/828791#M1287</guid>
      <dc:creator>chat1983</dc:creator>
      <dc:date>2010-09-07T12:43:15Z</dc:date>
    </item>
  </channel>
</rss>

