-
Notifications
You must be signed in to change notification settings - Fork 76
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MeshLine.refine #633
Comments
But given >>> m.p
array([[0. , 1. , 0.5]])
>>> m.t
array([[0, 2],
[2, 1]]) which looks O. K., not sorted, but O. K., but then >>> m.element_finder()(np.array([.2]))
array([1])
>>> m.element_finder()(np.array([.7]))
array([0]) |
So |
I think there is some sort of assumption inside |
It does assume that the start point of interval is |
The original version before #630 gave the correct result here. I'll have to check #630 carefully. |
Alright, so it was a change from |
Does #634 fix the issue in the point source? |
No, it gives different answers for mesh = skfem.MeshLine(np.linspace(0, 1, 2 ** 1 + 1)) and mesh = skfem.MeshLine().refined(1) and indeed >>> MeshLine(np.array([0, .5, 1])).element_finder()(np.array([.7]))
array([0])
>>> MeshLine().refined(1).element_finder()(np.array([.7]))
array([1]) The first of these is wrong, since >>> m = MeshLine(np.array([0, .5, 1]))
>>> m.p[0, m.t]
array([[0. , 0.5],
[0.5, 1. ]]) (Both meshes look the same in terms of |
While working on the point source #632, trouble was encountered with
MeshLine().refined()
and this was traced toelement_finder
:I'm not sure which of these is right. I mean the first is wrong since 0.7 is definitely in the second element, but I'm not sure about the second. Are the points passed to the constructed assumed increasing?
The text was updated successfully, but these errors were encountered: