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.