Thanks Ben and Roy, I'll have a go at it tomorrow.
Kirk, Benjamin (JSC-EG311) wrote:
>> - Add a new enum SCALAR to FEFamily (or alternatively, a new enum SCALAR
>> to Order)?
> Something like that sounds good... This is a single scalar value coupled to
> *all* other DOFs?
>> - Short circuit all the loops over elements for DOF counting in DofMap
>> for SCALAR variables, and instead store the dof index of each SCALAR
>> variable in a vector in DofMap?
> I would think the DofMap needs to store a vector of scalar indices, yeah....
>> - However, I can't see where in the code one should compute the dof
>> index of a SCALAR variable in the first place?
> Well, after the typical dof indexing each processor knows the local number
> of Dofs and their global Dof indices, [0, n_global_dofs) so don't the
> scalars get numbered sequentially in
> [n_global_dofs, n_global_dofs+n_scalars) ?
>> - Ben, regarding setting the nonzero count and the number of rows that
>> you mentioned; where is this controlled? In SparsityPattern?
> Yeah, the sparsity pattern is constructed, potentially handed off to
> initialize matrices, then the nonzeros are counted, and it is removed to
> save storage.
> Everything should fall through provided:
> (1) DofMap::dof_indices() tacks on the scalar indices for an element when it
> is called, since you are expecting them to be coupled to all elemend dofs,
> (2) n_scalar additional, *full* rows are added at the end of the sparsity
> I think it would be pretty easy to code up and try in serial, not sure at
> what point in parallel we will need to get smarter with the load balancing.
> probably round-robbin'ing the scalars across processors is a better idea
> than putting them continuously at the end, and thus in the last processor's
> So at the end of the sparsity pattern construction we a