Hi,<div><br></div><div>    I just discovered that the way we assemble our matrix cause a deadlock in MatSetOption</div><div>when petsc is compiled with debugging option enabled.</div><div><br></div><div>I resume :</div><div>
- We loop over elements.</div><div>- For each element we create a small elementary matrix.</div><div>- We assemble the elementary matrix with MatSetValues into the big one.</div><div><br></div><div>Sometimes, we have some rectangular elementary matrix that needs to be added twice,</div>
<div>the second time it is transposed. The big matrix is not symmetric for many possible reasons.</div><div>We are essentially doing it for every elementary matrix that needs it :</div><div><br></div><div>MatSetOption(mat,MAT_ROW_ORIENTED,true)</div>
<div>MatSetValues(...)</div><div><div>MatSetOption(mat,MAT_ROW_ORIENTED,false)</div></div><div><div>MatSetValues(...)</div><div></div></div><div><br></div><div>Of course, it fails (deadlock) in MatSetOption at assertion </div>
<div>PetscValidLogicalCollectiveEnum(mat,op,2);</div><div>because different process don't loop over the same (number of) elements.</div><div>However, it is working fine without the assertion.</div><div><br></div><div>
I have two question :</div><div>Is there really a risk to call MatSetOption(mat, MAT_ROW_ORIENTED, flg) on only one process?</div><div>What can I do now?</div><div><br></div><div>Some possible answer are</div><div>- Close our eyes and stop compiling petsc with debugging option enabled.</div>
<div>- 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.</div><div>- Could MatSetValues has a bonus argument row_oriented?</div>
<div>- Could the assertions in MatSetOption be skipped for some options?</div><div>- Could we add a function MatSetRowOriented which would not be collective?</div><div><br></div><div>thanks,</div><div><br></div><div>Patrick Lacasse</div>