<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Dec 31, 2020 at 5:23 PM Jed Brown <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Stefano Zampini <<a href="mailto:stefano.zampini@gmail.com" target="_blank">stefano.zampini@gmail.com</a>> writes:<br>
<br>
> You should swap fieldsplit and ASM<br>
><br>
> -pc_type fieldsplit<br>
> -fieldsplit_0_pc_type asm<br>
<br>
Note that this incurs separate communication for each split. If you nest them the other way, there would be one heavy communication and then a bunch of local work. This latency impact may not matter as much when you're already launching GPU kernels for the local work, though the communication to/from device memory is also expensive. <br></blockquote><div><br></div><div>This is one processor, but I don't know what you mean by 'the other way'. I did try making one field with a 10D vector but DM died on that.</div><div><br></div><div>I am now thinking that I could assemble factorization matrices at the same time as the operator matrix, on the GPU, and then stuff them into ASM or factor them and then stuff if ASM can not drive parallel GPU factoring. I hope that we can come up with a coherent model but I do want to get this done in early April for SC.</div><div><br></div><div>Thanks,</div><div> </div></div></div>