>>
>> > fe_values.get_function_values() on the velocity vector.
>> > ExcIndexNotPresent (n)
>>
>> get_function_values() needs to see the ghost values of your vector
>> (all DoFs on a cell).
>
>
> yes, that is what is being passed to it. I use the post flags _lo and _lr
> for my vector names to distinguish between the completely distributed
> (locally owned) and ghosted (locally relevant) vectors. I am not positive,
> but I believe the issue is that we are using velocity_lr =
> solution_lr.block{0} where solution_lr has not been blockwise renumbered and
> so the locally owned IndexSet corresponding to the first block is not a
> single interval and in fact contains global indices larger than the number
> of dofs on the block. The locally relevant index set has the same problem.
> Could it be that there is a difference in dof index between the global
> indexset of solution_lr and the dof index on the block and the use of the
> incorrect index is what triggers the ExcIndexNotPresent() error?
I am confused what you you do:
a) loop over cells with get_function_values()
b) loop over locally owned indices and do vec1(idx) = vec2(idx);
c) assign vectors: velocity_lr = solution_lr.block(0)
If you do a) it should work if the vector is ghosted and you only look
at owned cells.
If you do b) it should work if you only look at locally owned indices
of vec2. You can write anywhere but only read from available entries.
If you do c) I have no idea what will happen.
> Yes I thought there would be an approach like this. Thanks for laying it
> out. As I am only needing to convert one direction, the vectors as
> constructed above would likely be sufficient but are you thinking of a data
> structure like std::map<global_dof_index, global_dof_index> ?
The vectors as explained above contain duplicates and ghost indices,
that you should probably remove. They also don't give you a direct
mapping from idx to idx. You could construct a map but you can also
use the vectors as is.
> Does the DoFHandler with it's attached FiniteElement change anything in the
> FiniteElement when we renumber?
No, a DoFHandler does not modify the FiniteElement (look at
distribute_dofs(), it gets a const ref of the FE so it won't modify
it). One of the important concepts of deal.II is we try to be modular:
you can have as many Triangulation, FE, DoFHandler, FEValues, ...
objects at the same time as you want.
--
Timo Heister
http://www.math.clemson.edu/~heister/
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
