Thanks Barry for your answer,<div><br></div><div>Patrick<br><br><div class="gmail_quote">2012/9/20 Barry Smith <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>
   Patrick,<br>
<br>
    We may have gone overboard with our assertions in this routine.<br>
<br>
    Some MatOptions really should be collective while others like the one you are using need not be collective.<br>
<br>
    Simple solution just remove those two collective asserts.  Harder solution, use the asserts for only the options that should be checked. We could for example use less then some number for collective asserts and greater than number for for non collective. A little hacky but would work?<br>

<span class="HOEnZb"><font color="#888888"><br>
   Barry<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On Sep 20, 2012, at 11:42 AM, Patrick Lacasse <<a href="mailto:patrick.m.lacasse@gmail.com">patrick.m.lacasse@gmail.com</a>> wrote:<br>
<br>
> Hi,<br>
><br>
>     I just discovered that the way we assemble our matrix cause a deadlock in MatSetOption<br>
> when petsc is compiled with debugging option enabled.<br>
><br>
> I resume :<br>
> - We loop over elements.<br>
> - For each element we create a small elementary matrix.<br>
> - We assemble the elementary matrix with MatSetValues into the big one.<br>
><br>
> Sometimes, we have some rectangular elementary matrix that needs to be added twice,<br>
> the second time it is transposed. The big matrix is not symmetric for many possible reasons.<br>
> We are essentially doing it for every elementary matrix that needs it :<br>
><br>
> MatSetOption(mat,MAT_ROW_ORIENTED,true)<br>
> MatSetValues(...)<br>
> MatSetOption(mat,MAT_ROW_ORIENTED,false)<br>
> MatSetValues(...)<br>
><br>
> Of course, it fails (deadlock) in MatSetOption at assertion<br>
> PetscValidLogicalCollectiveEnum(mat,op,2);<br>
> because different process don't loop over the same (number of) elements.<br>
> However, it is working fine without the assertion.<br>
><br>
> I have two question :<br>
> Is there really a risk to call MatSetOption(mat, MAT_ROW_ORIENTED, flg) on only one process?<br>
> What can I do now?<br>
><br>
> Some possible answer are<br>
> - Close our eyes and stop compiling petsc with debugging option enabled.<br>
> - We could copy our elementary matrix into a transposed one before to MatSetValues. We don't want do this cause we think it would slow down our code.<br>
> - Could MatSetValues has a bonus argument row_oriented?<br>
> - Could the assertions in MatSetOption be skipped for some options?<br>
> - Could we add a function MatSetRowOriented which would not be collective?<br>
><br>
> thanks,<br>
><br>
> Patrick Lacasse<br>
<br>
</div></div></blockquote></div><br></div>