Re: [deal.II] Importing nodal BCs and accessing vertices

[Alex Quinlan]

Thanks, Luca.  I will try to implement your suggestions.

Best regards,
Alex

On Thursday, April 11, 2024 at 4:03:08 PM UTC-4 luca@gmail.com wrote:

> If you have access to the DG, you can call 
> dh.get_triangulation().n_active_cells(). 
>
> Take a look at the tests subdirectory to find more inspiration on more 
> ways to exploit your information. 
>
> For example, I’d use DoFTools::map_dofs_to_support_points, use that to 
> generate an r tree of indices, and then just ask for the one nearest 
> neighbor (in the tests subdirectory there are a few examples that show how 
> to do this for collections of points). 
>
> Luca
>
> Il giorno 11 apr 2024, alle ore 15:43, Alex Quinlan  
> ha scritto:
>
> 
>
> Hi Wolfgang,
>
> I've gotten an R-tree subroutine set up for applying my boundary 
> conditions based on rtree_8h.html 
> .  It seems 
> to work, but I have a couple difficulties that I've highlighted in red. 
> Hopefully, others might find use in my adaptation of the example and in my 
> questions.
>
>
> My subroutine takes the following arguments: the DOF handler, the 
> constraints object, and a vector of a custom nBC structure for holding the 
> nodal boundary conditions that I've read from the file.
>
> template 
> void nodal_bcs_rtree(std::vector   &  nBCs, 
>  dealii::DoFHandler   & 
>  dof_handler,   
>   dealii::AffineConstraints  & constraints )
>  {
>namespace bgi = boost::geometry::index;
>
>//  Create the R-tree ---
>std::vector> all_boxes(*10*);  //  TODO Need a way 
> to set the correct size for this
>std::vector false> >> cell_list(*10*);
>
>unsigned int i = 0;
>for (const auto &cell : dof_handler.active_cell_iterators())
>  if (cell->is_locally_owned())
>  {
>all_boxes[i] = cell->bounding_box();  // prepare the bounding boxes to 
> be packed into the r-tree
>cell_list[i++] = cell;// create a corresponding vector 
> of cells accessors
>  }
> const auto idx_tree  = pack_rtree_of_indices(all_boxes);
>
>//  Search the R-tree 
>
>const double nrad = 1e-5;  // Tolerance on vertex position TODO make 
> relative to cell size
>
>for (nBC bc : nBCs)
> {
> std::vector closest_cell_idx;
> idx_tree.query(bgi::nearest(bc.coords,1), 
> std::back_inserter(closest_cell_idx));  // bc.coords is type Point<3>
>
> if (closest_cell_idx[0] < i-1)  // Check that the cell index number 
> will correspond to an actual cell in cell_list
> {
> const auto cell = cell_list[closest_cell_idx[0]];
>
> for (unsigned int v = 0; vn_vertices() ; v++) {
>if (cell->vertex(v).distance(bc.coords) < nrad){
>  ~~~Apply constraints ~~~
>  }
>   }
> }
> }
> }
>
>
> 
> 1) I'm having trouble getting the number of cells, and then sizing my 
> vectors appropriately.  From what I can see, the DoFHandler won't provide 
> the number of cells, only the number of DoFs.  In the short term, I've just 
> thrown in the number 100,000 as the vector size.  In the example ( 
> https://www.dealii.org/current/doxygen/deal.II/rtree_8h.html ), the line: 
>
>std::vector> all_boxes(tria 
> 
> .n_locally_owned_active_cells());
>
> gets used to set the vector size.  From within my subroutine, I don't have 
> access to the triangulation object. Am I missing a way to get 
> "n_locally_owned_active_cells" from the DoFHandler?  Or should I just pass 
> this value in as an argument to my subroutine?
>
>
> 2) Does my approach of creating vectors to hold the bounding boxes and the 
> cell pointers make sense?  Is there a better way to get access to the cell 
> once I've determined the BoundingBox index from the R-tree?
>
> 3) Somewhat related to question 1, is there a way to check that the 
> 'closest_cell' was actually found?  I had an issue with MPI where the 
> target point 'bc.coords' was outside the bounding box of some processes, 
> resulting in some errors.  I set this (closest_cell_idx[0] < i-1) to 
> check that an actual BoundingBox was found.
>
>
> Thanks for your suggestion on the R-tree.  I'd welcome any critiques of my 
> implementation.
>
> Cheers,
> Alex
> On Wednesday, November 15, 2023 at 8:35:49 AM UTC-5 Alex Quinlan wrote:
>
>> Thanks, Wolfgang.  I will abide by those guidelines.
>>
>> On Tuesday, November 14, 2023 at 10:15:29 PM UTC-5 Wolfgang Bangerth 
>> wrote:
>>
>>> On 11/14/23 16:25, Alex Quinlan wrote: 
>>> > 
>>> > I'm curious what your thoughts are on this approach.  I imagine it 
>>> could have 
>>> > an advantage in some situations, depending on the size of the mesh and 
>>> the 
>>> > number of constraints to be added. 
>>> > 
>>> > I have not done any speed testing on this yet, tho.  Do you think it 
>

[deal.II] Short course in Chennai, India -- April 20 to May 3, 2024

[Wolfgang Bangerth]

All,
if you live in India or thereabouts, can travel on short notice, and are 
interested in the

  FINITE ELEMENT METHOD IN SCIENTIFIC COMPUTING: A SHORT COURSE
then this is for you: I will be teaching in Chennai, India, April 20 to May 3, 
2024.


For details, please see
  https://civil.iitm.ac.in/pcoe/smge/term-course-2024.php

Best
 Wolfgang

--

Wolfgang Bangerth  email: bange...@colostate.edu
   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 dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/bc475b78-031d-475d-9297-d93286b020b1%40colostate.edu.