dolfin team mailing list archive

[Kristian Ølgaard <k.b.oelgaard@xxxxxxxxx>]

On 13 June 2011 16:07, Neilen Marais <nmarais@xxxxxxxxx> wrote:
> Hi,
>
> Has the calculation of auto quadrature order changed recently?

Yes, UFL revno: 1088.
This changeset updated the estimate_total_polynomial_degree()
function to take into account spatial coordinates when computing the degree.

Try something like this in your code:

from ufl.algorithms import estimate_total_polynomial_degree
...
print "L degree: ", estimate_total_polynomial_degree(L)

to see if the degree is conservative enough for your application, then
you can decide if you want to leave the default degree at 'auto' or
specify it yourself.

Kristian

> I've set up the electromagnetic near-to-farfield transform based on
> the integral of tangential electric and magnetic fields around the
> boundary of the problem. I got incorrect results on a canonical test
> problem and wasn't sure of the source of the error. I'm evaluating
> complex integrals like:
>
> L =   surface_integral_over_Gamma( (-n x E(r_prime) )
> e^(j*k0*dot(r_prime, r_hat))ds(r_prime) )
>
> where E is the E-field vector, r_hat is a unit vector pointing in the
> far-field observation direction and r_prime is the integration
> coordinate and Gamma is the closed near-to-farfield transform surface.
> Since the integrals are complex, I had to split them up into several
> real integrals making the whole thing quite complicated. In real
> components, the complex exponential is of course broken into sin/cos
> terms. Since E is a vector quantity, I also needed to take the dot
> product with unit vectors, so the final forms looked like:
>
> from dolfin import *
> V = FunctionSpace(mesh, "Nedelec 1st kind H(curl)", 2)
> E_r = Function(V) # real part
> E_i = Function(V) # imaginary part
> ....
> phase = k0*dot(r_prime, rhat)
> n = V.cell().n
> rprime = V.cell().x
>
> # theta and phi are the far-field observation angles
> import math
> rhat_ = math.sin(theta)*math.cos(phi), math.sin(theta)*math.sin(phi),
> math.cos(theta)])
> theta_hat_ = math.cos(theta)*N.cos(phi),
> math.cos(theta)*math.sin(phi), -math.sin(theta)]
> rhat = Constant(rhat_)
> theta_hat = Constant(theta_hat_)
>
> M_r = -cross(n, E_r)
> M_i = -cross(n, E_i)
> L_r_theta =  dot(theta_hat, M_r*cos(phase) - M_i*sin(phase))*ds # real
> part of Theta component of L
>
> After some experimentation I manually specified the integration order,
> and suddenlty the results seemed quite good! What is strange is that I
> could not replecate the bad 'auto' order results, even by specifying
> zero or first order integration. Today I upgraded my fenics
> installation to the latest development version, and now the auto
> results are also looking good. I realise that the inclusion of the
> cos/sin terms complicate matters somewhat, but I would just like to
> have a feeling for what is going on with the auto quadrature. Would it
> be sensible to leave the quadrature order default at 'auto' going
> forward, or should I rather be setting it explicitly?
>
> Thanks
> Neilen
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dolfin
> More help   : https://help.launchpad.net/ListHelp
>