VectorTools::interpolate: Make common case of vector problem faster

[kronbichler]

In several applications, I have observed that VectorTools::interpolate is quite slow, most recently when looking at our timing-step_68 benchmark case. The reason is that we ask a DoFHandler's FESystem for the generalized support points and mix/match the local results inside

dealii/include/deal.II/numerics/vector_tools_interpolate.templates.h

Lines 396 to 397 in c76154b

	FETools::convert_generalized_support_point_values_to_dof_values(
	fe[fe_index], function_values, dof_values);

via

dealii/source/fe/fe_system.cc

Lines 2674 to 2693 in c76154b

	// populate base_point_values for a recursive call to
	// convert_generalized_support_point_values_to_dof_values
	for (unsigned int j = 0; j < base_point_values.size(); ++j)
	{
	base_point_values[j].reinit(n_base_components, false);
	const auto n =
	generalized_support_points_index_table[base][j];
	// we have to extract the correct slice out of the global
	// vector of values:
	const auto *const begin =
	std::begin(point_values[n]) + current_vector_component;
	const auto *const end = begin + n_base_components;
	std::copy(begin, end, std::begin(base_point_values[j]));
	}
	base_element
	.convert_generalized_support_point_values_to_dof_values(
	base_point_values, base_dof_values);

This is quite expensive and involves a lot of memory allocations. While we can't change the underlying interfaces easily, we can at least detect when the FiniteElement consists of a single base element that has support points, in which case we can just pick up the values directly without the indirections.

While there, also avoid some dynamic_cast to detect the case of FESystem recursively: We can use n_base_elements() for that query.

[tamiko]

This looks good!

Thanks a lot for the cleanup and small refactoring as well. This made the whole logic a lot easier to follow and understand.

[tamiko]

@kronbichler Will we see this in the performance graphs?

[kronbichler]

Will we see this in the performance graphs?

I expected it to have. But look at https://dealii.org/performance_tests/graphs//whistler-bullseye-gcc-10/a8379e2009bdfcb9e6fcb9fdb7dd074668217145-timing-step_68.average.png - timing-step_68/local_advect went from 1.37s to below 0.6s. More than I measured on my system. 😉