Dear Wolfgang,
I do not think it is a bug. I think it may very well be that
VectorTools::point_value it is not meant to be used with FE_Nedelec.
The first question: in this instance I do not use DataOut at all. I use
VectorTools::point_value to get data point-by-point and save it into a
On 4/18/21 10:50 PM, John Smith wrote:
Then I have fed this solution together with the dof handler to the
VectorTools::point_value on a grid of regularly spaced points. The results
were written into a *.csv file. Then I have made the vector plot out of it.
The 0-th order, FE_Nedelec<2> fe(0),
On 4/19/21 4:19 AM, Paras Kumar wrote:
std::unique_ptr nItersListPattern(new
dealii::Patterns::List(dealii::Patterns::Integer(1), 2, 8, "|"));
nIters =
dealii::Patterns::Tools::Convert::to_value(nMaxItersString,
nItersListPattern);
I suspect you need to write this last line as
On 4/19/21 4:14 AM, Simon wrote:
I use Elements of type FE_Q(p).
For p=1 there is no problem: I can simply loop over all cells and vertices and
use cell->vertex(...) in order to get the global coordinates of vertex(...).
Being p=2 for instance, this approach does not work anymore. In this case
Hi Simon,
This could be helpful:
https://github.com/dealii/dealii/wiki/Frequently-Asked-Questions#how-to-get-the-mapped-position-of-support-points-of-my-element
Here's a code snippet for Option-1, which I usually use.
const auto & feSystem = dofHandler.get_fe();
Dear Wolfgang,
Thank you so much for the suggestion. Just to avoid confusion for future
readers, the to_value() function needs a unique_ptr, and hence the
aforementioned line needs to be replaced by the following lines:
std::unique_ptr nItersListPattern(new
Dear All,
I am implementing a local postprocessing SPR-Approach for a mechanical
problem, in which I sloppy speaking need the global coordinates of all
nodes.
I use Elements of type FE_Q(p).
For p=1 there is no problem: I can simply loop over all cells and vertices
and use cell->vertex(...)
Dear John,
I had a look at the pdf you sent. I noticed some conceptual inconsistencies
that are important for the discretization. Let me start like this: The
curl-curl-problem that you are trying to solve is - according to your
description of the gauge - actually a curl-curl + grad-div problem
