Tags and keywords
TemperatureIncreasewith a supporting ConstraintBlock
Remember this loophole?
Let's see whether we can make the numbers fit anyway:
The startup value 4180.0 for
specificHeat works quite well across the expected temperature ranges if it is in J/(K⋅L), noting the following data are in J/(K⋅cm^3):
So 4180.0 J/(K⋅L) seems reasonable.
But note also that to get the dimensional analysis to work the "waterVolume" has to be a rate:
This is based in part on the observation that the consumer
HeatingCalculation does NOT treat the temperature increase as a rate, together with:
Assume you've got all of the power 400 J/s from the heater (ignore any radiative loss) and plugin these values:
specificHeat -> 4.180 J/(K cm^3) waterVolume -> 0.1 L/s energy -> 400 J/s L -> cm^3*1000
This gives a temperature increase of 0.956938 K. We'll see also later when we run the simulation that the assumption of
waterVolume = 0.1 L/s corresponds well enough with the equivalent vapor output rate.