Sounds great!

Unfortunately I don't really know how to manually create arbitrary meshes in gmsh (the meshes it generates by default are "too good" for this purpose). However, here's at least one mesh that I think should be fairly horrible (and is aptly named). There are some points in there for which there are almost ten elements "between" the point and its closest mesh node. Naturally, you can make the mesh worse by an arbitrary factor by changing nodes 4-13 (increase y-coordinate or push x-coordinates closer to each other) or by adding more triangles in the same style.

I tested this mesh with the latest code from Github (which, I assume, doesn't contain the changes you're talking about). I used the same solution script as in the OP (just replaced "vertices of group 3" with "vertices of group 2"), and picked points randomly from the quadrilateral with corners at (0, 0), (0, 1), (-0.1, 4), (-1, 4). Using PointsProbe with close_limit=0.0, out of the 92475 random points as many as 55155 returned NaN.

I hope this helps. =)

-Jonatan

On Tuesday, April 28, 2015 at 7:30:49 PM UTC+3, Robert Cimrman wrote:

On 04/15/2015 01:02 PM, Robert Cimrman wrote:
> Hi Jonatan,
>
> On 04/15/2015 12:53 PM, Jonatan Lehtonen wrote:
>> Hi Robert,
>>
>> Do you have any timeline for when this bug might be fixed? I don't want to
>> rush you, I understand that it might be a pain to fix and you did mention
>> that you're busy. It would just be really helpful for me to know if I can
>> expect a fix in, say, the next month or so.
>
> I am about to merge in some pretty big changes of the internals (I will post a
> summary here), and then I may have some time to address this. So, if things go
> well, it might be fixed within a month.
>

I have the new code almost ready. To test it properly, a little help would be
appreciated - could you prepare some small meshes in gmsh with really ugly
elements (large size variations, elements with very acute angle, etc)?

It produces no nans with your original script...

r.