Hi Robert,
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
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
size 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.