David, Thank you for your help. I have this part working now. I will likely need to be optimize this more, but not at the present.
-Brent On Tue, 13 Jan 2009 16:32:47 -0500, David Knezevic <[email protected]> wrote: > When assemble_before_solve==true, you have to call > attach_assemble_function(fptr ), where fptr is a pointer to the assembly > function (have a look at the examples to understand that better). Then > in that case when you call system.solve(), system knows to call the > assembly function before it tries to solve. > > When assemble_before_solve==false, you just have to call the assemble > function yourself, direction, i.e.: > assemble_matrix(equation_systems,"MySystem"); > assemble_rhs(equation_systems,"MySystem"); > > You can call these yourself whenever you need them (note that as Roy and > John pointed out, this can all be done just as well using boolean flags > that prevent unnecessary assembling). > > Also, you may need to call system.rhs->zero(); before each assembly loop > for the rhs, I can't recall whether or not the matrix/rhs gets zeroed > automatically when assemble_before_solve==false. > > - Dave > > > Brent Kraczek wrote: >> David (or anyone else), >> >> I've been trying to figure out how to do this. But I'm still getting >> stuck with the rhs assembly. I have been working backward through the >> various function calls for what it does when >> assemble_before_solve==true >> but I can't figure out how the code figures out which assemble function >> to call. >> >> How would you recommend that I assemble only the RHS? >> >> Thanks, >> Brent >> >> >> >> David Knezevic wrote: >>> Hi Brent, >>> >>> You should set system.assemble_before_solve = false to tell libMesh >>> not to reassemble the system matrix each time you call solve(). >>> Instead, you'll have to call your matrix assemble function yourself >>> just once (before you try to solve, of course). Also, define a >>> separate assembly function for the right-hand side and you can call >>> that each time you need a new rhs. >>> >>> As to the solves themselves, in the past I've done some computations >>> with the raw PETSc KSP (Krylov subspace) object and I believe in your >>> situation you can get some savings if you just set the KSP Operator >>> (i.e. the system matrix) once, but it looks to me that libMesh makes >>> the call KSPSetOperators(ksp,A,A,SAME_NONZERO_PATTERN) on each call to >>> solve, so unless you want to delve down into the library a bit, I'd >>> recommend you just use the assemble_before_solve flag. >>> >>> - Dave >>> >>> >>> Brent Kraczek wrote: >>>> Dear all, >>>> >>>> I am trying to set-up a simple poisson system where I will change my >>>> RHS repeatedly, but the main system matrix will not change, so it >>>> will only need to be inverted once. I have been looking through the >>>> class definition for LinearImplicitSystem and its parent classes, but >>>> I don't see how to implement this. (I did run across a comment about >>>> multiple RHS in regard to the variable assemble_before_solve, but >>>> it's still not clear to me.) >>>> >>>> Is there an example of this, or could you point me toward which >>>> member functions to use to accomplish this? >>>> >>>> >>>> Thanks, >>>> Brent >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> This SF.net email is sponsored by: >>>> SourcForge Community >>>> SourceForge wants to tell your story. >>>> http://p.sf.net/sfu/sf-spreadtheword >>>> _______________________________________________ >>>> Libmesh-users mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/libmesh-users >>>> >>> >> >> > ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
