<div class="gmail_quote">2011/4/21 Алексей Рязанов <span dir="ltr"><<a href="mailto:ram@ibrae.ac.ru">ram@ibrae.ac.ru</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div>I think I understand this now. But it seems strange that the DA<b>Get</b>Matrix procedure <b>creates</b> the matrix and I need call the MatDestroy after the "get" proceure to properly free the memory. </div>
</blockquote></div><br><div>Indeed, it should be named DACreateMatrix().</div><div><br></div><div>@petsc-dev</div><div>This comes up way too often and we've all agreed that it should change. Let's do it before 3.2 is released. In what other cases does the following model not hold?</div>
<div><br></div><div>1. XCreateY(X,...,&Y); user has ownership to the new Y and should destroy with YDestroy(Y)</div><div><br></div><div>2. XGetY(X,...,&Y); user has a "cheap" reference to an object owned by X, reference count is not incremented, no need to do anything when the user is done with Y</div>
<div><br></div><div>3. XGetY(X,...,&Y); the new Y may require setup or other resources, user calls XRestoreY(X,...,&Y) when they are finished with Y</div><div><br></div><div><br></div><div>I wish there was a nice naming convention to distinguish 2 from 3, but I think we should shoot for no exceptions to following 1 versus (2,3).</div>
<div><br></div><div>What about MatGetSubMatrix()? For internal use, e.g. in PCFieldSplit, I think that model 3 would be better because it exposes more optimizations when assembly is lagged.</div>