Timeline for MeshRefinementFunction for region gives error
Current License: CC BY-SA 4.0
28 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 17, 2018 at 21:24 | history | edited | Henrik Schumacher | CC BY-SA 4.0 | added 74 characters in body |
| Sep 28, 2018 at 13:52 | comment | added | user21 | @HenrikSchumacher, just a quick ping: I just merged the new code: So will get a different message when the function does not return True|False or a different one when the compilation does not work and it suggests with which arguments the compiled function needs to work. | |
| Sep 27, 2018 at 10:44 | comment | added | Henrik Schumacher | @user21 Nope, sorry. | |
| Sep 27, 2018 at 10:28 | comment | added | user21 | @HenrikSchumacher, you are not by any chance going to be in the US for the WTC conference, or are you? | |
| Sep 27, 2018 at 10:27 | comment | added | user21 | @HenrikSchumacher, stay tuned for that other half ;-) | |
| Sep 27, 2018 at 10:19 | comment | added | Henrik Schumacher | @user21 I'd say the first half is already great! Now it is about the other half ;) | |
| Sep 27, 2018 at 10:17 | comment | added | user21 | @HenrikSchumacher, I try my best to write a half decent FEM environment. | |
| Sep 27, 2018 at 10:14 | comment | added | user21 | @HenrikSchumacher, as a side note, the CF does not have to be free of MainEvaluate in fact that is the mechanism for a general call back from Triangle/TetGen for arbitrary functions. The problem in this case is that the compilation does not happen message free. One would have to go through some length to see if the CF is still OK to use, so I just gave a message (which I think is better then not saying anything at all). | |
| Sep 27, 2018 at 10:13 | comment | added | Henrik Schumacher | @user21 That would be great. I really appreciate that you take interaction with users so seriously! | |
| Sep 27, 2018 at 10:11 | comment | added | user21 | @HenrikSchumacher, OK, I'll see what can be done. | |
| Sep 27, 2018 at 8:36 | comment | added | Henrik Schumacher | Yeah, that could be a step forward. Yet, as a user, I would be prefer to be told which one of the to possible issues is the one that I should tackle. | |
| Sep 27, 2018 at 8:34 | comment | added | user21 | @HenrikSchumacher, thanks for the detailed response. How about the message text: "The MeshRefinementFunction XXX is not valid and will be ignored. Possibly the function does not return either True or False or the (auto) compilation failed. Try to provide a compiled function that evaluates to True or False with the arguments of YYYY" where YYYY in this case would be {{0., 0., 0.}, {1., 0., 0.}, {0., 1., 0.}, {0., 0., 1.}}, 1/6.} . | |
| Sep 27, 2018 at 7:06 | comment | added | Henrik Schumacher | (iv) The user cannot get more information on how to mend the issue, neither from the message nor from the doc page. I like error and warning messages that tell me to try this or that. For example, you could encourage the use to provide a CompiledFunction as MeshRefinementFunction and to check that the result of CompiledFuntionTools`CompilePrint is free of MainEvaluate? | |
| Sep 27, 2018 at 7:05 | comment | added | Henrik Schumacher | (iii) The doc page of MeshRefinementFunction does not state the requirement that the function should be compilable. Actually, DiscretizeRegion[reg, MeshRefinementFunction -> cf] just ignores cf = Function[{coordinates, vol}, vol > 0.00001 && RegionMember[Ball[Mean[coord], 0.5], Mean[coordinates]]]; without any message; that is also not a good user experience. If TetGenLink really cannot handle uncompiled refinement functions, in might be worth adding a section "Possible issues" that explains that. | |
| Sep 27, 2018 at 7:05 | comment | added | Henrik Schumacher | Can TetGenLink handle uncompiled refinement functions (e.g. by means of some reverse communication interface like Intel's FGMRES routines)? Then a noncompilable refinement function would not be an issue at all. But I expect that it requires a pointer to a library function instead. | |
| Sep 27, 2018 at 7:05 | comment | added | Henrik Schumacher | (ii) The generic user cannot grasp the meaning of the part the message that involves compiled functions. One needs a bit of experience with Compile in order to understand it. Moreover, the compilation happens in the background so that the user has no idea what is going on. And even the more experienced user cannot inspect the compiled function in order to single out the problem. Maybe the user can be spared from all these things by manipulating the backend code a bit? | |
| Sep 27, 2018 at 7:05 | comment | added | Henrik Schumacher | (i) The error message tries to cope with two rather different problems: The first problem is that the MeshRefinementFunction might be invalid in the sense that it does not evaluate to a Boolean. Imho, this will be the most frequently occuring problem so that it quite likely focusses all the users attention to it. The second is basically about the function not being compilable or not parallelizing correctly. Sure, it would be a bit tedious, but maybe the error handling can be made a bit more fine-grained? (Two different error messages instead of one.) | |
| Sep 27, 2018 at 7:04 | comment | added | Henrik Schumacher | @user21 Hmm. Good question. Speaking for myself, I stopped reading after "True or False". Several times. =/ Then I moved directly to the doc page of MeshRefinementFunction. And the only criterion for validity that is stated there is that the function returns a Boolean. After several rounds of guessing and trying, I finally saw "(auto) compiled function". Finally, that drove me to the conclusion that I posted above. I thought a lot about this but did not find a satisfactory answer. Maybe the problem is too complex for a single error message. I see the following issues: | |
| Sep 27, 2018 at 5:44 | history | edited | Henrik Schumacher | CC BY-SA 4.0 | deleted 1 character in body |
| Sep 27, 2018 at 4:51 | comment | added | user21 | @HenrikSchumacher, how should the message be written such that it is not confusing? If you have a suggestion I could improve the text. | |
| Sep 26, 2018 at 10:59 | history | edited | Henrik Schumacher | CC BY-SA 4.0 | added 1 character in body |
| Sep 26, 2018 at 10:52 | history | edited | Henrik Schumacher | CC BY-SA 4.0 | added 348 characters in body |
| Sep 26, 2018 at 10:41 | history | edited | Henrik Schumacher | CC BY-SA 4.0 | added 250 characters in body |
| Sep 26, 2018 at 10:38 | comment | added | Henrik Schumacher | You're welcome. | |
| Sep 26, 2018 at 10:38 | comment | added | N.Schl | Works fine. Thanks. | |
| Sep 26, 2018 at 10:37 | vote | accept | N.Schl | ||
| Sep 26, 2018 at 10:35 | history | edited | Henrik Schumacher | CC BY-SA 4.0 | added 175 characters in body |
| Sep 26, 2018 at 10:28 | history | answered | Henrik Schumacher | CC BY-SA 4.0 |