Re: [deal.II] extract_dofs() extremely slow in for single-thread run?

Using the merged commit my runtime decreased now from 120 sec. per call to ~1-2 sec. per call, thanks for the fast help! develo...@googlemail.com schrieb am Donnerstag, 3. September 2020 um 14:13:37 UTC+2: > I'm following the discussion, and will retest my program as soon as the > commit has

Re: [deal.II] extract_dofs() extremely slow in for single-thread run?

I'm following the discussion, and will retest my program as soon as the commit has been approved and merged. Thanks! Martin Kronbichler schrieb am Donnerstag, 3. September 2020 um 13:55:40 UTC+2: > Indeed the other function was fast. I looked into the function already > and have a fix posted:

Re: [deal.II] extract_dofs() extremely slow in for single-thread run?

Indeed the other function was fast. I looked into the function already and have a fix posted: https://github.com/dealii/dealii/pull/10883 Best, Martin -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see

Re: [deal.II] extract_dofs() extremely slow in for single-thread run?

On 9/3/20 1:16 AM, 'Maxi Miller' via deal.II User Group wrote: Again, extract_dofs takes most of the time here. Is there an alternative approach for that, too? There is a variation of extract_dofs() that returns its results in the form of a std::vector (as one of the arguments) instead of

Re: [deal.II] extract_dofs() extremely slow in for single-thread run?

Another issue I have is for the following code piece, where I basically have to rescale every part of the solution by a different factor (due to using unitless variables in the calculation): const ComponentMask surface_A_mask = fe.component_mask(surface_A); const ComponentMask surface_B_mask =

Re: [deal.II] extract_dofs() extremely slow in for single-thread run?

Yes, that worked, thanks! Now, when comparing, it takes 132 seconds for my initial version, and 0.41 seconds for the version you proposed. Why is my approach so much more expensive? Thanks! Jean-Paul Pelteret schrieb am Mittwoch, 2. September 2020 um 20:34:56 UTC+2: > I was close — it’s >

Re: [deal.II] extract_dofs() extremely slow in for single-thread run?

I was close — it’s fe.get_unit_support_points() // https://www.dealii.org/developer/doxygen/deal.II/classFiniteElement.html#a5b35a290aa7dd7562911a92a13b11fee > Moreover, defining

Re: [deal.II] extract_dofs() extremely slow in for single-thread run?

I'm using FESystem for defining fe, and therefore I get "unit_support_points is protected within this context". Is there another way to get access to those points? Moreover, defining fe_values as const disables the reinit()-call, and I have to call cell->is_locally_owned(), instead of

Re: [deal.II] extract_dofs() extremely slow in for single-thread run?

Hi, 30-40% of the runtime for this operation seems a bit excessive to me. Maybe you should try using the FEValuesExtractors in conjunction with FEValues in order to get the solution at the quadrature points. If you want the solution at the support points, then you can just create a quadrature

[deal.II] extract_dofs() extremely slow in for single-thread run?

I'd like to simulate four coupled PDEs (with variables A, B, C and D) using deal.II. At each step in time I'm interested in the maximum and minimum value of each variable. Therefore, I have to loop over my solution, and gather the maximum and minimum value of each variable by using vector_t