Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

User reported issue: heat capacity values #404

Open
oliver-phet opened this issue Dec 11, 2020 · 8 comments
Open

User reported issue: heat capacity values #404

oliver-phet opened this issue Dec 11, 2020 · 8 comments

Comments

@oliver-phet
Copy link

Forwarded from Carl:

My name is Barry Lucas and I am currently an engineering, science and robotics specialist at the Clayton-Bradley STEM Academy in Maryville, TN. My 8th grade science class recently conducted a virtual lab using the energy forms and changes simulation (link below). Each team was tasked with designing an experiment that allowed them to rank order the four materials in order of heat capacity. Pretty much every team found discrepancies in their observations as compared to literature values. Even after working with them to minimize potential measurement errors, the discrepancies still persist. The assumption that we are making is that if we measure the time to raise the temperature at full heat then the time divided by the number of tics should be a representative measure of heat capacity and that a ratio of the literature value to this measured ratio should be a constant, essentially a calibration factor. I am sure that there are assumptions in the simulation about the heat capacity but am curious if there are other factors in the simulation that we are unaware of that might contribute to this error.

@arouinfar
Copy link
Contributor

arouinfar commented Dec 12, 2020

The assumption that we are making is that if we measure the time to raise the temperature at full heat then the time divided by the number of tics should be a representative measure of heat capacity and that a ratio of the literature value to this measured ratio should be a constant, essentially a calibration factor.

This method makes the assumption that the blocks have the same mass, which is incorrect. Brick and iron have the same volume, but the iron block is several times heavier than the brick. If they adjust for the differences in mass (by using the densities), this method will work. I tested it using the values currently in the model, and everything checks out.

However, I think that the brick density used in the model is too high (currently 3300 kg/m³). The comment in the code says it comes from the design doc, but those values are not actually sourced. I'm willing to bet they are the values we used in Java. According to Wikipedia:

The density of solid clay bricks is around 2000 kg/m³

I've found other sources which put the density of brick in the 1400-2400 kg/m³ range, so 2000 kg/m³ sounds like a more reasonable value.

It seems like we should change the brick density in the model, but I am a bit hesitant since the code currently says the value was tweaked to "keep chunk numbers reasonable". @kathy-phet what are your recommended next steps?

@chrisklus
Copy link
Contributor

@arouinfar looked into this a little bit and ran into an assertion for expected preset values when we changed the brick density to a more accurate number mentioned in #404 (comment). I'll have to investigate more or talk to @jbphet about how these preset values work - I know they were added to speed up start time / reset time.

Leaving assigned to @kathy-phet for recommendations on if any changes here should be implemented for the next release.

@arouinfar
Copy link
Contributor

Another user wrote to phethelp about the heat capacity of the bricks. The values they cite match the specific heat in the model, but because we have an unrealistic brick density, the user does not observe the behavior they would expect.

The brick and the iron have different densities and specific heats. No matter how I try to look at the blocks I can’t get the numbers to fit.
If the blocs are the same mass, the Iron should heat much faster than the brick. According to my tables iron has a specific heat of 449 J/(kgK) and solid brick around 840 J/(kgK).
If the blocks are the same size, the heat capacity of the iron should be about twice as high as for the brick, but the temperature changes is not half as much. (densities of 7,9 kg/L and 1,8 kg/L). Maybe bricks are different in the US?

@jbphet jbphet self-assigned this Jun 9, 2021
@jbphet
Copy link
Contributor

jbphet commented Jun 9, 2021

Self-assigned to get this on my radar.

@jbphet
Copy link
Contributor

jbphet commented Sep 27, 2021

Here is what is in the code as of this writing:

 BRICK_DENSITY = 3300; // in kg/m^3, source = design document plus some tweaking to keep chunk numbers reasonable
 BRICK_SPECIFIC_HEAT = 840; // in J/kg-K, source = design document

 IRON_DENSITY: 7800, // In kg/m^3, source = design doc
 IRON_SPECIFIC_HEAT: 450, // In J/kg-K, source = design doc

Here is part of a table I just found online for densities and specific heats of building materials (URL = https://www.greenspec.co.uk/building-design/thermal-mass/):

image

So, assuming steel is close to iron, we seem to be using pretty realistic values for iron and a bit of an unrealistic density for the brick (though the specific heat is reasonably close).

The comment on the brick density says, "design document plus some tweaking to keep chunk numbers reasonable", so I think we probably did some "hollywooding" here to get the behavior we wanted. This could, of course, be changed to be more realistic, but there would be consequences. We could also consider a different material that is closer to what we're after.

@arouinfar - I'm hitting this back into your court. I'd be happy to meet with you during design meeting time to discuss options and tweak the values and see how it affects the behavior.

@jbphet jbphet assigned arouinfar and unassigned jbphet and kathy-phet Sep 27, 2021
@arouinfar
Copy link
Contributor

Republishing this sim will eventually be a priority, let's discuss then. For now, I'm going to unassing myself.

@arouinfar arouinfar removed their assignment Jun 23, 2023
@oliver-phet
Copy link
Author

Related user email into phethelp:

Hello! I am a student in the Physics Teaching Program at the National University of Misiones and I am close to completing my studies. I would like to reach out to you because I am not entirely convinced by the simulation found at the following link, translated as "Energy Forms and Changes":

https://phet.colorado.edu/en/simulations/energy-forms-and-changes

To discuss thermal energy transfers, you show an iron block and a brick block and use a burner. The heat absorbed by both the brick block and the iron block is hypothetically the same, as it comes from the same burner. The volumes of both are the same, as you recommend to teachers.

When performing the experiment with the simulator, it can be seen that the brick absorbs heat more quickly than the iron block and increases its temperature faster. It is understood that the mass of the iron block is greater than that of the brick, and if we analyze the heat equations, approximating that the equilibrium temperature will be the peak of the thermometer, we see that the brick block reaches a higher temperature in less time than the iron. You justify this by saying the following, translated:

"The brick and iron blocks have the same volume, but not the same mass, so the brick heats up to 20% faster, despite its larger specific heat."

Unless the mass of the iron is considerably greater than that of the brick, we, along with the faculty team, do not see the point in what happens in the simulation. In the case that a student with a construction-oriented background might see it, despite the fact that iron is denser than brick, it still does not justify why the simulator shows what it shows.

@jbphet
Copy link
Contributor

jbphet commented Jul 8, 2024

Assigning to @arouinfar to respond to the query above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants