Hmm.. also I just noticed that simple.py complains that all is not well. The output really *looks* reasonable though!
On 06/06/2012 04:33 PM, steve wrote:
> Hi Robert,
>>> OK. So it seems that for the above, you could use directly dw_laplace
>>>> dw_volume_dot terms, with material arguments equal to 2\pi r and 2\pi
>>>> respectively. Or just r, and put the known constants directly into the
>>>> equations string.
>>> Hmm.. OK. I'll try to wrap my head around that. ;-)
>> I will try to support you, don't worry.
> Well... I've had some success here, I think!
Glad to hear that!
> here's the setup file 'es-test.py' which is trying to model a cylindrically
> symmetric electrostatic lens. The results compare favorably with a
> relaxation code with the same setup. Now of course I have a couple of
> issues that I hope you can help me with.
Nice! Could you send me also the mesh? (off-list, if it's big...) So this just
solves the direct problem, not the eigenvalue problem, right?
> 1) In the relaxation version I have to impose the du/dr=0 boundary
> condition at r=0 at each time step. I made no mention of that BC in the
> setup file, but the solution seems to respect it more or less
> automatically. I remember in the examples seeing mention of "zero flux"
> over the boundary. Is this just a consequence of leaving out the boundary
> integral in the weak formulation?
Yes, by leaving out the boundary integral you impose the zero flux.
> 2) I've developed a simple wxpython app that allows a user to specify
> voltages on, and position/geometry of the lenses and then compute particle
> trajectories through the system. My relaxation algorithm is currently
> limited to a uniform rectangular mesh. Part of my motivation for pursuing
> sfepy is the possibility of using variable/arbitrary mesh density. However,
> to run this test I had to generate a mesh in gmsh and then hand-edit the
> output to get a .mesh file that was acceptable to sfepy. I'd like to
> increase the density of nodes around the corners of the conductors in the
> problem (especially around the needle where the particles are introduced).
> Any thoughts on dynamically building meshes in code to accomplish this?
What had to be changed in the gmsh-generated mesh? INRIA medit format (.mesh)
should work - if it does not, it should be fixed.
As sfepy cannot do the meshing/adaptive refinement, so you will need to call an
external mesher (e.g. gmsh) to do that. Skimming the gmsh docs seems to suggest
that it's possible to drive it from Python. If you choose to go that path, I
would really like to see the result - having a MeshIO class taking a gmsh mesh
description file and returning the mesh would be great.
> Anyway.. thanks for the help! I think it's working pretty well after I
> finally groked how variable materials work in the setup file.