hp-meshworker

[Mihai]

Dear all,

I am interested in adding hp-functionality to the dealii::meshworker framework. Has anybody else done work in this direction? I'd appreciate some pointers about where best to start.

Thanks,

Mihai

[Guido Kanschat]

Dear Mihai,

in principle, it should be possible to do so. But, in order to save on memory allocations, some of the local vectors are set to their size before the loop. That would have to be changed. You will also have to consider if you want to start out using the same quadrature for all degrees to start with. It may be sub-optimal, but easier to implement.

I hope this is good for a start,
Guido

--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en
---
You received this message because you are subscribed to the Google Groups "deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dealii+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Prof. Dr. Guido Kanschat
Interdisziplinäres Zentrum für Wissenschaftliches Rechnen
Universität Heidelberg
Im Neuenheimer Feld 368, 69120 Heidelberg

[Wolfgang Bangerth]

> in principle, it should be possible to do so. But, in order to save on memory
> allocations, some of the local vectors are set to their size before the loop.
> That would have to be changed. You will also have to consider if you want to
> start out using the same quadrature for all degrees to start with. It may be
> sub-optimal, but easier to implement.

We have in other places used the following idiom:

std::vector<types::global_dof_index> dof_indices;
for (cell=dof_handler.begin_active(); cell!=dof_handler.end(); ++cell)
{
dof_indices.resize (cell->get_fe().dofs_per_cell);
cell->get_dof_indices (dof_indices);
...
}

The resize operation is fast if enough memory has already been allocated and
is only slow if the previously allocated memory is not sufficient to satisfy
the current request. Of course, this happens at most FECollection::size()
times and, consequently, is not a major bottleneck. I think this could also be
applied to the various MeshWorker loops where you need to do similar operations.

Best
W.


--
------------------------------------------------------------------------
Wolfgang Bangerth email: bang...@math.tamu.edu
www: http://www.math.tamu.edu/~bangerth/

[Korosh Taebi]

Did anybody continue working on this?
Which methods or classes exactly have to be modified for extending the meshworker framework by hp functionality?

[Wolfgang Bangerth]

On 02/15/2016 05:33 AM, 'Korosh Taebi' via deal.II User Group wrote:
> Did anybody continue working on this?

Not that I know.

> Which methods or classes exactly have to be modified for extending the
> meshworker framework by hp functionality?

I don't think anyone really knows. You'd probably just have to go through it,
try, and see where things break. We should have enough assertions in the code
base for things to fail in most of the places where one would need to change
something.