<div class="gmail_quote">On Tue, Sep 20, 2011 at 01:05, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov">bsmith@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"><br>
On Sep 19, 2011, at 4:47 PM, Jed Brown wrote:<br>
<br>
> On Mon, Sep 19, 2011 at 23:29, Mark F. Adams <<a href="mailto:mark.adams@columbia.edu">mark.adams@columbia.edu</a>> wrote:<br>
> An alternative to a virtual function is changing the hash table code:<br>
><br>
> #define HASH_FACT 79943<br>
> #define HASHT(ta,x) ((unsigned long)((HASH_FACT*(unsigned long)x)%ta->tablesize))<br>
><br>
> and make HASH_FACT a variable.  Set HASH_FACT  to 1 if you want an array (and thus the index (x) is less than the table size tablesize).  The index x is one based so the hash function should modified:<br>
><br>
> #define HASHT(ta,x) ((unsigned long)((HASH_FACT*(unsigned long)(x-1))%ta->tablesize))<br>
><br>
> This is an interesting idea. Storage is still double the array, but I think the cases where we want a dense array will generally not be so space limited.<br>
<br>
</div>  It may very well be limiting with MatGetSubMatrix() for VI solvers. In fact we may need yet a different approach to make the MatGetSubMatrix() itself memory scalable for very large problems; that is rather than doing an ISAllGather on the columns it has to be smart about knowing what processes need to know about what columns based on the sparsity of the matrix.<br>
<font color="#888888"><br></font></blockquote><div><br></div><div>Oh, you're working with the global column space? That explains why it's so expensive. This gather is a problem in PCFieldSplit too unless you use MatNest (which should be easy now). VI doesn't have that luxury, so MatGetSubMatrix() needs to get a scalable implementation. Didn't we talk about this several months ago and Dmitry started writing code for it? How did that turn out?</div>
</div>