View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001433 | OpenFOAM | Bug | public | 2014-11-01 22:17 | 2015-01-18 22:06 |
| Reporter | wyldckat | Assigned To | henry | ||
| Priority | normal | Severity | major | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Summary | 0001433: Units in the incompressible implementation of the class "turbulentHeatFluxTemperatureFvPatchScalarField" aren't perfectly clear | ||||
| Description | In the file "src/turbulenceModels/incompressible/turbulenceModel/derivedFvPatchFields/turbulentHeatFluxTemperature/turbulentHeatFluxTemperatureFvPatchScalarField.C" is this piece of code: case hsFlux: { gradient() = q_/(Cp0*alphaEffp); break; } And in the header is this information: heatSource | heat source type: \c flux [W/m2] or \c power [W]| yes | q | heat source value | yes | [...] - it is assumed that the units of \c alphaEff are [kg/m/s] - the specific heat capcaity is read from the transport dictionary entry \c Cp0 (By the way, the typo "capcaity" isn't mine ;) ) Now, the symptoms are as follows: 1. "Cp0" read from the dictionary has no units, which is somewhat suspicious... 2. "alphaEff" is commented as being assumed to have the units [kg/m/s], which is a somewhat dangerous assumption, since in the incompressible model it derives from "alphat" which has the dimensions "[0 2 -1 0 0 0 0]". 3. When the heat source is meant to be flux, it's documented as having the units [W/m2]. If we compare with the compressible implementation of this same boundary condition, we're dealing with this equation: gradient() = (q_ + qr)/kappa(Tp) Which is approximately: gradient() = q_/(alphaEff*thermo.Cp) And where the units are: 1. "thermo.Cp" is in [J/kg/K] (according to "src/thermophysicalModels/basic/basicThermo/basicThermo.H"). 2. "alphaEff", i.e. "alphat" has the dimensions "[1 -1 -1 0 0 0 0]". 3. When the heat source is meant to be flux, it's also documented as having the units [W/m2]. Therefore, something is incorrectly documented in the incompressible implementation. One suggestion would be that the comment is updated to something like this: - reminder: the units of \c alphaEff are [m2/s2] - the specific heat capacity is read from the transport dictionary entry \c Cp0 and is actually Cp*rho, namely in [J/kg/K]*[kg/m3] = [J/m3/K] = [kg.m2/s2]/[m3/K] = [kg/m/s2/K] and that the "Cp0" value read from the dictionary is forced to be read with units, instead of a simple scalar :) For example: Cp0 Cp0 [1 -1 -2 -1 0 0 0] 1000.0; The other hypothesis is to think the other way around and state that the heat flux is actually the "kinematic heat flux", i.e. "q/rho"... which has some pretty crazy units :) | ||||
| Additional Information | I've only spotted this while diagnosing the detail mentioned here: http://www.cfd-online.com/Forums/openfoam-post-processing/101972-wallheatflux-utility-incompressible-case-2.html#post516635 | ||||
| Tags | No tags attached. | ||||
|
|
Greetings, So I'm guessing that this bug report of mine is suffering from the symptom "tl;dr". Therefore, here's the summarized 3 point report: 1. Files in question are the ones in this folder: "src/turbulenceModels/incompressible/turbulenceModel/derivedFvPatchFields/turbulentHeatFluxTemperature" 2. There is a typo in the header file ".H" where it's spelled "capcaity", which should be "capacity". 3. "Cp0" is not described in the comments within the header file, nor is respective dictionary entry require units, which can lead to serious errors in calculations. 3.a) The quick proposition is to update the respective comment to something like this (maybe not as complex): - the specific heat capacity is read from the transport dictionary entry \c Cp0 and is actually Cp*rho, namely in [J/kg/K]*[kg/m3] = [J/m3/K] = [kg.m2/s2]/[m3/K] = [kg/m/s2/K] 3.b) One perfectionist proposition is to enforce the correct units when reading from the dictionary, e.g.: Cp0 Cp0 [1 -1 -2 -1 0 0 0] 1000.0; For more specific details, please check the original report. If anything else is needed, like a proof/test case, please let me know. Best regards, Bruno |
|
|
Replaced Cp0 with rhoCp0 and added comment concerning units to clarify usage Resolved by commit 7e448b3295dd77b6d9c7cd0d745b0c02c318cf9d |
