-
Notifications
You must be signed in to change notification settings - Fork 396
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
Relax Conduction Transfer Function time step limit #10614
Conversation
The eio file shows the CTF values before and after this fix have not changed. So that would mean this construction did converge but at 5 hours instead of 4 and fatal'd out. Chicago Ohare Intl Ap,IL,USA,TMY3,725300 develop:
this branch:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rraustad I get that this allows the defect input file to run to completion. As the comments say here, the use of 4 hours was arbitrary so I don't have an argument against bumping this up to 7 hours. The material used in this case is basically one foot of high R-value concrete. The combination of low conductivity with relatively high specific heat, density, and thickness result in the long time step. My concern is: what do the results say? Do they actually make sense? Will the user know how to tell? It seems like a good idea to run a modified version of 1ZoneUncontrolled with this construction to see if the design day results make sense (might have to bump up the number of warmup days) and if the annual results seem reasonable. In the design day, if it can't get to steady periodic (or at least headed there), that's a potential concern. In the annual result, if the temperatures seemed to wander all over the place, that's a sign that the CTFs might not be correct. I guess the reality is that we don't have a way to test this outside of someone doing something like this and I am guessing that the documentation does not tell the user what to look for? So, I'm not opposed to this change, but I wonder if the result will be bogus simulation results. Just a suspicion on my part.
Well, I thought I was making an "in-line" comment, but I guess I don't know what I am doing. The reference in the previous post to "the comments" was pointing to the comments that describe the constant parameter that got adjusted here. In any case, I'm not really asking for a change to the fix. Maybe what is needed is some additional documentation? The IO Ref is not set-up for discussing something like this, and the Eng Ref is heavy on the details of how the calculation is made. There's nothing really "practical" about what to look for when the time step gets longer. Given what is there now, I'm not even sure where it would go--a new sub-section or note in the "Conduction Through the Wall" part of Eng Ref? _CTFTestsPart2.idf is a file that I used early on in development to test what was going on. Those tests were by no means exhaustive and the material chosen by the user is clearly more challenging the "slowhwconc" material that was tested in _CTFTestsPart1.idf. Or maybe just an additional "warning" message when the time step gets above "something" that they need to look at the results careful and what to try to see what is going on? I mean, the material properties chosen here are unusual. But the warning message might end up being kind of long as it tries to describe a lot so maybe that isn't the right approach. I think my concern is that the user will think "completed successfully" will mean that the results are good. That was actually not guaranteed before either, so this is really not a new concern. @Myoldmopar @mjwitte Any thoughts on this? |
All good suggestions. I like the idea of comparing this material using an original example file to see what happens. |
Discussed this on the iteration call today and agreed to merge. |
Pull request overview
NOTE: ENHANCEMENTS MUST FOLLOW A SUBMISSION PROCESS INCLUDING A FEATURE PROPOSAL AND DESIGN DOCUMENT PRIOR TO SUBMITTING CODE
Pull Request Author
Add to this list or remove from it as applicable. This is a simple templated set of guidelines.
Reviewer
This will not be exhaustively relevant to every PR.