Ok, I tried using .2 instead of .i1 and it also works.
2012/8/30 Robert Cimrman cimr...@ntc.zcu.cz:
thanks for the info. Anyway, I would recommend you not to use a single named integral for both the volume and surface integration, as I have written below, at least for the moment.
On 08/30/2012 10:01 AM, David Libault wrote:
No I did not get this error, and I was going to tell you... My platform is Mac OSX + MacPorts. I use MacPorts python 2.7 and sfepy installed manually from git.
Le mercredi 29 août 2012 18:07:50 UTC+2, Robert Cimrman a écrit :
On 08/29/2012 05:59 PM, Robert Cimrman wrote:
On 08/29/2012 05:21 PM, David Libault wrote:
Enclosed are a mesh file and a problem file for the 2D electrostatic problem without volume charge of a square of 1x1 on which 1 V is
2 opposite sides (Gamma_Left and Gamma_Right), and the default 0 Von Neumann boundary conditions on the 2 other sides.
The Electric field is evaluated as the gradient of V, and looks good
small, and Ey = 1 over the entire domain).
Yes, it looks good.
Flux 1 and Flux 2 evaluate the flux intensity of current with
sigma=1 across Gamma_Left and Gamma_Right. They should have opposite
and absolute value of 1.
It looks that the d_surface_flux is computed on each element of the
so the returned value is an array, but the values in the array are all
Shouldn't they be 1/(element surface) so that the sum of the array
the total flux over the all Gamma_Left or Gamma_Right surface ?
There is a glitch in using integrals I noticed when preparing the
Alec: once you use an integral for a volume integration (volume term),
should not use it for a surface term. If you do that, you should get an
and indeed, there is:
fmf_mulAB_nn(): ERR_BadMatch: (2 2 1) == (3 2 2) * (2 2 1)
Ha, you actually did not get this error, right? What's your platform and Python version?
printed just before your flux output. This should lead to raising an
but for some reason it does not, the exception is raised only when I
the relevant code piece with a debugger. If I just run the code, it
continues, and leads to wrong results you got. So this is definitely a
I am not sure why it behaves this way. It used to work.
So to fix you problem: replace flux1 = pb.evaluate('d_surface_flux.i1.Gamma_Left(coef.sigma, v)', mode='el_avg')
flux1 = pb.evaluate('d_surface_flux.2.Gamma_Left(coef.sigma, v)',
and do the same with flux2. The number is the quadrature order... Then
should get the "correct" fluxes. If fact, there is another problem -
mode divides the resulting integrated value in an element by the volume/area/length of that element. That's why you get 1 or -1, and the
and -9, as there are 9 edges on each of Gamma_Left, Gamma_Right.
So it seems another evaluation mode is needed (let's say called 'el') -
that just integrates a value over an element, without computing the
dividing by volume. Do you agree?
-- You received this message because you are subscribed to the Google Groups "sfepy-devel" group. To post to this group, send email to sfepy...@googlegroups.com. To unsubscribe from this group, send email to sfepy-devel...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.