<div dir="ltr">On Fri, Oct 18, 2013 at 10:15 AM, Shiva Rudraraju <span dir="ltr"><<a href="mailto:rudraa@umich.edu" target="_blank">rudraa@umich.edu</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="im">><span style="font-family:arial,sans-serif;font-size:13px">I did unstructured hexes. You still haven't said what you'll use for </span><span style="font-family:arial,sans-serif;font-size:13px">relaxation. High-order discretizations tend to have poor h-ellipticity, </span><span style="font-family:arial,sans-serif;font-size:13px">so they either need heavy smoothers or a correction based on a </span><span style="font-family:arial,sans-serif;font-size:13px">discretization with better h-ellipticity.</span></div>
<div>
<span style="font-family:arial,sans-serif;font-size:13px">Quite frankly, I was not aware of the poor h-ellipticity of higher order elements and I was assuming I would use the regular GS/GMRES/etc for relaxation. I looked up h-ellipticity of higher order elements and now this adds to my worries :(. I may be asking for too much here.... but what do you mean by heavy smoothers? or </span><span style="font-size:13px;font-family:arial,sans-serif">correction based on a </span><span style="font-size:13px;font-family:arial,sans-serif">discretization?. </span></div>
</div></blockquote><div><br></div><div>By "heavy" Jed means a powerful but expensive solver. By "<span style="font-size:13px;color:rgb(80,0,80);font-family:arial,sans-serif">correction based on a </span><span style="font-size:13px;color:rgb(80,0,80);font-family:arial,sans-serif">discretization" Jed means</span></div>
<div><span style="font-size:13px;color:rgb(80,0,80);font-family:arial,sans-serif">a smoother which is tailored to the specific higher order discretization that probably will not work in the</span></div><div><span style="font-size:13px;color:rgb(80,0,80);font-family:arial,sans-serif">general case (and would need to be coded up).</span></div>
<div><span style="font-size:13px;color:rgb(80,0,80);font-family:arial,sans-serif"><br></span></div><div><span style="font-size:13px;color:rgb(80,0,80);font-family:arial,sans-serif"> Matt</span></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><div class="h5"><div class="gmail_extra"><div class="gmail_quote">On Thu, Oct 17, 2013 at 10:36 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>Shiva Rudraraju <<a href="mailto:rudraa@umich.edu" target="_blank">rudraa@umich.edu</a>> writes:<br>
<br>
> By Spectral Elements I mean spectral quadrilateral/hexahedral elements<br>
> based on tensor product lagrangian polynomials on Gauss Lobatto Legendre<br>
> points.<br>
<br>
</div>Okay "both Lagrange and Spectral elements" sounded like you wanted to<br>
distinguish between two classes of methods.<br>
<div><br>
> >You could reorder your equations, but multicolor GS is not a very good or<br>
> representative algorithm on cache-based architectures, due to its poor<br>
> cache reuse. I suggest just using standard GS smoothers (-pc_type sor with<br>
> default relaxation parameter of 1.0).<br>
> I plan to implement multicolor GS precisely to demonstrate its poor<br>
> performance as compared to other iterative and MG schemes, because in the<br>
> Phase Field community multicolor GS is still quite popular and lingers<br>
> around as a solver. The main point of this work is to clearly demonstrate<br>
> the ill-suitedness of GS for these coupled transport problems.<br>
<br>
</div>Block Jacobi/SOR is still popular and useful.<br>
<div><br>
><br>
> So just wondering if there are any related examples showing multicolor<br>
> GS as a solver. Also, since you mentioned, are there any references<br>
> which demonstrate the poor cache reuse of multicolor GS or is it too<br>
> obvious?... just curious.<br>
<br>
</div>I though multicolor GS mostly died when cache-based architectures beat<br>
out vector machines. One well-optimized application that uses<br>
multicolor GS is FUN3D, but it is doing nonlinear point-block<br>
Gauss-Seidel with a second order residual and first-order correction,<br>
and adds line smoothers for boundary layers.<br>
<div><br>
> Sorry I forgot to mention..... I am only interested in structured quad/hex<br>
> elements. I have my old implementations of higher order Lagrange elements<br>
> and also used deal.ii's Spectral elements.... but for this work I will more<br>
> or less write one from scratch. So any pointers to efficient tensor grid<br>
> FEM implementation will really help me.<br>
<br>
</div>I did unstructured hexes. You still haven't said what you'll use for<br>
relaxation. High-order discretizations tend to have poor h-ellipticity,<br>
so they either need heavy smoothers or a correction based on a<br>
discretization with better h-ellipticity.<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener
</div></div>