From 814cdd6b331ea7a2df28206069e6865b6ce6b6ea Mon Sep 17 00:00:00 2001 From: Marc Fehling Date: Tue, 10 Nov 2020 12:50:33 -0700 Subject: [PATCH] Deprecate DataPostprocessorInputs::CommonInputs::{get|set}_cell. --- .../incompatibilities/20201115Fehling-2 | 8 ++ include/deal.II/numerics/data_postprocessor.h | 91 +++++++++++++++---- source/numerics/data_out.cc | 8 +- 3 files changed, 83 insertions(+), 24 deletions(-) create mode 100644 doc/news/changes/incompatibilities/20201115Fehling-2 diff --git a/doc/news/changes/incompatibilities/20201115Fehling-2 b/doc/news/changes/incompatibilities/20201115Fehling-2 new file mode 100644 index 0000000000..2bb1867c56 --- /dev/null +++ b/doc/news/changes/incompatibilities/20201115Fehling-2 @@ -0,0 +1,8 @@ +Deprecated: The DoFHandlerType template argument for the functions +DataPostprocessorInputs::CommonInputs::set_cell() and +DataPostprocessorInputs::CommonInputs::get_cell() has been deprecated. +These functions now only work with the basic `DoFHandler` class. As a +consequence, the get_cell() function requires an additional dim +template. For example, write: cell=common_inputs.template get_cell() +
+(Marc Fehling, 2020/11/15) diff --git a/include/deal.II/numerics/data_postprocessor.h b/include/deal.II/numerics/data_postprocessor.h index 5ecbcdf466..b270b442c3 100644 --- a/include/deal.II/numerics/data_postprocessor.h +++ b/include/deal.II/numerics/data_postprocessor.h @@ -24,6 +24,8 @@ #include #include +#include + #include #include @@ -99,18 +101,16 @@ namespace DataPostprocessorInputs * To make this work, the DataOut and related classes store in objects * of the current type a representation of the cell. To get it back out, * you would use the get_cell() function that requires you to say, - * as a template parameter, the DoFHandler type to which the cell that - * is currently being processed belongs. This is knowledge you typically - * have in an application: for example, if your application runs in - * @p dim space dimensions and you are currently using the DataOut class, - * then the cells that are worked on have data type - * DataOut::cell_iterator. Consequently, in a - * postprocessor, you can call - * inputs.get_cell@ @> . For technical - * reasons, however, C++ will typically require you to write this as - * inputs.template get_cell@ @> - * because the member function we call here requires that we explicitly - * provide the template argument. + * as a template parameter, the dimension of the cell that is currently + * being processed. This is knowledge you typically have in an + * application: for example, if your application runs in @p dim space + * dimensions and you are currently using the DataOut class, then the cells + * that are worked on have data type DataOut::cell_iterator. + * Consequently, in a postprocessor, you can call inputs.get_cell@ + * . For technical reasons, however, C++ will typically require you to + * write this as inputs.template get_cell@ because the + * member function we call here requires that we explicitly provide the + * template argument. * * Let us consider a complete example of a postprocessor that computes * the fluid norm of the stress $\|\sigma\| = \|\eta \nabla u\|$ from the @@ -135,7 +135,7 @@ namespace DataPostprocessorInputs * std::vector > &computed_quantities) const override * { * const typename DoFHandler::cell_iterator current_cell = - * input_data.template get_cell >(); + * input_data.template get_cell(); * const viscosity = look_up_viscosity (current_cell->material_id()); * * for (unsigned int q=0; q + template void + set_cell(const typename DoFHandler::cell_iterator &cell); + + /** + * Set the cell that is currently being used in evaluating the data + * for which the DataPostprocessor object is being called. + * + * This function is not usually called from user space, but is instead + * called by DataOut and similar classes when creating the object that + * is then passed to DataPostprocessor. + * + * @deprecated Use the equivalent function with the dim template parameter + * instead. + */ + template + DEAL_II_DEPRECATED void set_cell(const typename DoFHandlerType::cell_iterator &cell); /** @@ -197,8 +212,20 @@ namespace DataPostprocessorInputs * See the documentation of the current class for an example on how * to use this function. */ + template + typename DoFHandler::cell_iterator + get_cell() const; + + /** + * Query the cell on which we currently produce graphical output. + * See the documentation of the current class for an example on how + * to use this function. + * + * @deprecated Use the equivalent function with the dim template parameter + * instead. + */ template - typename DoFHandlerType::cell_iterator + DEAL_II_DEPRECATED typename DoFHandlerType::cell_iterator get_cell() const; private: @@ -1174,12 +1201,24 @@ namespace DataPostprocessorInputs void CommonInputs::set_cell( const typename DoFHandlerType::cell_iterator &new_cell) + { + return set_cell(new_cell); + } + + + + template + template + void + CommonInputs::set_cell( + const typename DoFHandler::cell_iterator &new_cell) { // see if we had previously already stored a cell that has the same // data type; if so, reuse the memory location and avoid calling 'new' // inside boost::any - if (typename DoFHandlerType::cell_iterator *storage_location = - boost::any_cast(&cell)) + if (typename DoFHandler::cell_iterator *storage_location = + boost::any_cast::cell_iterator>( + &cell)) *storage_location = new_cell; else // if we had nothing stored before, or if we had stored a different @@ -1193,14 +1232,24 @@ namespace DataPostprocessorInputs template typename DoFHandlerType::cell_iterator CommonInputs::get_cell() const + { + return get_cell(); + } + + + + template + template + typename DoFHandler::cell_iterator + CommonInputs::get_cell() const { Assert(cell.empty() == false, ExcMessage( "You are trying to access the cell associated with a " "DataPostprocessorInputs::Scalar object for which no cell has " "been set.")); - Assert(boost::any_cast(&cell) != - nullptr, + Assert((boost::any_cast::cell_iterator>( + &cell) != nullptr), ExcMessage( "You are trying to access the cell associated with a " "DataPostprocessorInputs::Scalar with a DoFHandler type that is " @@ -1210,7 +1259,9 @@ namespace DataPostprocessorInputs "current function with a template argument equal to " "DoFHandler<2, 3>, but not with any other class type or dimension " "template argument.")); - return boost::any_cast(cell); + + return boost::any_cast::cell_iterator>( + cell); } } // namespace DataPostprocessorInputs diff --git a/source/numerics/data_out.cc b/source/numerics/data_out.cc index 2a28a0f04a..348b2a8351 100644 --- a/source/numerics/data_out.cc +++ b/source/numerics/data_out.cc @@ -232,8 +232,8 @@ DataOut::build_one_patch( cell_and_index->first->level(), cell_and_index->first->index(), dataset->dof_handler); - scratch_data.patch_values_scalar - .template set_cell(dh_cell); + scratch_data.patch_values_scalar.template set_cell( + dh_cell); // Finally call the postprocessor's function that // deals with scalar inputs. @@ -656,8 +656,8 @@ DataOut::build_one_patch( cell_and_index->first->level(), cell_and_index->first->index(), dataset->dof_handler); - scratch_data.patch_values_system - .template set_cell(dh_cell); + scratch_data.patch_values_system.template set_cell( + dh_cell); // Whether the solution was complex-scalar or // complex-vector-valued doesn't matter -- we took it apart -- 2.39.5