Hi John,
the function is there and can be used, but not for hp::DoFHandler yet.
Maybe you can try to implement it for hp::DoFHandler yourself. Feel free
to ask if you need some help. I would be happy to help.
Bärbel
--
Bärbel Janssen
Institut für Angewandte Mathematik
Universität Heidelberg
Im Neuenheimer Feld 293, Raum 213
Telefon: +49 6221 54-5449
On Wed, 8 Sep 2010, Bärbel Janssen wrote:
Hi John,
yes, Martin and I we finished the make_flux_sparsity_pattern function. Please
give me a sec and I try to check it in. I will let you know then.
Bärbel
--
Bärbel Janssen
Institut für Angewandte Mathematik
Universität Heidelberg
Im Neuenheimer Feld 293, Raum 213
Telefon: +49 6221 54-5449
On Wed, 8 Sep 2010, John Chapman wrote:
Hi Martin,
You asked two questions, which I'll answer in turn. There was an exception
thrown, namely
An error occurred in line <466> of file
</extra/tmp/dealii_6.3.1/deal.II/lac/include/lac/sparse_matrix.templates.h>
in function
void dealii::SparseMatrix<number>::add(unsigned int, unsigned int, const
unsigned int*, const number2*, bool, bool) [with number2 = double, number =
double]
The violated condition was:
counter < cols->row_length(row)
The name and call sequence of the exception was:
ExcInternalError()
Additional Information:
(none)
Secondly I think that your comment about the sparsity pattern is true. I
am creating the sparsity pattern with
constraints.clear ();
DoFTools::make_hanging_node_constraints (dof_handler,constraints);
constraints.close ();
CompressedSetSparsityPattern csp
(dof_handler.n_dofs(),dof_handler.n_dofs());
DoFTools::make_sparsity_pattern (dof_handler, csp, constraints, false);
sparsity_pattern.copy_from (csp);
system_matrix.reinit (sparsity_pattern);
but of course I need DoFTools::make_flux_sparsity_pattern, but this doesn't
take constraints (as typically a dG method doesn't have any). However my
application will be introducing some constraints so changing this section
would only be a temporary solution.
I know Barbel was also looking at a
make_flux_sparsity_pattern(...,constraints,...) function, so perhaps she
can shed some light on the problem.
John
On 08/09/10 09:31, Martin Kronbichler wrote:
Dear John,
Assuming that I want to continue to use
constraints.distribute_local_to_global, how do I treat the assembly
terms ui_ve_matrix, ue_vi_matrix i.e. those that contain integrals
involving cell and neighbor? The two cells may not have the same number
of degrees of freedom, so the matrices may not be square, so I tried to
use
void ConstraintMatrix::distribute_local_to_global ( const
FullMatrix< double> & local_matrix,
const std::vector< unsigned int> & row_indices,
const std::vector< unsigned int> & col_indices,
MatrixType& global_matrix
) const
but the local_dof_indices and neighbor_dof_indices are not the correct
variables to pass - how do I get row_indices and col_indices from the
dof_indices?
What do you mean by "not the correct variables to pass"? To me your
assembly routines seems correct. Your matrix ui_ve_matrix has
local_dof_indices.size() rows and neighbor_dof_indices.size() columns,
which is exactly the dimension the distribute_local_to_global function
expects. So I can't really see any flaw with this problem. Is some kind
of exception thrown (there might still be a bug in that distribute_l_t_g
function, we haven't been using it so much yet)? How is the sparsity
pattern of your matrix obtained - did you use
make_flux_sparsity_pattern?
Best,
Martin
_______________________________________________
dealii mailing list http://poisson.dealii.org/mailman/listinfo/dealii
_______________________________________________
dealii mailing list http://poisson.dealii.org/mailman/listinfo/dealii
