[deal.II] Computational Methods for PDEs Summer School, August 3-5 2019

[Wolfgang Bangerth]

Dear colleagues,

To come right to the point, the community devoted to the numerical
solution of partial differential equations is not diverse. Most
researchers are white males, and the majority of software packages in
the area are developed by all-white all-male teams. We all lose out if
we accept this state.

An important piece in addressing this issue is building a *community*
among those who do not look like the majority. As one step towards
this, we will run the

   Computational Methods for PDEs Summer School
   Colorado State University
   Fort Collins, CO, USA
   August 3-9, 2019
   https://dealii.org/pdeschool-2019/

This summer school is geared toward undergraduate and graduate
students with an interest in the numerical solution of partial
differential equations, primarily using the finite element
method. While registration is open to everyone, we will give strong
preference to female applicants and applicants from other minorities.

The school will run August 3-5. It precedes the "Seventh deal.II
Users' and Developers' workshop" which will be held August 6-9, 2019,
also in Fort Collins, Colorado. Participants of the school will get an
introduction to deal.II and will then participate in the deal.II
workshop where they get to further build a network of peers.

Registration:
For workshop and registration information, see
   https://dealii.org/pdeschool-2019/

Deadline for registration: May 5, 2019. Participation is capped at
around 30.

Travel support:
A limited amount of (domestic) travel support is available courtesy of the
National Science Foundation, and will be given on a first come first serve
basis, with preference to undergraduate and graduate students. If you need
support, please state so in your registration.

The organizers
   Wolfgang Bangerth (Colorado State University)
   Juliane Dannberg (University of California, Davis)
   Timo Heister (University of Utah)
   Annalisa Quaini (University of Houston)
   Natasha Sharma (University of Texas at El Paso)


-- 

Wolfgang Bangerth  email: bange...@colostate.edu
www: http://www.math.colostate.edu/~bangerth/

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[deal.II] deal.II User and Developer Workshop: August 6-9, 2019

[Wolfgang Bangerth]

Dear deal.II users and developers,

The
Seventh deal.II Users' and Developers' workshop
will be held August 6-9, 2019 in Fort Collins, Colorado, USA. The
intent of this workshop is to discuss applications and tools using
deal.II, as well as future directions of the library itself.

We invite proposals for talks and discussion topics by users and
existing developers in the following areas:
  - Use cases and applications of the library.
  - What users think would be useful directions for the library to go into,
things that are missing, and possibly getting people together who can help
implement those parts.
  - Newer parts of the library (e.g., geometry descriptions, large parallel
computations, etc.) and how these could help in your programs.
A significant part of the time will be set aside for "hackathon"- or "code
jam"-style sessions where people can ask questions, work on their codes
with others, and receive help from experienced users.

Registration:
For workshop and registration information, see
   https://dealii.org/workshop-2019/

Deadline for registration: May 5, 2019. Participation is capped at
around 60.

Travel support:
A limited amount of (domestic) travel support is available courtesy of the
National Science Foundation, and will be given on a first come first serve
basis, with preference to undergraduate and graduate students. If you need
support, please state so in your registration.

The organizers
   Wolfgang Bangerth (Colorado State University, bange...@colostate.edu)
   Timo Heister (University of Utah, heis...@sci.utah.edu)

-- 

Wolfgang Bangerth  email: bange...@colostate.edu
www: http://www.math.colostate.edu/~bangerth/

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Why the FENedelec and FENedelecSZ 's shape functions change versus edge length?

[Wolfgang Bangerth]

On 4/9/19 8:51 PM, Phạm Ngọc Kiên wrote:
> I am a little bit confusing with the integral over all cell :
> *\int \varphi_i(x) *\varphi_j(x) * dx *on physical cell is approximated
> by computing *\sum { \varphi_hat_i(x_hat) *\varphi_hat_i(x_hat) *JxW(x_hat) } 
> *on reference cell.
> With FEValues we get *\varphi_i(x) *, if we compute the above integral as:
> *\sum { \*varphi_i(x)* *\*varphi_j(x)* *JxW(x_hat) }*
> then the value of the integral changes because shape functions defined on 
> reference cell are different from those on real cell.
> 
> Is there any reason for the integral calculation*\sum { \*varphi_i(x)* 
> *\*varphi_j(x)* *JxW(x_hat) }?*

I have to admit that I don't understand the question. The integral you are 
computing is

   \int \varphi_i(x)  \varphi_j(x)  dx

which is approximated using quadrature via

   \sum_q  \varphi_i(x_q) \varphi_j(x_q) w_q

where w_q = |det J(x_q)| \hat w_q = JxW. So this approximation happens in real 
space, not on the reference cell. How the individual components are computed 
(via the reference cell) is not important for the approximation.

Best
  WB

-- 

Wolfgang Bangerth  email: bange...@colostate.edu
www: http://www.math.colostate.edu/~bangerth/

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Imposing the Neumann BC using right_hand_side() function

[Wolfgang Bangerth]

On 4/9/19 10:01 AM, Muhammad Mashhood wrote:
> I want to apply the heat flux BC on one of the edge instead i.e. *dU(t, x, 
> y=1)/dy* at top. For this so far I could only find a method to make a heat 
> source using the already present function as follows:

I don't know how you use the class you implement, but I would try to avoid all 
confusion by naming the class RightHandSide: This is the name we generally use 
for forcing terms of the differential equation, and not for the right hand 
side of boundary conditions.

Just like for your previous question, it is not correct to "convert" the right 
hand side of a boundary condition into a right hand side of the equation. This 
is mathematically not correct and will not lead to the correct solution.

Have you looked at step-7? This program deals with Neumann boundary conditions 
and may have exactly what you are looking for.

Best
  W.

-- 

Wolfgang Bangerth  email: bange...@colostate.edu
www: http://www.math.colostate.edu/~bangerth/

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Why the FENedelec and FENedelecSZ 's shape functions change versus edge length?

[Phạm Ngọc Kiên]

I am a little bit confusing with the integral over all cell :
*\int \varphi_i(x)  \varphi_j(x)  dx *on physical cell is approximated
by computing *\sum { \varphi_hat_i(x_hat)  \varphi_hat_i(x_hat) JxW(x_hat)
} *on reference cell.
With FEValues we get *\varphi_i(x) *, if we compute the above integral as:
*\sum { \varphi_i(x) \varphi_j(x) JxW(x_hat) }*
then the value of the integral changes because shape functions defined on
reference cell are different from those on real cell.

Is there any reason for the integral calculation* \sum { \varphi_i(x)
\varphi_j(x) JxW(x_hat) }?*
Thank you very much for your quick answers.

Best regards.


Vào Th 4, 10 thg 4, 2019 vào lúc 00:15 Wolfgang Bangerth <
bange...@colostate.edu> đã viết:

> On 4/9/19 1:27 AM, Phạm Ngọc Kiên wrote:
> > I looked through the codes for Fe_Nedelec_SZ in the library and found
> that the
> > fe_values was transformed from reference cell to physical cell by the
> function
> > like:
> > mapping.transform(make_array_view(fe_data.shape_values[dof]),
> >  mapping_covariant,
> >  mapping_internal,
> >  make_array_view(transformed_shape_values));
> > Does this mean that fe_values.value(i,q_point) and
> fe_values.curl(i,q_point)
> > are stored on physical cell?
>
> Yes, yes, of course -- that's the point of FEValues :-)
>
> Best
>   W.
>
>
> --
> 
> Wolfgang Bangerth  email: bange...@colostate.edu
> www: http://www.math.colostate.edu/~bangerth/
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[deal.II] deal.II Newsletter #74

[Rene Gassmoeller]

Hello everyone!

This is deal.II newsletter #74.
It automatically reports recently merged features and discussions about the 
deal.II finite element library.


## Below you find a list of recently proposed or merged features:

#7901: Use std::string in SmartPointer and Subscriptor interface (proposed by 
masterleinad) https://github.com/dealii/dealii/pull/7901

#7900: Update dead LICENSE link in README (proposed by kkremitzki; merged) 
https://github.com/dealii/dealii/pull/7900

#7899: Refactored hp::FECollection: Get fe relations with respect to 
FiniteElementDomination. (proposed by marcfehling) 
https://github.com/dealii/dealii/pull/7899

#7898: [CI]: catch failures and run quicktests (proposed by tjhei) 
https://github.com/dealii/dealii/pull/7898

#7897: MPI quicktests failing (proposed by tjhei; merged) 
https://github.com/dealii/dealii/pull/7897

#7896: Require SymEngine version 0.4 (proposed by masterleinad; merged) 
https://github.com/dealii/dealii/pull/7896

#7894: Silence an unused variable warning. (proposed by drwells; merged) 
https://github.com/dealii/dealii/pull/7894

#7893: Fix a misspelled word. (proposed by bangerth; merged) 
https://github.com/dealii/dealii/pull/7893

#7890: Fix space in error message (proposed by masterleinad; merged) 
https://github.com/dealii/dealii/pull/7890

#7889: fix hdf5 in serial (proposed by tjhei; merged) 
https://github.com/dealii/dealii/pull/7889

#7886: Test SCALAPACK with -Werror (proposed by masterleinad; merged) 
https://github.com/dealii/dealii/pull/7886

#7885: add default constructor for ArrayView and a reinit() method (proposed by 
davydden; merged) https://github.com/dealii/dealii/pull/7885

#7844: SD: Types, traits, and expression class (proposed by jppelteret; merged) 
https://github.com/dealii/dealii/pull/7844

#7746: More edits in the introduction of step-61. (proposed by bangerth; 
merged) https://github.com/dealii/dealii/pull/7746


## And this is a list of recently opened or closed discussions:

#7904: Bug in rectangular TrilinosWrappers::SparseMatrix (opened) 
https://github.com/dealii/dealii/issues/7904

#7903: Use fe.degree explicitly in example quadrature rules. (opened) 
https://github.com/dealii/dealii/issues/7903

#7902: tbb from intel-parallel-studio (opened and closed) 
https://github.com/dealii/dealii/issues/7902

#7895: CDash builds with SYMENGINE support failing (opened and closed) 
https://github.com/dealii/dealii/issues/7895

#7892: Heap use after free in ParameterAcceptor::ParameterAcceptor(const 
std::string ) (opened) https://github.com/dealii/dealii/issues/7892

#7891: Illegal instruction in bundled OpenBLAS with Deal.ii mac package on pre 
Haswell architectures (opened) https://github.com/dealii/dealii/issues/7891

#7888: Configure error with fedora 29 (opened) 
https://github.com/dealii/dealii/issues/7888

#7887: get_mg_dof_indices is deprecated? (opened) 
https://github.com/dealii/dealii/issues/7887


A list of all major changes since the last release can be found at 
https://www.dealii.org/developer/doxygen/deal.II/changes_after_8_5_0.html.


Thanks for being part of the community!


Let us know about questions, problems, bugs or just share your experience by 
writing to dealii@googlegroups.com, or by opening issues or pull requests at 
https://www.github.com/dealii/dealii.
Additional information can be found at https://www.dealii.org/.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Imposing the Neumann BC using right_hand_side() function

[Muhammad Mashhood]

Sorry if it is not clear. Sure I will explain it a bit more.
In step-26 of tutorials, the (temperature application) Dirchlet BC is 
already implemented. I want to apply the heat flux BC on one of the edge 
instead i.e. *dU(t, x, y=1)/dy* at top. For this so far I could only find a 
method to make a heat source using the already present function as follows:

  template
  class RightHandSide : public Function
  {
  public:
RightHandSide ()
  :
  Function(),
  period (0.2)
{}

virtual double value (const Point ,
  const unsigned int component = 0) const;

  private:
const double period;
  };



  template
  double RightHandSide::value (const Point ,
const unsigned int component) const
  {
(void) component;
Assert (component == 0, ExcIndexRange(component, 0, 1));
Assert (dim == 2, ExcNotImplemented());

const double time = this->get_time();
const double point_within_period = (time/period - 
std::floor(time/period));

if ((point_within_period >= 0.0) && (point_within_period <= 0.2))
  {
if ((p[0] > 0.5) && (p[1] > -0.5))
  return 2;
else
  return 0;
  }
else if ((point_within_period >= 0.5) && (point_within_period <= 0.7))
  {
if ((p[0] > -0.5) && (p[1] > 0.5))
  return 2;
else
  return 0;
  }
else
  return 0;
///
// Applying the Neumann BC in the form of flux producing source or sink 
at top boundary
///

if ((point_within_period >= 0.0) && (point_within_period <= 0.2))
  {

if (p[1] > 0.99)
  return 100;
else
  return 0;

  }

  }

So the question is that is it valid Idea or there can be other idea to 
apply heat flux on the boundary edge in deal.ii step-26 code? Thank you!

On Tuesday, April 9, 2019 at 5:23:04 PM UTC+2, Wolfgang Bangerth wrote:
>
> On 4/9/19 3:44 AM, Muhammad Mashhood wrote: 
> > Thank you very much Prof. Bangerth. The Neuman condition is now 
> implemented 
> > successfully on the face elements in relatively simpler way (which you 
> > proposed for me). Now I have moved ahead to implement the flux BC on the 
> top 
> > edge of square plate and I am taking help of your tutorial step-26. But 
> in 
> > this code the structure is a bit different than the step-8 i.e. the 
> *cell_rhs 
> > *looks like being formed now in *create_right_hand_side* function. 
> > So my question is that can I simply use the heat source code of 
> following 
> > function: 
> > *template 
> >double RightHandSide::value (const Point , 
> >  const unsigned int component) 
> const* 
> > 
> > to select the points of top edge of the domain to declare the flux input 
> or 
> > Neuman BC (i.e. in other words moving source on top and source now 
> putting 
> > heat inside the domain) or there is other valid way for that? Thank you 
> in 
> > advance for your suggestion! 
>
> I don't think I fully understand what you want to do. Can you state in 
> formulas what you want to implement? How does your boundary conditions 
> look like? 
>
> Best 
>   WB 
>
> -- 
>  
> Wolfgang Bangerth  email: bang...@colostate.edu 
>  
> www: http://www.math.colostate.edu/~bangerth/ 
>
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Imposing the Neumann BC using right_hand_side() function

[Wolfgang Bangerth]

On 4/9/19 3:44 AM, Muhammad Mashhood wrote:
> Thank you very much Prof. Bangerth. The Neuman condition is now implemented 
> successfully on the face elements in relatively simpler way (which you 
> proposed for me). Now I have moved ahead to implement the flux BC on the top 
> edge of square plate and I am taking help of your tutorial step-26. But in 
> this code the structure is a bit different than the step-8 i.e. the *cell_rhs 
> *looks like being formed now in *create_right_hand_side* function.
> So my question is that can I simply use the heat source code of following 
> function:
> *template
>    double RightHandSide::value (const Point ,
>      const unsigned int component) const*
> 
> to select the points of top edge of the domain to declare the flux input or 
> Neuman BC (i.e. in other words moving source on top and source now putting 
> heat inside the domain) or there is other valid way for that? Thank you in 
> advance for your suggestion!

I don't think I fully understand what you want to do. Can you state in 
formulas what you want to implement? How does your boundary conditions look 
like?

Best
  WB

-- 

Wolfgang Bangerth  email: bange...@colostate.edu
www: http://www.math.colostate.edu/~bangerth/

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] project_boundary_values for components

[Wolfgang Bangerth]

On 4/9/19 2:23 AM, Anton wrote:
> 
> Thank you for the help.  I think I have it working in the non-distributed 
> case, but project_boundary_values segfaults on me without any explanations 
> (compiled in debug mode) when run with a distributed triangulation.  Is this 
> "normal"?

Ah, good point. The function may not be intended (so far) for the parallel 
case. Do you think you can come up with a minimal example that shows the 
segfault?

The root of the issue is that you are using a DG element. For those elements, 
the projection is local on each face, and I think it would probably not be 
terribly difficult to implement by hand given that there is no function right 
now that does what you want. Have you thought about doing that? It may be 
useful to then put that into the library.

Best
  W.


-- 

Wolfgang Bangerth  email: bange...@colostate.edu
www: http://www.math.colostate.edu/~bangerth/

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Why the FENedelec and FENedelecSZ 's shape functions change versus edge length?

[Wolfgang Bangerth]

On 4/9/19 1:27 AM, Phạm Ngọc Kiên wrote:
> I looked through the codes for Fe_Nedelec_SZ in the library and found that 
> the 
> fe_values was transformed from reference cell to physical cell by the 
> function 
> like:
> mapping.transform(make_array_view(fe_data.shape_values[dof]),
>      mapping_covariant,
>      mapping_internal,
>      make_array_view(transformed_shape_values));
> Does this mean that fe_values.value(i,q_point) and fe_values.curl(i,q_point) 
> are stored on physical cell?

Yes, yes, of course -- that's the point of FEValues :-)

Best
  W.


-- 

Wolfgang Bangerth  email: bange...@colostate.edu
www: http://www.math.colostate.edu/~bangerth/

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Imposing the Neumann BC using right_hand_side() function

[Muhammad Mashhood]

Thank you very much Prof. Bangerth. The Neuman condition is now implemented 
successfully on the face elements in relatively simpler way (which you 
proposed for me). Now I have moved ahead to implement the flux BC on the 
top edge of square plate and I am taking help of your tutorial step-26. But 
in this code the structure is a bit different than the step-8 i.e. the 
*cell_rhs 
*looks like being formed now in *create_right_hand_side* function. 
So my question is that can I simply use the heat source code of following 
function:


*template  double RightHandSide::value (const Point 
,const unsigned int component) const*

to select the points of top edge of the domain to declare the flux input or 
Neuman BC (i.e. in other words moving source on top and source now putting 
heat inside the domain) or there is other valid way for that? Thank you in 
advance for your suggestion!  


On Thursday, April 4, 2019 at 3:10:35 PM UTC+2, Wolfgang Bangerth wrote:
>
> On 4/4/19 4:05 AM, Muhammad Mashhood wrote: 
> > 
> >   for (unsigned int f=0; f :: faces_per_cell; ++f) 
> >  if (cell->face(f)->at_boundary() ) 
> >  { 
> >  fe_face_values.reinit (cell,f); 
> >  for (unsigned int i=0; i >{ 
> >  const unsigned int 
> >  component_i = 
> fe.system_to_component_index(i).first; 
> > 
> >  for (unsigned int q_point=0; 
> q_point > ++q_point) 
> >cell_rhs(i) += 
> fe_face_values.shape_value(i,q_point) * 
> >   rhs_values[q_point][component_i] * 
> >   fe_face_values.JxW(q_point); 
> >  } 
> >  } 
> > 
> > 
> >   Where the *"rhs_values"* are being extracted from my previously 
> mentioned 
> > function "*right_hand_side (fe_values.get_quadrature_points(), 
> rhs_values, 
> > cell);"* in a same loop of "*for (; cell!=endc; ++cell)" *and the code 
> for 
> > this "*right_hand_side" *function is that which I mentioned previously. 
> > In my limited knowledge I am going through each face in cell as in 2D 
> there 
> > are four edges are present and I want to choose the edge number 3 (which 
> is 
> > upper outer edge in my example case). 
>
> The way you do things here does not work. You are assembling boundary 
> terms on 
> an individual face here. You need to evaluate the rhs_values *for this 
> particular face*. In other words, you need to call the function you showed 
> us with 
>fe_face_values.get_quadrature_points() 
> (not fe_values.get_quadrature_points()), and not with an iterator to the 
> cell 
> but with an iterator to the face. 
>
> This way, you do not need the function you showed us guess whether a 
> quadrature point is near a particular boundary -- the function already 
> *knows* 
> that the quadrature points lie on that boundary, because it is only called 
> for 
> such points. 
>
> Best 
>   W. 
>
>
> -- 
>  
> Wolfgang Bangerth  email: bang...@colostate.edu 
>  
> www: http://www.math.colostate.edu/~bangerth/ 
>
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] project_boundary_values for components

[Anton]

Wolfgang,

Thank you for the help.  I think I have it working in the non-distributed 
case, but project_boundary_values segfaults on me without any explanations 
(compiled in debug mode) when run with a distributed triangulation.  Is 
this "normal"?  

/Anton

On Monday, April 8, 2019 at 12:11:19 AM UTC+2, Wolfgang Bangerth wrote:
>
> On 4/6/19 12:29 PM, Anton wrote: 
> > 
> > Basically if I interpolate a step function (which can be exactly 
> presented in 
> > for example DGQ1 space if the discontinuity is at the node) I get a 
> 1-element 
> > wide transition.  In ASCII pictures, I expect  ___  but I get 
> ___/---   
> > instead :) 
>
> Ah, yes -- ASCII art to the fore! Yes, the problem is that the DGQ(k) 
> elements 
> have support (interpolation) points at the vertices, and so you'll get the 
> same value for both cells at these vertices. That's unavoidable. 
> Projection is 
> the solution. 
>
>
> > So if I understand you correctly, one would need to (1) obtain 
> > ConstraintMatrix from project_boundary_values; (2) go over each row of 
> the 
> > constraint matrix and check which component it is; (3) if it is the 
> "right" 
> > component  then copy the row.  Could I ask how does one figure out the 
> > component number from the row number in the ConstraintMatrix - I cannot 
> > immediately figure this out from DoFHandler interface? 
>
> You can't do it this way, but there are functions in DoFTools that allow 
> you 
> to extract *all* DoF indices for a particular component from a DoFHandler, 
> and 
> then you can cross-check the two objects. 
>
> Best 
>   W. 
>
>
> -- 
>  
> Wolfgang Bangerth  email: bang...@colostate.edu 
>  
> www: http://www.math.colostate.edu/~bangerth/ 
>
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Why the FENedelec and FENedelecSZ 's shape functions change versus edge length?

[Phạm Ngọc Kiên]

Dear all,
I looked through the codes for Fe_Nedelec_SZ in the library and found that
the fe_values was transformed from reference cell to physical cell by the
function like:
mapping.transform(make_array_view(fe_data.shape_values[dof]),
mapping_covariant,
mapping_internal,
make_array_view(transformed_shape_values));
Does this mean that fe_values.value(i,q_point) and
fe_values.curl(i,q_point) are stored on physical cell?

In mapping, mapping of integrals
,
the shape function is defined on reference cell to approximate the integral
by quadrature.
How can I use fe_values.value(i,q_point) and fe_values.curl(i,q_point) to
compute the integral when they are defined on physical cell?
Is there any other way to compute the integral in this case?

I would like to thank you very much in advance.
Best regards,
Pham Ngoc Kien


Vào Th 5, 28 thg 3, 2019 vào lúc 16:30 Phạm Ngọc Kiên <
ngockien.lea...@gmail.com> đã viết:

> Thank you very much
> I will dig deeper from your suggestion.
> Best regards,
> Pham Ngoc Kien
>
> Vào Th 5, 28 thg 3, 2019 vào lúc 12:25 Wolfgang Bangerth <
> bange...@colostate.edu> đã viết:
>
>> On 3/27/19 6:56 PM, Phạm Ngọc Kiên wrote:
>> > Yes, I know that the source should be integral over the edge of a cell,
>> not a
>> > single point on the cell.
>> > And I checked that if I take the integral over an edge of shape
>> function I
>> > will get 1 * inverse of edge length.
>> > However, we actually do compute the source term over a cell when
>> assembling
>> > the right hand side:
>> > F_i  =  \int_\Omega  \phi_i(x) J(x)  dx
>> > To compute it, we implement the Quadrature formula with its weights on
>> unit
>> > cell rather than the weights on and edge.
>> > In my limited knowledge, I think that J(x) should be non-zero if x is
>> on my
>> > source line, and be zero every where else in the cell.
>>
>> Well, but that's precisely a delta function then. J is a current
>> *density*, so
>> if you have a current density that only lives on an edge with a finite
>> length
>> but an infinitely small diameter, then the total current that is flowing
>> is
>> zero. If you say that J(x) is zero everywhere but on that edge, then no
>> current is flowing. Your model is just flawed in that case.
>>
>> If you want to restrict a *nonzero* current to just an edge, then you
>> need an
>> infinite current density, and in that case you would have
>>
>>F_i = \int_Omega phi_i(x) J(x)  // J is current *density*
>>= \int_edge phi_i(x) j(x)   // j is *current*
>>
>> where the second integral only extends over a one-dimensional edge.
>>
>>
>> > Should I set J(x) constant when computing F_i if dof i of the cell
>> relates to
>> > the source?
>>
>> You're asking the wrong person. If you are trying to model a physical
>> situation, then what J(x) is is a question of how that physical situation
>> looks like and is best described. Nobody but you can answer this -- it's
>> not a
>> mathematical question, but a modeling question.
>>
>> Best
>>   W.
>>
>> --
>> 
>> Wolfgang Bangerth  email: bange...@colostate.edu
>> www: http://www.math.colostate.edu/~bangerth/
>>
>> --
>> 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+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.