On Mon, Sep 26, 2011 at 08:21:13PM +0100, Garth N. Wells wrote: > On 26 September 2011 15:21, Andre Massing <mass...@simula.no> wrote: > > On 09/26/2011 01:15 PM, Anders Logg wrote: > >> On Mon, Sep 26, 2011 at 12:06:55AM -0700, Johan Hake wrote: > >>> On Sunday September 25 2011 23:54:57 Anders Logg wrote: > >>>> As part of assembling systems on overlapping meshes (for Nitsche type > >>>> methods), my student Andre Massing is calling the regular DOLFIN > >>>> assemble function for part of the domain and then calling a special > >>>> purpose assembler (currently residing in a branch called dolfin-olm) > >>>> for terms that are not supported by the regular assembler. > >>>> > >>>> For this to work out well, I'd like to propose the following changes > >>>> to the assembler: > >>>> > >>>> 1. Make the assemble_cells, assemble_exterior/interior_facets public > >>>> > >>>> We need to access these separately. > >>>> > >>>> 2. Add options for controlling if and how we call A.apply() > >>> > >>> Wouldn't this be unnesseary if 1 is implemented? Then you just impement > >>> your > >>> own more flexible assemble routine? > >> > >> Good point. > >> > >> Andre: Would that be enough? Note that apply() is not called from the > >> assemble_cells/interior/exterior_facets functions, only from the main > >> (currently public) assemble function. > > > > In principle that would be okay. But it enforces the user > > to reimplement (or basically to copy paste) the entire > > > > void Assembler::assemble(GenericTensor& A, > > const Form& a, > > const MeshFunction<uint>* cell_domains, > > const MeshFunction<uint>* exterior_facet_domains, > > const MeshFunction<uint>* interior_facet_domains, > > bool reset_sparsity, > > bool add_values) > > > > even if the user only wants to first do an regular assemble (via that > > function) and then add/insert manually new entries. > > Top copy paste the entire assemble function just to get rid of one apply > > call at the end seems not to be really user friendly.
I agree that's not optimal, especially since the fix is easy to add and it will be backwards compatible. > > One nice example is the use of the ident_zeros function which as of > > today is "damm" slow :) if there are many zeros along the diagonal. > > That is because the Matrix will be called with an apply() at the end > > of the assemble routine and hence adding values afterwards via > > ident_zeros is very expensive. > > My understanding is that it does not add entries. Someone did add some > hacks which I never understood the need for. A good solution is to not > use Assembler but SystemAssembler. The latter should really be the > default in DOLFIN since it preserves symmetry. > > I haven't tested, but I don't know if, for PETSc, MatZeroRows can be > called post set/insert but pre apply. > > The function Assembler::assemble referred to above could have > something like 'bool finalise_matrix=true' added to the function > signature. I suggest we make it 'bool finalize_tensor=true'. Concerning the flush option to GenericTensor::apply, we already have a "mode" parameter which only has an effect for EpetraMatrix. It is currently ignored by PETScMatrix. The mode parameter can for EpetraMatrix take the values "add" and "insert". I suggest that we add a third option "flush" which would be useful for PETScMatrix. In summary: 1. Make assemble_foo functions public 2. Add optional parameter finalize_tensor=true 3. Check for mode="flush" in PETScMatrix.cpp -- Anders > Garth > > > Naturally a user want to assemble, ident_zeros and then call apply. > > Basically copy pasting the the whole assemble function > > only to omit the postpone the one apply call at the end of assemble > > function seems to be an overkill. > > > > So one thing is the possibility to omit the apply at the end the > > assemble. The other thing is to make assemble_cells, etc. public or > > protected to ease the implementation of new assemblers. As you said > > there are related, but I can think of simple scenarios where a > > completely new assembler is not needed but just a tiny function to add > > some elements. There, the missing option of postponing the apply makes > > it rather cumbersome to reuse the nice functionality which already is > > provided in DOLFIN. > > > > > > > > > > > > > > > > > > > >> > >> > >> > >>> Johan > >>> > >>>> A.apply() calls PETSc MatAssemblyBegin/End with MAT_FINAL_ASSEMBLY. > >>>> This makes it *very* expensive for us since we need to switch between > >>>> inserting and adding values to the matrix. We need to instead use the > >>>> option MAT_FLUSH_ASSEMBLY. It would further be useful to have an > >>>> option of not calling A.apply() at all. > >>>> > >>>> I'm not sure how this should be handled in the GenericTensor interface > >>>> since Trilinos does not seem to have a corresponding option. > >>>> > >>>> A first step would be to just add a boolean option to the assembler: > >>>> > >>>> call_apply=false > >>>> > >>>> Then we could manually flush the values in between calls. > >>>> > >>>> Opinions? > >>>> > >> > >> _______________________________________________ > >> Mailing list: https://launchpad.net/~dolfin > >> Post to : dolfin@lists.launchpad.net > >> Unsubscribe : https://launchpad.net/~dolfin > >> More help : https://help.launchpad.net/ListHelp > > > > > > _______________________________________________ > > Mailing list: https://launchpad.net/~dolfin > > Post to : dolfin@lists.launchpad.net > > Unsubscribe : https://launchpad.net/~dolfin > > More help : https://help.launchpad.net/ListHelp > > > > _______________________________________________ > Mailing list: https://launchpad.net/~dolfin > Post to : dolfin@lists.launchpad.net > Unsubscribe : https://launchpad.net/~dolfin > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : dolfin@lists.launchpad.net Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
