I will try this tomorrow and let you know.  My platform is 64bit Ubuntu, I cloned the repo on 7/22 so I'm at revision 433a3bc2a6a84d93145b04ee7d3debb493de0e50.

The linear system converges nicely and the voltage values look nice and smooth so I don't think there is anything grossly wrong.  I think theres some issue with how flux is being integrated that is not exposed with the flat cylinder example.

I tried a similar test with a simple cube on Friday, and the results were correct when I had the source and sink on opposing faces of the cube.  However, once I included more of the orthogonal faces in the source, I saw the issue again.  I'll post the mesh and the python script for this tomorrow.

One more thing I wanted to try is to look at the flux values across the whole surface under some of these scenarios.  I understand that I can pull out the surface values using mode='el', and same them in the vtk output file.  But I'm not sure how to map them back to the appropriate vertex positions in order to visualize the flux.  Can you suggest the best way of doing this?  I'll post a screenshot once I have it.

Geoff

On Friday, August 1, 2014 5:58:53 PM UTC-4, Robert Cimrman wrote:

On 08/01/2014 09:25 PM, Geoff Wright wrote:
> Hi Robert,
>
> I didn't try the cube idea yet, but I tried simplifying to a single sphere
> and adding a source one one side and a sink on the other.  Flux still not
> making sense.  See scripts attached.  Flux output is:
>
> Source flux:  2.50129488048
> Sink flux:  -1.46351297349
> Block flux:  -0.929787940721
> Entire surf:  -1.4574793787
>
> Also noticed that if I run it several times, sometimes the source or sink
> flux will show up as 'nan', which is worrying.  Is it possible that the
> surface_flux calculation is not reliable in the case of a curved surface
> such as a sphere?  The general distribution looks correct..

This is strange, nans should not be there. I did not get them in my runs.

The surface flux term is sort of dangerous by definition, as you need to
compute a gradient on a surface - that requires more regularity in general than
the weak solution has. But it behaved ok in my examples, including the
poisson_neumann.py, that has a curved boundary as well. It's true that the
nonzero flux regions are flat there, and the gradient is constant in planes
perpendicular to the long axis - this may have a role too.

Try to edit the site_cfg.py:

debug_flags = '-DDEBUG_FMF'

and also remove optimization in compile_flags. Then rebuild the sources.

Another thing that is strange is that I get different flux values from you (but
equally wrong):

Source flux:  2.09499463797
Sink flux:  -1.44302331431
Block flux:  -0.68702181322
Entire surf:  -0.0350504895656

What is your platform and sfepy version? Also, the linear system solution
converges well?

So: there might be a bug. Trying that on a rectangular shape might shed some
light on the problem.

r.

> On Friday, August 1, 2014 2:19:54 PM UTC-4, Robert Cimrman wrote:
>>
>> On 08/01/2014 05:26 PM, Geoff Wright wrote:
>>> Hi Robert,
>>>
>>> Yes, I generated the domain using gmsh.  I have tried uniform cell size
>> and
>>> the numbers are different but still off.  I checked the surface areas of
>>> the inner and outer spheres, they come out ~3% below the theoretical
>> sphere
>>> surface area but i'm assuming this is due to the mesh approximation.  As
>>> far as I can tell the meshes and regions are okay.
>>>
>>> Please let me know if you have any ideas.. I attached the .geo file that
>> I
>>> used to generate the meshes, in case it is useful.
>>
>> Maybe try a cube_inside_cube mesh aligned with axes, so that the normals,
>> surface areas, etc. could be easily checked and meshing artefacts were
>> minimized. Do you have a setup where an analytical solution is known?
>>
>> r.
>>
>>
>