<div dir="ltr">Thanks Jed, so if I understood correctly in fact there is nothing to be done, since I was already recomputing the staggered values when passing from one node to its neighbour. And good Black Friday to you.<br>

</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Nov 29, 2013 at 4:20 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">"iwaddington ." <<a href="mailto:iwaddington@gmail.com">iwaddington@gmail.com</a>> writes:<br>


<br>
> Hi, I am trying to optimize a code that solves an inhomogeneous laplacian<br>
> pde of the form :<br>
><br>
>        -div ( K(x) grad(u) ) = f           0 < x,y < 1     where K(x) is a<br>
> matrix  that<br>
><br>
> depends   on the position<br>
><br>
>  I use finite differences and the values of "f" and "u" are cell centered.<br>
><br>
>  The problem is the following, since each interface is common to two cells,<br>
> and I need the value of K on the interfaces, which is taken as an harmonic<br>
> mean,<br>
<br>
</div>This is one choice, and not a perfect one.<br>
<div class="im"><br>
> I would like to compute these values only once, and then pass them as<br>
> some user context to KSPSetComputeOperators, because I am using a<br>
> dmda. Any ideas ?<br>
<br>
</div>You can create a DMDA to hold those staggered coefficients.  Note that<br>
it may be faster to just recompute the staggered values from<br>
cell-centered values, since it involves a bit less memory bandwidth, and<br>
memory bandwidth is the main performance bottleneck for these things.<br>
That also makes it easier to choose different flux definitions (e.g.,<br>
for unaligned anisotropy, you'll need at least a 9-point stencil).<br>
</blockquote></div><br></div>