FS#172 Restructure the way heat conduction is implemented in the 2p(2c)ni boxmodel
Metadata
Property |
Value |
Project |
dumux |
Category |
2p2cni |
Reported by |
Anonymous (Id=0) |
Reported at |
Nov 27, 2012 16:13 |
Type |
Feature Request |
Version |
Git |
Last edited by |
Anonymous (Id=9) |
Last edited at |
Jan 24, 2013 12:29 |
Closed by |
Anonymous (Id=9) |
Closed at |
Jan 24, 2013 12:29 |
Closed in version |
unknown (Id=0) |
Resolution |
Fixed |
Description
Heat conduction is implemented in a quite simple way providing not much flexibility. So far, the matrixHeatFlux (and boundaryMatrixHeatFlux) method in the spatial parameters computes the entire conductive heat flux with a given temperature gradient.
I suggest to split this to
1) effectiveHeatConductivity(...), which provides a model for the computation of an effective heat conductivity in one SCV,
2) thermalConductivitySolid(...) returning only the thermal conductivity of the solid material, which is called by the effectiveHeatConductivity method and which allows to specify the solid heat conductivity according to the position (like e.g. porosity).
Furthermore, I would add a calculateEffectiveThermalConductivity() method in the 2p(2c)nifluxvariables, which averages the effective heat conductivities at node i and j harmonically. I am not sure, if 2) should be in the fluxvariables or in the spatial parameters. The porous diffusion coefficient is calculated completely in the fluxvariables. However, this is just one method to calculate that and may be exchanged. Thus, I tend to put it into the spatial parameters.
The (boundary-)MatrixHeatFlux() method would be needless with the changes above and could be removed. However, it has to be checked how it is possible to deprecate the existing methods and to sustain backwards-compatibility. If someone has modified the matrixHeatFlux method in his/her spatialparams, this method would not be called anymore...