Re: [deal.II] Re: Tips on writing "versatile" assembly function

That's interesting. Seems like it was more about inlining than branch prediction. Surprising how much difference it made. On Tuesday, January 5, 2021 at 6:18:38 PM UTC-5 Timo Heister wrote: > What I forgot to say: > We used to have something like > > if (use_anisotropic_viscosity==true) > cell(i

Re: [deal.II] Re: Tips on writing "versatile" assembly function

Hello Prof. Blais, Optimizing code is always fun, so I've had this discussion multiple times with a colleague. Dr. Turcksin comment was also our conclusion. Templating seems to be the way to go, but only on options/variations where mispredicted branches actually slow down your performance since

Re: [deal.II] Re: Finding vertices on boundaries

wrote: > On 10/21/20 1:05 PM, Doug Shi-Dong wrote: > > > > It seems like I might have to loop over the neighbors of every cell to > make > > sure that account for all the corners/edges DoFs that might be on a > boundary, > > but that seems inefficient. > &

Re: [deal.II] Re: Finding vertices on boundaries

Hello everyone, Sorry to revive this thread, but I have a similar question that follows up his question. In the case of a distributed grid, there might be vertices/DoFs on a corner (or even edges in 3D) of a cell. For example, see attached figure (at the trailing edge of the airfoil in the sq

Re: [deal.II] Nested reverse and forward-mode Sacado memory leak

Thanks for the answer! I am currently using the master branch of Trilinos, to make sure that a newer version did not fix this. I had some second-guessing with how I had configured Sacado itself since there seems to be some options that changes how the reverse mode reuses the memory through RAD

[deal.II] Nested reverse and forward-mode Sacado memory leak

Hello everyone, I found that Sacado's nested reverse and forward mode AD leads to a memory leak when use multiple times. I have opened an issue on their end: https://github.com/trilinos/Trilinos/issues/7741 and the steps to reproduce are pretty simple. However, I've found that the community here

Re: [deal.II] How to transform points on faces from unit cells to real cells?

Yes I can confirm, I am using QProjector with a dummy face Quadrature right now it works as intended. Doug -- 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 a

Re: [deal.II] How to transform points on faces from unit cells to real cells?

()” requires Point as input. >> >> The dimensions of points in cells is different from that on faces. That’s >> one of the reasons why I posted this question. >> >> >> If I misunderstand you, please kindly let me know. >> >> >> >> Rega

[deal.II] Re: How to transform points on faces from unit cells to real cells?

me using the member function > "transform_unit_to_real_cell()" to get all support points in a unit cell? > In the step, sort out the face points I need? Am I correct? > > > Regards, > > Lex > > On Sunday, June 21, 2020 at 5:00:35 PM UTC-7, Doug Shi-Dong wrote: >> >> He

[deal.II] Re: How to transform points on faces from unit cells to real cells?

Hello Lex, You were close. https://www.dealii.org/current/doxygen/deal.II/classMapping.html#ae5df63553eb8ed170c3b90524853dd48 The project_real_point_to_unit_point_on_face() is useful is you take a "volume" point within the cell. Since you are mapping from unit to real, you would always know wh

[deal.II] Re: Strategy to snap the boundary of a triangulation to a manifold

Prof. Blais, Bonjour fellow Montreal-er (McGill), land of the bagel and poutine. I have also given some thoughts to robustly generate our meshes with GMSH. I think it's great to see that we've concluded to similar steps as you described: 1. Provide GMSH some CAD/NURBS parametrization from w

[deal.II] Re: LinearOperator MPI Parallel Vector

More so, I just found that the AffineConstraints function have not been instantiated for a mix of TrilinosWrappers::SparseMatrix and LA::dist::Vector, hence it likely has not been tried out/tested. Seems like it's just not a thing to use LA::dist::Vector other than for matrix-free? -- The dea

[deal.II] LinearOperator MPI Parallel Vector

Hello, I have been using the LinearAlgebra::distributed::Vector class for MPI parallelization since the way it works is more familiar to what I had worked with and seemed more flexible. However, for parallelization, I have to either use a Trilinos or PETSc matrix since the native deal.II Spars

Re: [deal.II] Constrained linear operator on distributed data structures

te: > > Hi Doug, > > If I recall correctly, we added that comment since this is a part of > the library that is not very well tested. The code is probably fine. > > Thanks, > David > > On Tue, Dec 24, 2019 at 2:33 PM Doug Shi-Dong > wrote: > > > >

[deal.II] Re: Converting LinearAlgebra::distributed::Vector to TrilinosWrappers::MPI::Vector

resulting Trilinos vector was empty and would of course not have the same parallel distribution as the matrix it was supposed to be multiplied with. Doug On Wednesday, December 4, 2019 at 6:25:49 PM UTC-5, Doug Shi-Dong wrote: > > Hello, > > I am trying to solve a block syst

[deal.II] Constrained linear operator on distributed data structures

Hello everyone, I see that some functions within the constrained_linear_operator.h have a note saying Currently, this function may not work correctly for distributed data structures. I am currently using it in parallel and seems to be working fine for a very simple linear elasticity problem w

[deal.II] Converting LinearAlgebra::distributed::Vector to TrilinosWrappers::MPI::Vector

Hello, I am trying to solve a block system using the LinearOperators and Trilinos matrices and vectors. Currently, all my matrices uses TrilinosWrappers::SparseMatrix, but my vectors use the deal.II LinearAlgebra::distributed::Vector because of how easily it handles ghosted vectors. When time

Re: [deal.II] Instantiation of vector_tools_integrate_difference

Not sure why it builds fine locally, but that fixed it! Thank you! Doug On Wednesday, November 6, 2019 at 11:06:47 AM UTC-5, Wolfgang Bangerth wrote: > > On 11/6/19 8:49 AM, Doug Shi-Dong wrote: > > > > Any hints about what could be causing this? > > I thought we

[deal.II] Re: Docker MPI

hat mpich is installed. > > Best, > > Bruno > > On Monday, October 21, 2019 at 9:53:36 PM UTC-4, Doug Shi-Dong wrote: >> >> Hello everyone, >> >> I would like to use Travis CI to test pull requests, and I am currently >> following the steps descr

[deal.II] Docker MPI

Hello everyone, I would like to use Travis CI to test pull requests, and I am currently following the steps described in https://github.com/dealii/dealii/wiki/Docker-Images Except I am using the following Docker image: dealii/dealii:v9.1.1-gcc-mpi-fulldepsspack-debugrelease It seems that this

[deal.II] Re: Query regarding DoFTools::dof_indices_with_subdomain_association()

Hello Vachan, Sounds like you're implementing nodal DG, hence why you only need values and gradients at the *quadrature* points from the neighbor. Something you might want to consider rather than communicating them at solution points, in case you ever decide to overintegrate. You could still a

[deal.II] Re: Integrate the solution over a subdomain

On Tuesday, October 8, 2019 at 8:43:23 AM UTC-4, Yang Liu wrote: > > > Dear DEAL.II users, > > The DEAL.II software provides the function > VectorTools::compute_mean_value() to integrate the solution over the whole > domain. > > But now I would like to integrate the solution over a subdomain.

[deal.II] Re: High order mesh from Gmsh

Hello everyone, Sorry to revive/hijack this thread, but it seems to have the exact information/people that might be able to help. My current goal is to perform some shape optimization with some h(p)-refinement. I am currently using Prof. Heltai's method described in this issue

Re: [deal.II] Instantiation MappingFEField with hp::DoFHandler

On Wednesday, September 18, 2019 at 11:28:45 PM UTC-4, Wolfgang Bangerth wrote: > > > Doug, > > It does not greatly surprise me that it doesn't compile -- what isn't > tested > generally doesn't work. > Makes sense. We'd of course be very happy to accept any patches to make things work. T