<div class="gmail_quote">On Thu, Mar 8, 2012 at 07:36, Lorenzo Alessio Botti <span dir="ltr"><<a href="mailto:ihabiamx@yahoo.it">ihabiamx@yahoo.it</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":1e">My strategy is different.<br>
Since I know that I have to evaluate QX at each non-linear iteration instead of communicating QX<br>
I communicate the shape function evaluations on partition interfaces, say SX, once and for all (as soon as the mesh doesn't change).<br></div></blockquote><div><br></div><div>As a matrix? That is a lot of data to store, it's usually faster to recompute. But it's just on subdomain interfaces, so whatever is simpler to code...</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":1e">
So at each iteration I just have to communicate the dofs for each ghost element and I'm able to compute<br>
QX. I do the same for derivatives, I communicate once and for all SDX and evaluate QDX using the dofs.<br>
I assemble both the matrix and the rhs, possibly at the same time to avoid redundant flux evaluations.<br></div></blockquote><div><br></div><div>I just meant evaluating interface fluxes on both processors that see the interface. That redundant evaluation is not a big deal. Also for ghost cells, the mesh data structure is slightly heavier if you need a full level of ghosting. The communication volume for ghost cells versus face traces (QX and QDX) is comparable (depending on element order, dimension, and whether you need QDX).</div>
<div><br></div><div>As for computing the matrix and residual together, the residual is usually much less expensive than the matrix and there are good methods that evaluate residuals more frequently (e.g. Rosenbrock integrators, quasi-Newton accelerated lagging, line searches), so I always write them separately.</div>
</div>