[deal.II] Re: Electromagnetic problem in 3d

['yy.wayne' via deal.II User Group]

Thank you Abbas! That's wonderful.

在2022年12月5日星期一 UTC+8 23:24:12 写道：

> Here you go and good luck. 
>
> On Monday, December 5, 2022 at 4:52:22 PM UTC+2 yy.wayne wrote:
>
>> I'm extending step-81, the time-harmonic maxwell problem into 3d, however 
>> the result is
>> not correct. Both Nedelec and NedelecSZ elements are tested. However all 
>> physical 
>> formulas are kept same in 2d and 3d, with an absorption boundary 
>> condition rather than 
>> PML, but 2d test is correct even with little wavelength till boundary 
>> (1.5 waves) and low 
>> relolution (6 grids per wave). Is there a tutorial on EM in 3 dimensional?
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/4861f390-2e56-4b6a-b94a-d3a210f5d353n%40googlegroups.com.

[deal.II] Re: MatrixFree support for Nedelec element in deal.II

[Abbas]

Nedelec aren't cheap either. You need an fe(n+1) to achieve n accuracy. 
It's 64 dofs for all the 6 components of the electric field E in 3D to 
achieve 1st order accuracy. 
With adaptive mesh refinement, Nedelec will get a lot more expensive than 
this. 
By all means, do what seems fit. I am just trying to be a bit informative. 
Maybe you get one of those questions in the future.   

best,
Abbas 

On Monday, December 5, 2022 at 4:45:12 PM UTC+2 yy.wayne wrote:

> Thanks Abbas,
>
> I considered about DG method, because DG allows discontinuity and 
> implements boundary condition easier than FE_Q. 
> However DG requires more DoF than continuous finite element, especially in 
> frequency-domain. 
>
> Best,
> Wayne
>
> 在2022年12月5日星期一 UTC+8 22:35:12 写道：
>
>> Maybe you can look into using DG for discritizing the problem? You're 
>> already using penalty terms so might as well. 
>> One thing I am afraid of is that Nedelec elements inherently satisfy the 
>> div free condition, while DG might need careful treatment or your 
>> preconditioner would fail at high frequency. 
>> Just my 2 cents. Maybe you know someone else who can help you with this.  
>>  
>>
>>
>> On Monday, December 5, 2022 at 4:29:35 PM UTC+2 yy.wayne wrote:
>>
>>> Hi deal.II community,
>>>
>>> I'm working on MatrixFree electromagnetic problems with deal.II. For 2d 
>>> TE waves FE_Q element works good, but for cases like in step-81 and in 3d, 
>>> Nedelec element in the appropriate one for EM.
>>>
>>> I posted a discussion about this 3 months ago. May I ask what's the 
>>> current state for MatriFree support of Nedelec elements in deal.II? 
>>> Implementing MatrixFree Nedelec is quite difficult for me. Currently I plan 
>>> to solve 3d EM problem with FE_Q elements with some penalty terms, but of 
>>> course that's not a nice policy because of spurious solution and 
>>> singularity when solving EM numerically with nodal elements.
>>>
>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/1f4bd525-930b-4966-a0f9-f88b0a5edefbn%40googlegroups.com.

[deal.II] Electromagnetic problem in 3d

['yy.wayne' via deal.II User Group]

I'm extending step-81, the time-harmonic maxwell problem into 3d, however 
the result is
not correct. Both Nedelec and NedelecSZ elements are tested. However all 
physical 
formulas are kept same in 2d and 3d, with an absorption boundary condition 
rather than 
PML, but 2d test is correct even with little wavelength till boundary (1.5 
waves) and low 
relolution (6 grids per wave). Is there a tutorial on EM in 3 dimensional?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/c6f0d1f3-31a3-4fa4-a56a-d5a7c57ba928n%40googlegroups.com.
/* -
 *
 * Copyright (C) 2021 - 2022 by the deal.II authors
 *
 * This file is part of the deal.II library.
 *
 * The deal.II library is free software; you can use it, redistribute
 * it, and/or modify it under the terms of the GNU Lesser General
 * Public License as published by the Free Software Foundation; either
 * version 2.1 of the License, or (at your option) any later version.
 * The full text of the license can be found in the file LICENSE.md at
 * the top level directory of deal.II.
 *
 * -

 *
 * Author: Marc Fehling, Colorado State University, 2021
 * Peter Munch, Technical University of Munich and Helmholtz-Zentrum
 *  hereon, 2021
 * Wolfgang Bangerth, Colorado State University, 2021
 */

#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 

#include 
#include 

#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 

#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 

#include 
#include 
#include 

// For load balancing we will assign individual weights on cells, and for that
// we will use the class parallel::CellWeights.
#include 

// The solution function requires a transformation from Cartesian to polar
// coordinates. The GeometricUtilities::Coordinates namespace provides the
// necessary tools.
#include 
#include 

// The following include files will enable the MatrixFree functionality.
#include 
#include 
#include 

// We will use LinearAlgebra::distributed::Vector for linear algebra operations.
#include 

// We are left to include the files needed by the multigrid solver.
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define OMEGA 1.0/4*M_PI*1e9
#define C_CONST 3e8

namespace Nodal_EM
{
  using namespace dealii;
  const unsigned int fe_degree = 0;


  template 
  Tensor<1,dim,std::complex> J_a_func(const Point &point,
 types::material_id /*id*/)
  {
  Tensor<1,dim,std::complex> J_a;
  double dipole_radius = 0.2;
//  Point dipole_position(0., 0., 0.);
//  Tensor<1,dim> dipole_orientation{{0., 0., 1.}};
  Point dipole_position(0., 0.);
  Tensor<1,dim> dipole_orientation{{0., 1.}};
  std::complex dipole_strength = 1;

  const auto distance = (dipole_position - point).norm() / dipole_radius;
  if(distance > 1.)
  return J_a;
  double scale = std::cos(distance * M_PI / 2.) *
   std::cos(distance * M_PI / 2.) / (M_PI / 2. - 2. / M_PI) /
   dipole_radius / dipole_radius;
  J_a = dipole_strength * dipole_orientation * scale;
  return J_a;
  }

  template 
  DEAL_II_ALWAYS_INLINE inline Tensor<1, dim, std::complex>
  tangential_part(const Tensor<1, dim, std::complex> &tensor,
  const Tensor<1, dim> &  normal)
  {
auto result = tensor;
result[0]   = normal[1] * (tensor[0] * normal[1] - tensor[1] * normal[0]);
result[1]   = -normal[0] * (tensor[0] * normal[1] - tensor[1] * normal[0]);
// result in 2dim is -nxnxtensor, with component in z = 0.
return result;

//result[0] = normal[1]*tensor[2] - normal[2]*tensor[1];
//result[1] = -(normal[0]*tensor[2] - normal[2]*tensor[0]);
//result[2] = normal[0]*tensor[1]* - normal[1]*tensor[0];
//return result;
  }

  template 
  DEAL_II_ALWAYS_INLINE inline Tensor<1, dim, std::complex>
  cross(const Tensor<1, dim> &  normal,
  const Tensor<1, dim, std::complex> &tensor)
  {
auto result = tensor;
//result[0]   = normal[1] * (tensor[0] * normal[1] - tensor[1] * normal[0]);
//result[1]   = -normal[0] * (tensor[0] * normal[1] - tensor[1] * normal[0]);
//return r

[deal.II] Re: MatrixFree support for Nedelec element in deal.II

['yy.wayne' via deal.II User Group]

Thanks Abbas,

I considered about DG method, because DG allows discontinuity and 
implements boundary condition easier than FE_Q. 
However DG requires more DoF than continuous finite element, especially in 
frequency-domain. 

Best,
Wayne

在2022年12月5日星期一 UTC+8 22:35:12 写道：

> Maybe you can look into using DG for discritizing the problem? You're 
> already using penalty terms so might as well. 
> One thing I am afraid of is that Nedelec elements inherently satisfy the 
> div free condition, while DG might need careful treatment or your 
> preconditioner would fail at high frequency. 
> Just my 2 cents. Maybe you know someone else who can help you with this.   
>
>
> On Monday, December 5, 2022 at 4:29:35 PM UTC+2 yy.wayne wrote:
>
>> Hi deal.II community,
>>
>> I'm working on MatrixFree electromagnetic problems with deal.II. For 2d 
>> TE waves FE_Q element works good, but for cases like in step-81 and in 3d, 
>> Nedelec element in the appropriate one for EM.
>>
>> I posted a discussion about this 3 months ago. May I ask what's the 
>> current state for MatriFree support of Nedelec elements in deal.II? 
>> Implementing MatrixFree Nedelec is quite difficult for me. Currently I plan 
>> to solve 3d EM problem with FE_Q elements with some penalty terms, but of 
>> course that's not a nice policy because of spurious solution and 
>> singularity when solving EM numerically with nodal elements.
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/e8f7393c-6440-47c9-9942-6d440949a6b0n%40googlegroups.com.

[deal.II] Re: MatrixFree support for Nedelec element in deal.II

[Abbas]

Maybe you can look into using DG for discritizing the problem? You're 
already using penalty terms so might as well. 
One thing I am afraid of is that Nedelec elements inherently satisfy the 
div free condition, while DG might need careful treatment or your 
preconditioner would fail at high frequency. 
Just my 2 cents. Maybe you know someone else who can help you with this.   


On Monday, December 5, 2022 at 4:29:35 PM UTC+2 yy.wayne wrote:

> Hi deal.II community,
>
> I'm working on MatrixFree electromagnetic problems with deal.II. For 2d TE 
> waves FE_Q element works good, but for cases like in step-81 and in 3d, 
> Nedelec element in the appropriate one for EM.
>
> I posted a discussion about this 3 months ago. May I ask what's the 
> current state for MatriFree support of Nedelec elements in deal.II? 
> Implementing MatrixFree Nedelec is quite difficult for me. Currently I plan 
> to solve 3d EM problem with FE_Q elements with some penalty terms, but of 
> course that's not a nice policy because of spurious solution and 
> singularity when solving EM numerically with nodal elements.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/9ca08a1c-b9ab-46cb-8e90-1f65fad47b76n%40googlegroups.com.

[deal.II] MatrixFree support for Nedelec element in deal.II

['yy.wayne' via deal.II User Group]

Hi deal.II community,

I'm working on MatrixFree electromagnetic problems with deal.II. For 2d TE 
waves FE_Q element works good, but for cases like in step-81 and in 3d, 
Nedelec element in the appropriate one for EM.

I posted a discussion about this 3 months ago. May I ask what's the current 
state for MatriFree support of Nedelec elements in deal.II? Implementing 
MatrixFree Nedelec is quite difficult for me. Currently I plan to solve 3d 
EM problem with FE_Q elements with some penalty terms, but of course that's 
not a nice policy because of spurious solution and singularity when solving 
EM numerically with nodal elements.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/63916a81-2f0d-4b49-b231-cc3992817f91n%40googlegroups.com.

Re: [deal.II] How do I set initial solution vector to boundary values in DG?

[Abbas]

Thank you Profs. 

Prof. Bangerth, I probably wasn't clear in my question. I know how to apply 
BCs for an interior penalty problem weakly. 
But, for a non-linear problem like step 15, one initialises the solution 
vector and sets it to the value of the BCs at the boundary before solving 
for the Newton update. This is done explicitly in function 
'set_boundary_values()' in step 15 with the function  '
VectorTools::interpolate_boundary_values 

'. 
I cannot use this function with DG elements apparently and I am wondering 
if there are any alternatives.  

Prof. Hiester, don't you think that subtracting small and manipulating 
large numbers in the residual will cause some problems? 
I'll give it a try for sure though. 

Thanks again 


On Monday, December 5, 2022 at 3:01:32 AM UTC+2 Timo Heister wrote:

> I would consider the boundary conditions part of the nonlinear
> iteration (in contrast to step-15, where they are strongly enforced
> and as such are only needed in step 0). Every step you can evaluate
> your nonlinear residual which contains a residual in the boundary
> condition and that difference needs to be applied in every step
> (assuming you solve for an update in each Newton step).
>
> On Sat, Dec 3, 2022 at 10:56 AM Wolfgang Bangerth
>  wrote:
> >
> > On 12/3/22 07: 11, Abbas wrote: > > Something like this doesn't work 
> with DG. > Loosely speaking, my initial approach would be to solve a system 
> with just the > BC terms but I am not sure. Do I have other options? In DG 
> methods,
> > ZjQcmQRYFpfptBannerStart
> > This Message Is From an External Sender
> > Use caution when opening links or attachments if you do not recognize 
> the sender.
> >
> > ZjQcmQRYFpfptBannerEnd
> >
> > On 12/3/22 07:11, Abbas wrote:
> > >
> > > Something like this doesn't work with DG.
> > > Loosely speaking, my initial approach would be to solve a system with 
> just the
> > > BC terms but I am not sure. Do I have other options?
> >
> > In DG methods, you impose boundary values weakly, using the same 
> strategy with
> > which you impose continuity between cells weakly. You might want to look 
> at
> > papers on DG methods: pretty much every single one will show the jump 
> terms
> > corresponding to Dirichlet boundary values.
> >
> > Best
> > W.
> >
> > --
> > 
> > Wolfgang Bangerth email: bang...@colostate.edu
> > www: 
> https://urldefense.com/v3/__http://www.math.colostate.edu/*bangerth/__;fg!!PTd7Sdtyuw!Vf-IQx7HQQ5bIq8xBQu1BzCdpZiz9Q3UC6emGlg1Z50xBT-oA9UeUBtyamyADtrTV0zLEZpa0RBQ_lV6jh5B8Uo$
> >
> >
> > --
> > The deal.II project is located at 
> https://urldefense.com/v3/__http://www.dealii.org/__;!!PTd7Sdtyuw!Vf-IQx7HQQ5bIq8xBQu1BzCdpZiz9Q3UC6emGlg1Z50xBT-oA9UeUBtyamyADtrTV0zLEZpa0RBQ_lV6CDq7NmU$
> > For mailing list/forum options, see 
> https://urldefense.com/v3/__https://groups.google.com/d/forum/dealii?hl=en__;!!PTd7Sdtyuw!Vf-IQx7HQQ5bIq8xBQu1BzCdpZiz9Q3UC6emGlg1Z50xBT-oA9UeUBtyamyADtrTV0zLEZpa0RBQ_lV6qJBbcDU$
> > ---
> > 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.
> > To view this discussion on the web visit 
> https://urldefense.com/v3/__https://groups.google.com/d/msgid/dealii/c1d413d2-3c55-0523-19fd-9f399d1781da*40colostate.edu__;JQ!!PTd7Sdtyuw!Vf-IQx7HQQ5bIq8xBQu1BzCdpZiz9Q3UC6emGlg1Z50xBT-oA9UeUBtyamyADtrTV0zLEZpa0RBQ_lV6CppyxvM$
>  
> .
>
>
>
> -- 
> 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 dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/e6b575d7-9bfd-4137-b30b-3e3d2a335144n%40googlegroups.com.

Re: [deal.II] A problem using "make_periodicity_constraints" function

[Masoud Ahmadi]

OK, the more I think about it, the more I am confident to say: It is Wrong.

In my logic, I am not doing anything related to DoF numbering. In both 
cases, I create a square by the length of 44.72, assign the same boundary 
IDs to the sides (left: 1, right:2, down:3, up:4), then use the 
"DoFTools::make_periodicity_constraints" function to apply periodic BCs. 
Since the arguments for this function are the paired boundary IDs, and 
again, they are the same in both cases (because I marked them manually), I 
do not see a reason why we get a different result.

Regards,
Masoud
On Saturday, 3 December 2022 at 16:01:03 UTC Wolfgang Bangerth wrote:

> On 12/3/22 03:38, Masoud Ahmadi wrote:
> > My expectation stems from the fact that I am using the exact same mesh, 
> but 
> > instead of using "GridGenerator" function of dealii, this time I import 
> a mesh 
> > from Cubit. Then, I mark the boundaries in the same order: left: 1, 
> right: 2, 
> > bottom: 3, up: 4. So, I think I did the exact same thing.
> > 
> > What happens is the order of DoF numbering changes (as shown in the 
> pictures). 
> > But since my mesh is the same, and so are the boundary IDs, I expect the 
> > results to be as I described since 
> "DoFTools::make_periodicity_constraints" 
> > function gets the boundary IDs as inputs.
>
> What I'm trying to say is that just because the two meshes describe the 
> same 
> geometric region in space does not mean that they are constructed in the 
> same 
> way. GridGenerator may use a different numbering of vertices than the 
> imported 
> mesh, for example.
>
> So I'll come back to the original question: Is what happens actually 
> wrong? Or 
> is it just unexpected?
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/b8d32052-b795-4621-a9a1-c414f95ec3e3n%40googlegroups.com.