On 6/2/10 6:03 PM, Roy Stogner wrote: > > On Wed, 2 Jun 2010, Boyce Griffith wrote: > >> On 6/2/10 3:52 PM, Boyce Griffith wrote: >> >> Alternatively, I wonder if the interface might be clearer if assembly >> and ghost-filling were separate member functions, although that change >> would have the potential to wreak havoc on application codes. > > We did have those as separate functions before - the assembly gets > done on a PARALLEL vector like solution and then localized onto a > separate SERIAL vector like current_local_solution. But our end goal > is to get rid of the underlying current_local_solution data storage, > and leave it as an interface to a ghosted solution for backwards > compatibility. I don't see any advantage to keeping those two steps > separate, but I may be missing something obvious.
This is probably a minor performance optimization, but it seems like there are some cases where assembly doesn't really require ghost synchronization, and some cases where it might be desirable to do ghost synchronization but where there might be nothing to assemble. For example, just before a solve, you probably want to assemble the RHS but may not need to re-fill its ghost values. Likewise, just after a linear solve, you probably don't have anything to assemble for a solution vector but may need to re-fill its ghost values, e.g., to compute quantities required for the next solve in a time-dependent problem. I may be mistaken, but I think that VecAssemblyBegin/VecAssemblyEnd involve some parallel communication, even when there is nothing to be done, and I am fairly sure that VecGhostUpdateBegin/VecGhostUpdate will re-send ghost values even for vectors whose values have not changed since the previous VecGhostUpdateBegin/VecGhostUpdate. Are these hugely expensive "no-ops"? I would guess probably not, but I don't know. -- Boyce ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
