Re: [Getfem-commits] merge request for touched_region_for_projected_fem
Thank you, Kostas On Wed, 10 Mar 2021, 17:08 Konstantinos Poulios, wrote: > Hi Andriy, > > Sorry for the delay. I hadn't noticed your previous reply. Your commits > have been rebased/squashed/merged. All of your changes should be in the > current master. If you confirm this, you can delete the > touched_region_for_projected_fem branch yourself. > > Thanks for the useful new function. > > Best regards > Kostas > > On Tue, Mar 9, 2021 at 9:37 AM Andriy Andreykiv < > andriy.andrey...@gmail.com> wrote: > >> Kostas, hi, >> >> Did you have a chance to review my latest commits? >> Thanks, >> Andriy >> >> On Fri, 5 Mar 2021 at 09:27, Konstantinos Poulios < >> logar...@googlemail.com> wrote: >> >>> Thanks. I see your point about "intersected". I think >>> "projected_target_region" is a good name. >>> >>> If you do this change I can squash and merge your commits. >>> >>> Best regards >>> Kostas >>> >>> On Thu, Mar 4, 2021 at 2:06 PM Andriy Andreykiv < >>> andriy.andrey...@gmail.com> wrote: >>> Hi Konstantinos, Replaced almost all the auto's. Regarding intersected_target_region, that could be, but for me the word intersected would be appropriate if it was interpolated_fem where the regions intersect. Physically it feels like touch, but I agree that we have touch() in context_dependencies which might be confusing. Here I feel a need for the concept of projection. I personally need a name that condenses the sentence "region that contains part of the target where the source is projected on". Can we say projected_target_region? We can also go with supported_target_region()? Let me know what you think, Andriy On Thu, 4 Mar 2021 at 12:38, Konstantinos Poulios < logar...@googlemail.com> wrote: > 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 >>> >>> >>>
Re: [Getfem-commits] merge request for touched_region_for_projected_fem
Hi Andriy, Sorry for the delay. I hadn't noticed your previous reply. Your commits have been rebased/squashed/merged. All of your changes should be in the current master. If you confirm this, you can delete the touched_region_for_projected_fem branch yourself. Thanks for the useful new function. Best regards Kostas On Tue, Mar 9, 2021 at 9:37 AM Andriy Andreykiv wrote: > Kostas, hi, > > Did you have a chance to review my latest commits? > Thanks, > Andriy > > On Fri, 5 Mar 2021 at 09:27, Konstantinos Poulios > wrote: > >> Thanks. I see your point about "intersected". I think >> "projected_target_region" is a good name. >> >> If you do this change I can squash and merge your commits. >> >> Best regards >> Kostas >> >> On Thu, Mar 4, 2021 at 2:06 PM Andriy Andreykiv < >> andriy.andrey...@gmail.com> wrote: >> >>> Hi Konstantinos, >>> >>> Replaced almost all the auto's. Regarding intersected_target_region, >>> that could be, but for me the word intersected would be appropriate if it >>> was interpolated_fem where the regions intersect. >>> Physically it feels like touch, but I agree that we have touch() in >>> context_dependencies which might be confusing. >>> Here I feel a need for the concept of projection. I personally need a >>> name that condenses the sentence "region that contains part of the target >>> where the source is projected on". Can we say >>> projected_target_region? We can also go with supported_target_region()? >>> >>> Let me know what you think, >>> Andriy >>> >>> >>> >>> On Thu, 4 Mar 2021 at 12:38, Konstantinos Poulios < >>> logar...@googlemail.com> wrote: >>> 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 >> >> >>
[Getfem-commits] [getfem-commits] branch master updated: Add projected_fem::projected_target_region() function
This is an automated email from the git hooks/post-receive script.
logari81 pushed a commit to branch master
in repository getfem.
The following commit(s) were added to refs/heads/master by this push:
new 05989af Add projected_fem::projected_target_region() function
05989af is described below
commit 05989af44c2e90fade549070462b3201e59e6a6e
Author: Andriy Andreykiv
AuthorDate: Wed Mar 10 16:59:10 2021 +0100
Add projected_fem::projected_target_region() function
---
src/getfem/getfem_projected_fem.h | 4
src/getfem_projected_fem.cc | 22 ++
2 files changed, 26 insertions(+)
diff --git a/src/getfem/getfem_projected_fem.h
b/src/getfem/getfem_projected_fem.h
index ae216b9..840362f 100644
--- a/src/getfem/getfem_projected_fem.h
+++ b/src/getfem/getfem_projected_fem.h
@@ -141,6 +141,10 @@ namespace getfem {
/** return the list of convexes of the projected mesh_fem which
* contain at least one gauss point (should be all convexes)! */
dal::bit_vector projected_convexes() const;
+
+/** faces and convexes from the target region
+ * that contain at least one Gauss point that is projected by the source
*/
+mesh_region projected_target_region() const;
/** return the min/max/mean number of gauss points in the convexes
* of the projected mesh_fem */
diff --git a/src/getfem_projected_fem.cc b/src/getfem_projected_fem.cc
index fa73548..a5f0d68 100644
--- a/src/getfem_projected_fem.cc
+++ b/src/getfem_projected_fem.cc
@@ -795,6 +795,28 @@ namespace getfem {
return bv;
}
+ mesh_region projected_fem::projected_target_region() const {
+context_check();
+mesh_region projected_target;
+for (mr_visitor v(rg_target); !v.finished(); ++v) {
+ pintegration_method pim = mim_target.int_method_of_element(v.cv());
+ papprox_integration pai = pim->approx_method();
+ size_type start_pt = v.is_face() ? pai->ind_first_point_on_face(v.f()) :
0;
+ size_type nb_pts = v.is_face() ? pai->nb_points_on_face(v.f())
+ : pai->nb_points_on_convex();
+ bool isProjectedOn = false;
+ for (size_type ip = 0; ip != nb_pts; ++ip) {
+auto _data = elements.at(v.cv()).gausspt[start_pt + ip];
+if (proj_data.iflags) {
+ isProjectedOn = true;
+ break;
+}
+ }
+ if (isProjectedOn) projected_target.add(v.cv(), v.f());
+}
+return projected_target;
+ }
+
void projected_fem::gauss_pts_stats(unsigned , unsigned ,
scalar_type ) const {
std::vector v(mf_source.linked_mesh().nb_allocated_convex());
