Use Utilities::fixed_power() in step-82.

[bangerth]

This addresses the last uses of std::pow with fixed integer exponent. Fixes #13321.

[marcfehling]

While there, could you also adjust these guys:

dealii/examples/step-82/step-82.cc

Lines 240 to 242 in b528e0d

	return_value = std::pow(p(0) * (1.0 - p(0)) * p(1) * (1.0 - p(1)) *
	p(2) * (1.0 - p(2)),
	2);

dealii/examples/step-82/step-82.cc

Lines 990 to 992 in b528e0d

	error_L2 += std::pow(u_exact.value(fe_values.quadrature_point(q)) -
	solution_values_cell[q],
	2) *

dealii/examples/step-82/step-82.cc

Lines 1073 to 1082 in b528e0d

	error_H2 += mesh3_inv *
	std::pow(solution_values_neigh[q] -
	solution_values[q],
	2) *
	dx;
	error_H1 += mesh_inv *
	std::pow(solution_values_neigh[q] -
	solution_values[q],
	2) *
	dx;

[marcfehling]

After this patch, there are now ~50 occurrences of Utilities::fixed_power in step-82. I must admit that reading the code in the previous state, in particular the ExactSolution, was easier for me because there were less line breaks.

What would you think of introducing some alias in step-82, i.e.,

const auto& pow2 = Utilities::fixed_power<2>;
const auto& pow3 = Utilities::fixed_power<3>;

[bangerth]

I addressed the remaining locations.

I am not a fan of aliases, not the least because then in the doxygen documentation generated from this program, you cannot just click on the name of the function and get to the documentation of it. I agree that the current state is not as easy to read. I don't know what to suggest otherwise, though -- I'd be ok with just dropping this patch and leaving it up to individual authors to optimize their code, and using the optimizations only in the library proper.

[marcfehling]

In terms of best practices, we should definitely use Utilities::fixed_power. I hoped there was a way to prevent line breaks to preserve readability. The manufactured solution is posted via MathJax in the introduction in a compact and readable form, so I don't feel strongly that we also need to provide it readable in the code.

[masterleinad]

I hoped there was a way to prevent line breaks to preserve readability.

You can always do

// clang-format off
/* ... */
// clang-format on

[bangerth]

Let's not do that in tutorials, though.