<div dir="ltr"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Thank you for your answer,</span><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial">I am not responsible for the choices in this code to begin with, but in any case, as you can see in the example, I am not using any petsc call. Also in our code, even though openmp is used, this is never in interaction with petsc, the latter being used only at a specific (but crucial) place in the code, and without openMP. In that sense, the model we are using is NOT some 'Petsc with threads model', as described in the page you sent me. Nevertheless, it appears that just linking petsc is enough to perturb the behavior of openMP. I believe it may require further investigation. On top of the bug I report in my first message, I have noticed very weird openMP behavior lately, the kind of bugs that 'don't make sense' at first sight (would be too long/boring to give details at this stage). I am starting to realize that it may have something to do with petsc.</div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial">Again, the webpage you have sent me seems to adopt the point of view that hybrid MPI/openMP is useless from the performance point of view, and/or that Petsc routines should not be threaded. It does not, however, explain why the behaviour of openMP may be changed by merely linking a program with petsc, without a single petsc call in the program.</div><br><div>Best</div></div><div class="gmail_extra"><br><div class="gmail_quote">2018-01-30 18:02 GMT+01:00 Smith, Barry F. <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
  I don't know what you are trying to do with OpenMP and PETSc, nor do I understand why anyone would use OpenMP, but you cannot call virtually any PETSc function or operation while you are using threads.<br>
<br>
  Best to use PETSc as intended, with one MPI process per core or hardware thread and not use OpenMP at all. <a href="http://www.mcs.anl.gov/petsc/miscellaneous/petscthreads.html" rel="noreferrer" target="_blank">http://www.mcs.anl.gov/petsc/<wbr>miscellaneous/petscthreads.<wbr>html</a><br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
  Barry<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
> On Jan 30, 2018, at 10:57 AM, Timothée Nicolas <<a href="mailto:timothee.nicolas@gmail.com">timothee.nicolas@gmail.com</a>> wrote:<br>
><br>
> Dear petsc team,<br>
><br>
> For a while, I have been wondering why I have never managed to print what threads are doing in an openMP region in my FORTRAN programs. Some people told me it was normal because threads will get confused all trying to write at the same time. However I realised today that the problem seems to be related to petsc. I have a super simple "hello world" example that reproduces the problem :<br>
><br>
> program hello<br>
>   !$ use omp_lib<br>
>   implicit none<br>
>   integer nthreads, tid<br>
><br>
>   !$omp parallel private(nthreads, tid)<br>
>   tid = omp_get_thread_num()<br>
>   print *, 'hello world from thread = ', tid<br>
><br>
>   if (tid .eq. 0) then<br>
>      nthreads = omp_get_num_threads()<br>
>      print *, 'number of threads = ', nthreads<br>
>   end if<br>
>   !$omp end parallel<br>
><br>
> end program hello<br>
><br>
> If I compile it with<br>
><br>
> mpif90 -qopenmp -o omp main.f90<br>
><br>
> Then I get no problem. But if I link petsc library (as is the case in my code) :<br>
><br>
> mpif90 -qopenmp -o omp main.f90 -L/home/timotheenicolas/petsc-<wbr>3.7.3/arch-linux2-c-debug/lib -lpetsc<br>
><br>
><br>
> Then I get the following error after execution of export OMP_NUM_THREADS=2;./omp<br>
><br>
>  hello world from thread =            0<br>
>  number of threads =            2<br>
> forrtl: severe (40): recursive I/O operation, unit -1, file unknown<br>
> Image              PC                Routine            Line        Source<br>
> omp                0000000000403BC8  Unknown               Unknown  Unknown<br>
> omp                0000000000403572  Unknown               Unknown  Unknown<br>
> libiomp5.so        00002AAAAD3146A3  Unknown               Unknown  Unknown<br>
> libiomp5.so        00002AAAAD2E3007  Unknown               Unknown  Unknown<br>
> libiomp5.so        00002AAAAD2E26F5  Unknown               Unknown  Unknown<br>
> libiomp5.so        00002AAAAD3149C3  Unknown               Unknown  Unknown<br>
> libpthread.so.0    00002AAAAD5BADC5  Unknown               Unknown  Unknown<br>
> libc.so.6          00002AAAAD8C5CED  Unknown               Unknown  Unknown<br>
><br>
><br>
> This means that in my programs using petsc, I can't use prints to see exactly what the threads are doing, which is a pain when debug is required (that is to say, all the time). Is this issue expected ?<br>
><br>
> Thx in advance<br>
><br>
> Timothee NICOLAS<br>
><br>
<br>
</div></div></blockquote></div><br></div>