<div dir="ltr">Hi Peter<div><br></div><div>Thanks for the info. I actually already have a coloring that is done through the discretrization that is near optimal. The issue is that I have a funny interprocessor dependence that is tricky to do my own sequential coloring. So I was looking at doing it in a global, parallel sense. For interest, I tried using the matGetColor() on my assembled matrix just to see how many colors it would take. My discretrization coloring has 35 colors (for a stencil with 33 cells) and the matGetColor() resulted in approximately 78 colors or about twice as many. </div>
<div><br></div><div>Thanks,</div><div><br></div><div>Gaetan</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Nov 5, 2013 at 11:39 AM, Peter Brune <span dir="ltr"><<a href="mailto:brune@mcs.anl.gov" target="_blank">brune@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="im">On Tue, Nov 5, 2013 at 10:29 AM, Gaetan Kenway <span dir="ltr"><<a href="mailto:gaetank@gmail.com" target="_blank">gaetank@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi <div><br></div><div>I have a quick question regarding the MatGetColoring() function. According to the documentation, </div>

<div><br></div><div> "For parallel matrices currently converts to sequential matrix and uses the sequential coloring on that."</div>

<div><br></div></div></blockquote><div><br></div></div><div>The meaning of this is that it transfers the parallel matrix to a single processor and does the coloring there, not that it only considers on-processor entries.  What comes out is therefore a valid column coloring of the whole matrix.  Parallel matrix coloring is in development but is not quite ready for public consumption.  Anecdotal evidence suggests that the serial coloring does not become a bottleneck on small parallel runs.</div>

<div><br></div><div>A good option is to provide the coloring through your discretization.  This will often be more efficient than the matrix colorings, as you know the structure of your problem.</div><span class="HOEnZb"><font color="#888888"><div>
<br></div><div>- Peter</div></font></span><div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>I am wondering does this give actually give a valid parallel coloring? My application is a cell centered multi-block finite volume code, (with block-based decomposition)  and the communications are done using a two level exchange of halo cells. I would like to use FD (actually forward mode AD to compute the jacbian matrix). So, what I'm wondering is, if a cell with color 0 is perturbed on processor 0, is it guaranteed that a residual on processor 1, that is influenced by the 0-colored cell on proc zero is *only* influenced by the color 0 from proc 0 and not a 0-colored cell on proc 1?</div>


<div><br></div><div>I hope that is clear</div><div><br></div><div>Thank you,</div><div><br></div><div>Gaetan Kenway</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div>
</blockquote></div></div><br></div></div>
</blockquote></div><br></div>