should we also briefly discuss the name of the function? In mathematical terms I would call it
support_region But a more popularized name might be easier to understand in general. However, I do not like "touched" because "touch" is typically used in programming for denoting change in state, so your current name I understand it as a region that has state A and changes to state B. We could instead call it intersected_target_region or something similar. Other ideas? In general I think we should spend some effort in good names because once a name is in the API it is more difficult to remove. Best regards Kostas On Thu, Mar 4, 2021 at 12:31 PM Konstantinos Poulios < logar...@googlemail.com> wrote: > Hi Andriy, > > Thanks, I see how it can be useful. Could I ask you to reduce the use of > auto for this commit? For example it does not make much sense to use auto > for bool. In general my preference for the GetFEM codebase is to use auto > only if some type is particularly long and makes the code significantly > less readable. Otherwise the type of the variables is useful information > for people that will read and try to understand the code later. > > There is also a typo in a comment. It should be "Gauss". > > Best regards > Kostas > > On Thu, Mar 4, 2021 at 11:32 AM Andriy Andreykiv < > andriy.andrey...@gmail.com> wrote: > >> Dear Yves and Konstantinus, >> >> Kind request to review and merge touched_region_for_projected_fem branch. >> It introduces a method for projected_fem that extracts a region from the >> target that is actually touched by the source. >> I use this region to integrate my mortar terms on. >> >> Best regards, >> Andriy >> >> >>
