<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jan 9, 2021 at 11:14 PM Barry Smith <<a href="mailto:bsmith@petsc.dev">bsmith@petsc.dev</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"><div style="overflow-wrap: break-word;"><div><br></div>  Ok, fieldsplit, pretty much the same as what I said for block Jacobi. <div><br></div><div><div>static PetscErrorCode PCApply_FieldSplit(PC pc,Vec x,Vec y)</div><div>{</div><div>  PC_FieldSplit      *jac = (PC_FieldSplit*)pc->data;</div><div>  PetscErrorCode     ierr;</div><div>  PC_FieldSplitLink  ilink = jac->head;</div><div>  PetscInt           cnt,bs;</div><div><br></div><div>  PetscFunctionBegin;</div><div>  if (jac->type == PC_COMPOSITE_ADDITIVE) {</div><div>    if (jac->defaultsplit) {</div><div>      ierr = VecGetBlockSize(x,&bs);CHKERRQ(ierr);</div><div>      if (jac->bs > 0 && bs != jac->bs) SETERRQ2(PetscObjectComm((PetscObject)pc),PETSC_ERR_ARG_WRONGSTATE,"Blocksize of x vector %D does not match fieldsplit blocksize %D",bs,jac->bs);</div><div>      ierr = VecGetBlockSize(y,&bs);CHKERRQ(ierr);</div><div>      if (jac->bs > 0 && bs != jac->bs) SETERRQ2(PetscObjectComm((PetscObject)pc),PETSC_ERR_ARG_WRONGSTATE,"Blocksize of y vector %D does not match fieldsplit blocksize %D",bs,jac->bs);</div><div>      ierr = VecStrideGatherAll(x,jac->x,INSERT_VALUES);CHKERRQ(ierr);</div><div>      while (ilink) {</div><div>        ierr = PetscLogEventBegin(ilink->event,ilink->ksp,ilink->x,ilink->y,NULL);CHKERRQ(ierr);</div><div>        ierr = KSPSolve(ilink->ksp,ilink->x,ilink->y);CHKERRQ(ierr);</div><div><br></div><div>you need these KSPSolve() to not block which if you are using SuperLU_DIST means each call to </div><div><br></div><div><div> PetscStackCall("SuperLU_DIST:PStatInit",PStatInit(&stat));        /* Initialize the statistics variables. */</div><div>#if defined(PETSC_USE_COMPLEX)</div><div>  PetscStackCall("SuperLU_DIST:pzgssvx",pzgssvx(&lu->options,&lu->A_sup,&lu->ScalePermstruct,(doublecomplex*)bptr,m,1,&lu->grid,&lu->LUstruct,&lu->SOLVEstruct,berr,&stat,&info));</div><div>#else</div><div>  PetscStackCall("SuperLU_DIST:pdgssvx",pdgssvx(&lu->options,&lu->A_sup,&lu->ScalePermstruct,bptr,m,1,&lu->grid,&lu->LUstruct,&lu->SOLVEstruct,berr,&stat,&info));</div><div>#endif</div></div><div><br></div><div>must be on a different stream and cannot block. Which means essentially the PStatInit and pdgssvx have to run completely on the GPU or have some complex CPU babysitting that allows them to be interlaced on the GPU while doing their CPU stuff.  </div></div></div></blockquote><div><br></div><div>It is not clear why the library code would be that complex but I don't understand streams well. SuperLU currently uses Thrust driven by CPU code, but is developing a pure GPU version. I can wait for the pure GPU version.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><div>I doubt either thing is true and you are best off using the cuSparse Solvers which do run completely on the GPU in any stream you give them.</div></div></div></blockquote><div><br></div><div>CUSparse does not have an LU factorization.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><div><br></div><div>The factorization is even more of a nightmare, I think Sherry uses the GPU just to do blocks for her sequential factorization so I doubt very much it can handle multiple simultaneous factorizations. </div></div></div></blockquote><div><br></div><div>Oh you were talking about the solves. (I have only been thinking about factorizations and that has caused some confusion I now see).</div><div><br></div><div>I am still not clear about the parallel dispatch. If an MPI serial library method needs a lot of complex logic to work perhaps look at other models? The XGC code uses OMP a lot and they dispatch asynchronous "solves" in an OMP loop. I'm not sure if being in an OMP thread buys you anything for a GPU solver but this is what they have done for CPU solvers. At one point they used PETSc for a LU solve and we (Barry) made some fixes to make it thread safe enough for this operation, but don't know what GPU "solvers" they have now running in this model on the GPU.</div><div><br></div><div>Regardless, my best guess as the basic model is something like:</div><div><br></div><div>For all blocks i,</div><div>   create a stream i.s, and launch a non-blocking vecScater with i.s</div><div>For all blocks i,<br></div><div>  vecScaterEnd(i),</div><div>  Solve(i.s, ....)  // So library solvers and our built-in solvers would need to take a stream or I guess that would get passed in through Jacob's vector class and the library interface code would need to take the Cuda stream out and give it to SuperLU, say.</div><div>For all blocks i,<br></div><div>  Wait (i.s)</div><div>  vecscatterBegin (i.s, ...)</div><div>For all blocks i,<br></div><div> vecscatterEnd (i.s, ...)  // non-overlapping blocks so problem with adding values</div><div><br></div></div></div>