[Getdp] Why does Form 1 converge much slower than Form 1P on this problem?
Ningfeng HUANG
ningfengh at gmail.com
Tue Jul 28 19:08:14 CEST 2015
hi all,
sorry to bother again. I followed Michael's suggestion to add higher order
basis and it works well. Thanks Michael.
However, when I extended this into 3D structures, I cannot put
{ NameOfCoef en3a ; EntityType FacetsOf ; NameOfConstraint eConstraint ; }
{ NameOfCoef en3b ; EntityType FacetsOf ; NameOfConstraint eConstraint ; }
{ NameOfCoef en3c ; EntityType FacetsOf ; NameOfConstraint eConstraint ; }
in the Constraint in FunctionSpace.
The simulation works well without these defined in Constraints, otherwise I
saw the following error about the Link Constraint
"7-Constraint Link: bad correspondance of facets (1162, 3529)"
Is there any fundamental reason that I cannot define link constraints for
the facets or there is some bug in my code.
Thanks in advance.
Peter
On Mon, Jul 27, 2015 at 10:43 AM, Ningfeng HUANG <ningfengh at gmail.com>
wrote:
> Hi Michael.
>
> Thanks so much. It works!
>
> I stuck at this issue for about one month.
>
> Regards,
>
> Peter
>
> On Mon, Jul 27, 2015 at 9:32 AM, <michael.asam at infineon.com> wrote:
>
>> Hi Peter,
>>
>>
>>
>> the different result accuracy is due to the different polynomial order of
>> the basis functions.
>>
>> Let’s look at the lowest order basis functions:
>>
>>
>>
>> Form 1P represents a field which is pointing only in z-direction. This
>> (E) field
>>
>> is interpolated linearly between the nodes -> 1st order basis function.
>>
>>
>>
>> In contrast form 1 represents a field in the x-y plane for 2D-problems.
>> The lowest order basis function
>>
>> has a constant tangential vector component along each edge (order: 0)
>> which is interpolated
>>
>> linearly to the element interior (order: 1). Therefore it is usually said
>> to be of “order 0.5”.
>>
>> To have the same polynomial order along each edge as in form 1P, you need
>> a form 1 basis function
>>
>> which is one order higher.
>>
>> The same is true in your case. So just add one additional order to your
>> form 1 function space (BF_Edge_3F):
>>
>>
>>
>>
>>
>> FunctionSpace {
>>
>> { Name eSpace ; Type Form1 ;
>>
>> BasisFunction {
>>
>> { Name sn ; NameOfCoef en ; Function BF_Edge ; Support
>> TotAll ; Entity EdgesOf[All] ; }
>>
>> { Name sn2 ; NameOfCoef en2 ; Function BF_Edge_2E ; Support
>> TotAll ; Entity EdgesOf[All] ; }
>>
>> { Name sn3a; NameOfCoef en3a; Function BF_Edge_3F_a; Support
>> TotAll ; Entity FacetsOf[All] ; }
>>
>> { Name sn3b; NameOfCoef en3b; Function BF_Edge_3F_b; Support
>> TotAll ; Entity FacetsOf[All] ; }
>>
>> { Name sn3c; NameOfCoef en3c; Function BF_Edge_3F_c; Support
>> TotAll ; Entity FacetsOf[All] ; }
>>
>> }
>>
>> Constraint {
>>
>> { NameOfCoef en ; EntityType EdgesOf ; NameOfConstraint
>> eConstraint ; }
>>
>> { NameOfCoef en2 ; EntityType EdgesOf ; NameOfConstraint
>> eConstraint ; }
>>
>> { NameOfCoef en3a ; EntityType FacetsOf ; NameOfConstraint
>> eConstraint ; }
>>
>> { NameOfCoef en3b ; EntityType FacetsOf ; NameOfConstraint
>> eConstraint ; }
>>
>> { NameOfCoef en3c ; EntityType FacetsOf ; NameOfConstraint
>> eConstraint ; }
>>
>> }
>>
>> }
>>
>> }
>>
>>
>>
>>
>>
>> Cheers,
>>
>> Michael
>>
>>
>>
>>
>>
>>
>>
>> *From:* getdp [mailto:getdp-bounces at ace20.montefiore.ulg.ac.be] *On
>> Behalf Of *Ningfeng HUANG
>> *Sent:* Friday, July 24, 2015 1:50 AM
>> *To:* getdp at geuz.org
>> *Subject:* [Getdp] Why does Form 1 converge much slower than Form 1P on
>> this problem?
>>
>>
>>
>> Dear all,
>>
>>
>>
>> Currently I am trying to solve a very simple 2D electromagnetic problem
>> with GetDP, which is the transmission of plane wave through a dielectric
>> slab. I attached the simulation configuration and the result as a PDF
>> document with this mail.
>>
>>
>>
>> It is a slight modification from the waveguide example on OneLab website.
>> A high index slab (n=3.5) with thickness T is inserted in the middle of the
>> simulation region. The upper and lower boundaries are changed from PEC to
>> periodic to represent the infinity slab structure. The mode on port 1 is
>> changed to plane wave. I simulated this structure to get the transmission
>> spectra (S21) in two different ways with different polarizations:
>>
>>
>>
>> 1.s-polarization: the electric field is perpendicular to the 2D plane
>> (Ez). The simulation is in Form 1P.
>>
>>
>>
>> 2.p-polarization: the electric field is parallel to the 2D plane (Ey).
>> The simulation is in Form 1.
>>
>>
>>
>> In principle, these two approaches represent the same configuration,
>> which is the infinitely extended slab with the normal incident light.
>> However, Form 1P converges much better than the Form 1. The result is shown
>> in the PDF document. The analytical result from transfer-matrix method is
>> also shown for reference. For s-polarization and Form 1P, all curves with
>> different resolutions are overlap with each other and match well with the
>> analytical result even with only 3 grid points per wavelength. However, for
>> p-polarization and Form 1, there is a systematic shift to the higher
>> frequency (lower wavelength) when the resolution is reduced. Even with 7
>> grids per wavelength, there is a large discrepancy to the analytical
>> result.
>>
>>
>>
>>
>>
>> I wonder why there is a huge difference between Form 1P and Form 1 and
>> whether I can modify my code in Form 1 to have the similar accuracy as Form
>> 1P. It would be nice that I have similar accuracy with Form 1. My final
>> goal is to simulate 3D structures (in Form 1P) and this shift is also
>> observed in my 3D simulations.
>>
>>
>>
>> Here is some thoughts from my intuition. The blue shift of the spectra
>> can be caused by the effectively thinning of the high index material. I
>> suspect that I missed defining the proper basis for the surface such that
>> the grid at the interface is not considered as the high index material. The
>> lower the resolution, the larger the surface grid, thus the thinner the
>> effective slab thickness.
>>
>>
>>
>> I attached my code for both Form 1 and Form 1P with this mail and matlab
>> (octave) scripts to run the batch simulation and plot the result. I
>> appreciate any kind of comments. I really want to know whether this is the
>> bug in my (OneLab) code, or bug in GetDP or just fundamental limitation in
>> the finite-element method.
>>
>>
>>
>> Regards,
>>
>>
>>
>> Peter
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.geuz.org/pipermail/getdp/attachments/20150728/e75e83f7/attachment.html>