David Wells fixed the issue, so all of the credit goes to him :-) On Thursday, July 27, 2017 at 10:12:16 AM UTC+2, Giovanni Di Ilio wrote: > > Great! > Thank you very much Jean-Paul for the very quick fix! > > Best, > Giovanni > > > > On Thursday, July 27, 2017 at 9:47:48 AM UTC+2, Jean-Paul Pelteret wrote: >> >> Dear Giovanni, >> >> This bug was confirmed and fixed >> <https://github.com/dealii/dealii/pull/4659>, so hopefully if you try >> this now with the development version you should no longer have any issues. >> Thanks again for reporting the problem! >> >> Best, >> Jean-Paul >> >> On Tuesday, July 25, 2017 at 10:13:51 AM UTC+2, Giovanni Di Ilio wrote: >>> >>> Dear Jean-Paul, >>> >>> (I tried also version 8.4.1 and same problem). >>> Ok, thanks a lot! >>> >>> Best, >>> Giovanni >>> >>> On Tuesday, July 25, 2017 at 9:08:53 AM UTC+2, Jean-Paul Pelteret wrote: >>>> >>>> Dear Giovanni, >>>> >>>> Thank you very much for the clear and simple test case! I've played >>>> around with it and I don't see any fault in the way that you're trying to >>>> use the mapping functionality, so I think that its quite clear that >>>> there's >>>> something wrong with Mapping::transform_real_to_unit_cell. I've tested >>>> this >>>> with both deal.II 8.5 and the development version and the problem exists >>>> in >>>> both cases. I've opened a issue on GitHub >>>> <https://github.com/dealii/dealii/issues/4654> that uses your example >>>> to demonstrate the problem. I'll report back here when we make some >>>> headway >>>> towards solving the issue! >>>> >>>> Best regards, >>>> Jean-Paul >>>> >>>> On Tuesday, July 25, 2017 at 12:29:51 AM UTC+2, Giovanni Di Ilio wrote: >>>>> >>>>> Sorry, I thought I worked around the problem but actually I did not. >>>>> The mapping fails again when I work with a refined mesh, for both the >>>>> cases >>>>> of a mesh read in from gmsh and a mesh generated with Deal. >>>>> >>>>> I try to explain better what I mean: >>>>> 1) I generate a grid, using: >>>>> *GridGenerator::subdivided_hyper_rectangle(triangulation,repetitions,p1,p2)* >>>>> >>>>> ; >>>>> 2) I refine one time the grid with: *triangulation.refine_global(1)* ; >>>>> 3) I run over the cells and I try to get the mapped position of a >>>>> given point, which I set to be in the centre of the considered cell: >>>>> *mapping.transform_real_to_unit_cell*. >>>>> >>>>> Since the point I am testing is exactly in the centre of the cell I >>>>> expect the mapped position, in the unit cell, to be x = 0.5; y = 0.5. >>>>> However, for some "random" cell, again, the mapping fails. >>>>> >>>>> Here I am not dealing anymore with the digits of accuracy. >>>>> The numbers I am dealing with are the coordinates of the vertexes >>>>> provided by the GridGenerator and the coordinates of a testing point, >>>>> which >>>>> have just a couple of digits after comma. Moreover, the spacing between >>>>> vertexes for the cells I am considering is of the order of 0.1. >>>>> >>>>> I attach a very simple example, where I consider a uniform grid of 5 x >>>>> 5 elements (repetitions[0]=repetitions[1]=5), refined one time, so 100 >>>>> elements in total. >>>>> For cell with index 96 of my example, which vertexes are: >>>>> vertex(0): 0.8 0.8 >>>>> vertex(1): 0.9 0.8 >>>>> vertex(2): 0.8 0.9 >>>>> vertex(3): 0.9 0.9 >>>>> I test the point (0.85, 0.85) and the mapped position in the unit cell >>>>> results to be: (0.5, 0.46875) instead of (0.5, 0.5). >>>>> >>>>> You may notice that, by running the example with refineglobal(false), >>>>> the mapping on an equivalent grid made of 10 x 10 elements, with no >>>>> refinements (repetitions[0]=repetitions[1]=10), works just fine. >>>>> I don't see any difference between the two cases. >>>>> What is missing here? Can you help me please? >>>>> >>>>> Thank you very much, >>>>> Best, >>>>> >>>>> Giovanni >>>>> >>>>> >>>>> >>>>> On Saturday, July 22, 2017 at 8:57:57 PM UTC+2, Wolfgang Bangerth >>>>> wrote: >>>>>> >>>>>> On 07/22/2017 04:42 AM, Giovanni Di Ilio wrote: >>>>>> > >>>>>> > Yes, I agree, the issue is definitely related to round-off error. >>>>>> But I still >>>>>> > don't understand why the mapping fails, if the vertex coordinates >>>>>> read in from >>>>>> > my .msh file are apparently stored as doubles... >>>>>> > Anyway, yes, the problem is easily overcome by "manipulating" the >>>>>> values >>>>>> > before mapping. >>>>>> >>>>>> The numbers you consider differ in the last two or three bits when >>>>>> stored as >>>>>> double precision. Any computations you do with them, for example in >>>>>> the >>>>>> mapping, will then necessarily be completely off. >>>>>> >>>>>> Best >>>>>> W. >>>>>> >>>>>> -- >>>>>> ------------------------------------------------------------------------ >>>>>> >>>>>> Wolfgang Bangerth email: >>>>>> [email protected] >>>>>> www: >>>>>> http://www.math.colostate.edu/~bangerth/ >>>>>> >>>>>>
-- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
