[deal.II] Re: neighboring faces on the boundary

[Jean-Paul Pelteret]

>
> Since Erik explicitly asks for a way to "get the degrees of freedom living 
> on the set of faces", I would still just modify the referenced code to 
> return face_iterators and access the corresponding DoFs using them.
>

You're 100% correct, I misread the question (well, rather I focussed on the 
first half and didn't regard that Erik specifically wanted a list of face 
DoFs in the end). I agree that what you propose is the best way to do this. 
Sorry for the confusion!

J-P

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: neighboring faces on the boundary

[Daniel Arndt]

>
> We actually already have a function that can do 1/2 the job for you, 
> namely GridTools:: compute_active_cell_halo_layer 
> .
>  
> In this instance your predicate would be whether the input cell has a face 
> on the patch you've specified. You'd then remove from this list all of the 
> cells that are not on the boundary. It might be a bit expensive to use if 
> you compute for many patches, because it does a loop over all cells in the 
> triangulation. We could, however, look at extending the function for 
> multiple predicates leading to the output of multiple collections of cells, 
> one for each predicate.
>
As far as I understand the question, we are searching for the boundary 
faces that form a halo layer around one given boundary face. From my point 
of view, the code I referenced should be a straight-forward solution 
avoiding unnecessary work.
However, this might not be the best option if the "subdomain" you want to 
build the halo layer around is much larger. In particular, 
GridTools::compute_active_cell_halo_layer avoids visiting a cell twice (but 
visits every cell once).
 

> Daniel, I think that this is more generic than your approach, because not 
> all FE's have DoFs that have support on a face?
>
Why do you think GridTools::compute_active_cell_halo_layer is more generic? 
Am I missing something?
In the end, both codes just return a set of cell_iterators resp. 
face_iterators. Since Erik explicitly asks for a way to "get the degrees of 
freedom living on the set of faces", I would still just modify the 
referenced code to return face_iterators and access the corresponding DoFs 
using them.
One caveat might be to deal with locally refined meshes. In this case, one 
would have to loop through all subfaces additionally.
 
Best,
Daniel

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Synchronization issue for parallel computation of material forces

[Jean-Paul Pelteret]

Dear Seyed,

Daniel’s been nice enough to furnish you with more information, but at this 
point one of your deleted comments is quite telling to me:

> Any ideas what could cause such a behavior? I am really not an expert yet to 
> dive deeply inside the deal.II parallel structure. 

As we explain in our introductory note for the forum 
, its really up to 
you to make some more effort to understand the parts of deal.II that you make 
use of. We do our best here to supplement the extensive documentation that’s 
already in place, but if you don’t have a basic understanding as to what steps 
need to be taken to approach a problem and why they’re necessary, then there’s 
not much more we can do. Sometimes a bigger hammer is not the best solution to 
solving a problem.

Good luck with solving your problem.

Best regards,
Jean-Paul

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: Synchronization issue for parallel computation of material forces

[Daniel Arndt]

Seyed,

your results look like the ghost values are wrong. My first guess would be 
that you are still using a completely distributed vector (one initialized 
with locally_owned_dofs only) instead
of a ghosted one (initialized with locally_owned_dofs and 
locally_relevant_dofs). Can you confirm that after solving you do something 
like

configurational_forces = local_configurational_forces;

and that 

configurational_forces.has_ghost_values() == true
local_configurational_forces.has_ghost_values() == false

holds? Can you confirm that you use configurational_forces and not 
local_configurational_forces for output?
What is the output of configurational_forces.print(std::cout)?

What kind of error do you get when trying with pcout instead of std::cout?

> Maybe this helps: 
>
> How do you compute "reaction forces" within deal.II? 
>
What exactly do you mean by that? We are much better if you can provide us 
with formulas rather than application-specific names.
>From my understanding, you mean a projection, isn't it? So solving for u 
such that (u,v)=(f,v) for all v and given f?
This is implemented in the VectorTools::project functions.[1]

Best,
Daniel

[1] 
https://www.dealii.org/developer/doxygen/deal.II/namespaceVectorTools.html

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: Synchronization issue for parallel computation of material forces

['Seyed Ali Mohseni' via deal.II User Group]

Maybe this helps: 

How do you compute "reaction forces" within deal.II? 

Did you ever compute reaction forces and write them as output within a 
parallel framework?

Best,
Seyed Ali

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Re: neighboring faces on the boundary

[Praveen C]

Also this page might be useful

https://www.dealii.org/8.4.1/doxygen/deal.II/structGeometryInfo.html

It shows how the faces within a cell are topologically related to one
another.

Best
praveen

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Re: How to shift a ConstraintMatrix that initialized with IndexSet?

[Daniel Arndt]

Ce Qin, 

This finally made its way into the developer version via PR #3722 
. The approach we finally came 
up with is to also shift the local indices when shifting the 
ConstraintMatrix objects.[1]
Merging two ConstraintMatrix objects also merges the local indices.[2]

Best,
Daniel

[1] 
https://www.dealii.org/developer/doxygen/deal.II/classConstraintMatrix.html#ad971fb29f0a15bf8d30704d2a5ab445e
[2] 
https://www.dealii.org/developer/doxygen/deal.II/classConstraintMatrix.html#aa471ba15f320b700280ab5e5ac59d88b

-- 
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.
For more options, visit https://groups.google.com/d/optout.