From c49c8a9b46283dff86dc6751f449ff674d9b0af8 Mon Sep 17 00:00:00 2001 From: Wolfgang Bangerth Date: Fri, 15 Nov 2024 15:56:27 -0700 Subject: [PATCH 1/3] Document the heat flux plugin system. --- .../plugin-types/boundary-heat-flux.md | 34 +++++++++++++++++++ .../user/extending/plugin-types/index.md | 1 + 2 files changed, 35 insertions(+) create mode 100644 doc/sphinx/user/extending/plugin-types/boundary-heat-flux.md diff --git a/doc/sphinx/user/extending/plugin-types/boundary-heat-flux.md b/doc/sphinx/user/extending/plugin-types/boundary-heat-flux.md new file mode 100644 index 00000000000..d11dfebf712 --- /dev/null +++ b/doc/sphinx/user/extending/plugin-types/boundary-heat-flux.md @@ -0,0 +1,34 @@ + +# Boundary heat flux + +In contrast to prescribing the actual temperature at a boundary, it is +also possible to prescribe the *heat flux* across a boundary. A number +of heat flux models are already implemented, but if you want to +implement a new boundary heat flux model, you need to overload the +`aspect::BoundaryHeatFlux::Interface` class and use the +`ASPECT_REGISTER_BOUNDARY_HEAT_FLUX_MODEL` macro to register your new class. +The implementation of the new class should be in namespace +`aspect::BoundaryTemperature`. + +The `Interface` class that you need to overload provides the +prescribed heat flux at a given set of points via the `heat_flux()` +function. The function receives information about material parameters +at these points as well. For historical reasons, the function is asked +to provide the heat flux as a vector, even though the place where the +heat flux is used only uses the component of this vector that is +*normal* to the boundary (which it computes by taking the dot product +between the returned vector and the normal vector). Because there are +situations where all you can do is compute the normal heat flux as a +scalar, the `heat_flux()` function also receives the normal vector as +an input argument. As a consequence, one way for the function to +compute the required heat flux vector is to compute the scalar heat +flux and multiply it by the normal vector. + +Finally, the function also receives the boundary indicator of the particular +piece of boundary on which the point is located, as a hint in +determining where this point may be located; this may, for example, be used to +determine if a point is on the inner or outer boundary of a spherical shell. +Models may also need to query the geometry model (via the `SimulatorAccess` class) +to understand what a specific boundary indicator is supposed to mean – e.g., +if the given boundary indicator corresponds to an inner or outer surface of a shell +geometry. diff --git a/doc/sphinx/user/extending/plugin-types/index.md b/doc/sphinx/user/extending/plugin-types/index.md index 90311297a3a..700693fb525 100644 --- a/doc/sphinx/user/extending/plugin-types/index.md +++ b/doc/sphinx/user/extending/plugin-types/index.md @@ -9,6 +9,7 @@ gravity-models.md initial-conditions.md velocity-bc.md temp-bc.md +boundary-heat-flux.md postprocessors.md vis-postprocessors.md mesh-refinement.md From e3cee6596ffcc9da65cf3774d3755a8c2f3f7e59 Mon Sep 17 00:00:00 2001 From: Wolfgang Bangerth Date: Fri, 15 Nov 2024 15:57:58 -0700 Subject: [PATCH 2/3] Minor code clean-up. --- source/simulator/assemblers/advection.cc | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/source/simulator/assemblers/advection.cc b/source/simulator/assemblers/advection.cc index 08c21d1e90f..e4b8169beb6 100644 --- a/source/simulator/assemblers/advection.cc +++ b/source/simulator/assemblers/advection.cc @@ -461,13 +461,12 @@ namespace aspect // We are in the case of a Neumann temperature boundary. // Impose the Neumann value weakly using a RHS term. - std::vector> heat_flux(n_face_q_points); - heat_flux = this->get_boundary_heat_flux().heat_flux( - face->boundary_id(), - scratch.face_material_model_inputs, - scratch.face_material_model_outputs, - scratch.face_finite_element_values->get_normal_vectors() - ); + const std::vector> heat_flux + = this->get_boundary_heat_flux().heat_flux( + face->boundary_id(), + scratch.face_material_model_inputs, + scratch.face_material_model_outputs, + scratch.face_finite_element_values->get_normal_vectors()); for (unsigned int q=0; q Date: Fri, 15 Nov 2024 15:59:36 -0700 Subject: [PATCH 3/3] Better document the return type of a function. --- include/aspect/boundary_heat_flux/interface.h | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/include/aspect/boundary_heat_flux/interface.h b/include/aspect/boundary_heat_flux/interface.h index ab7a41f9a7b..ff85148d22b 100644 --- a/include/aspect/boundary_heat_flux/interface.h +++ b/include/aspect/boundary_heat_flux/interface.h @@ -59,7 +59,18 @@ namespace aspect * @param material_model_inputs The material property inputs. * @param material_model_outputs The material property outputs. * @param normal_vectors The normal vector at each quadrature point. + * * @return A vector of heat flux vectors at the evaluation points. + * For historical reasons, the function is asked + * to provide the heat flux as a vector, even though the place where the + * heat flux is used only uses the component of this vector that is + * to the boundary (which it computes by taking the dot product *normal* + * between the returned vector and the normal vector). Because there are + * situations where all you can do is compute the normal heat flux as a + * scalar, the `heat_flux()` function also receives the normal vector as + * an input argument. As a consequence, one way for the function to + * compute the required heat flux vector is to compute the scalar heat + * flux and multiply it by the normal vector. */ virtual std::vector>