View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001339 | OpenFOAM | Bug | public | 2014-07-09 02:59 | 2015-02-25 17:20 |
| Reporter | Assigned To | henry | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Platform | Red hat 6.4 | OS | Other | OS Version | (please specify) |
| Summary | 0001339: buoyantPimpleFoam with thermalBaffle1D: strange temperature decrease | ||||
| Description | I took the pimpleDyMFoam/propeller tutorial and added a 1D thermal baffle with Qs uniform 1000; I launched the analysis with buoyantSimpleFoam: it converges after 1189 iterations and the maximum temperature as expected increases from 273K to 339.4K. Then I took the 1189 time as starting point for buoyantPimpleFoam with the propeller stopped to see how much the temperature increases when there is only natural convection. But the temperature in less then 0.2s decrease from 339.4K to 328.4K. I wonder if this is linked to a bug? | ||||
| Steps To Reproduce | [I upload the files with the steps to reproduce already executed here https://www.dropbox.com/sh/gj602mpsiyvffhy/AADv6lR-VIjE8bKzHkVcSS9aa] - take the pimpleDyMFoam/propeller - add in front of the propeller a 1D thermal baffle like in the circuitBoardCooling tutorial - switch from AMI to MRF approach to be able to launch it with buoyantSimpleFoam - take the last time directory of the converged analysis and use it as starting point for the buoyantPimpleFoam analysis - comment in fvOptions the MRF subdictionary (propeller not rotating) - launch buoyantPimpleFoam for 0.2sec, temperature will decrease from 339.4K to 328.4K. | ||||
| Tags | No tags attached. | ||||
|
|
Greetings donQi, The file is no longer available in the dropbox link that you provided. As for the results you saw: 1. You're expecting something to happen without properly looking at the flow rate between the baffle and the fan. 2. In addition, since you used a sudden stop, the fluid flow will very likely almost "crash" against the propeller, leading to a "very confused" fluid flow around the propeller and the baffle. 3. My estimate is that if the propeller is no longer rotating, that means that the baffle will no longer have fluid forcefully flowing between the baffle and the propeller. Which means that the heat has to be exchanged more by conduction than convection, therefore the temperature drops, since a lot less heat is absorbed by the fluid. I think it's possible to set-up a case that is a lot simpler than relying on the propeller case. One could be created based on the circuit cooling tutorial, along with the fvOption "pressureGradientExplicitSource" to have the forced flow act for a defined period of time and then turning it off after a while, to diagnose what's going on. @Henry: Is it worth while to create such a simpler test case to ascertain if there is a bug or not, or can this issue be simply closed? Best regards, Bruno |
|
|
Certainly the complexity of the case would make debugging difficult. If the problem can be reproduced in a simpler case with better defined flow-field I could look into it. |
|
|
|
|
|
With some luck, I managed to reproduce the reported problem with a considerably simpler case, provided in the attachment "circuitBoardCoolingBuildUpForced.tar.gz". The case is simple: - single 1D baffle in the first 1/3rd of the mesh; - the mesh dimensions are similar to the propeller case, but most settings were inherited from the tutorial "heatTransfer/buoyantSimpleFoam/circuitBoardCooling"; - the flow speed is 1.0m/s at the inlet; - there is also a "pressureGradientExplicitSource" of 2 m/s for Ubar. Simply unpack and run "Allrun". It will run for 2500 iterations with "buoyantSimpleFoam", including a "pressureGradientExplicitSource"; it will then switch to running without the "fvOption" and will use "buoyantPimpleFoam" to run between 2500 to 2500.2. The maximum temperature will drop 2 degrees from 342 K to 340 K, namely Simple vs Pimple; but I think it's because I used the tutorial cases "heatTransfer/buoyantSimpleFoam/circuitBoardCooling" and "heatTransfer/buoyantPimpleFoam/hotRoom": - for Simple it uses "Gauss limitedLinear 0.2" for most divergence schemes; - for Pimple is uses "Gauss upwind" for the same schemes. When I tried using the same/similar schemes from the Simple case in the Pimple configuration (and deltaT & writeInterval 10x smaller than the attached case), the flow would develop a lot of flow vortices (with massive warm up within some of them, near the ends of the baffle), which eventually lead to a crash due to temperature falling out of the search range of the thermodynamic properties. But a few time snapshots before the crash, the temperature would indeed drop at least 10 degrees. |
|
|
Do you know which of the feature of the case need to be present in order to create the temperature drop? i.e. is it simply related to differences between the solvers or are either or both the baffle or the pressureGradientExplicitSource causing this behavior? |
|
|
Greetings Bruno, thank you for taking time to investigate about the issue and sorry for the dead link. Probably your circuit board attachment is easier for understanding the reason of the temperature decrease. Anyway if you still want to take a look at the propeller files are now re-uploaded here: https://www.dropbox.com/sh/u1sgx1t96skltci/AADJiDWVAqzDoLHUJdUX70tOa?dl=0 Best regards, donQi |
|
|
@Bruno: It is not clear what problem your case setup should demonstrate. The steady run uses a pressureGradientExplicitSource but the transient run does not so the results are different as expected. The schemes used are also different compounding the difference between the runs. What should I conclude from these results? What is the advantage of setting up the two cases so differently? |
|
|
@donQi: Many thanks for sharing the case again. I'll try to look into it as soon as I can. @Henry: I was aiming to recreate a similar case to what donQi had described. Now that the original case is available again, it should be fairly easier to adjust the simpler case to be more similar to the original report+case. As for the test case I provided: 1- Even when not using the "pressureGradientExplicitSource", the temperature distribution was roughly the same. Therefore, there was no clear increase in the convection term for heat exchange. 2- As for the "fvSchemes" configuration, I (or anyone else ;)) should be able to adjust the two file variants based on donQi's test case. But the steps I had taken are possibly a good approximation to how donQi's test case was set-up... at least under the principle of basing solely on a few reference tutorials that work. With any luck, I might be able to look into this at the end of the day. If not, only at the end of this week, i.e. during the weekend. |
|
|
I have setup the steady and transient runs equivalently and the results are practically identical; the peak temperature differs by 0.8K. I will investigate this difference in case it indicates a more serious error than the level suggests. |
|
|
The small difference in the results is a consequence of the fvc::ddtCorr term in the pressure equation of the transient solver. Under some circumstances this term is not needed but generally it is very beneficial for transient solvers, improving temporal accuracy and avoiding flux-pressure staggering modes. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
OK, took me a while to develop all of these, so I've uploaded them all. Each variation is built upon the previous one: - circuitBoardCoolingBuildUpForced_v2.tar.gz - Variant based on donQi's example cases. When switching from steady to transient, it will decrease the temperature within the first second, but it will then increase again and eventually stabilize at a higher temperature. The assessment here was that the problem was related to the "fvSchemes" not being similar enough. - circuitBoardCoolingBuildUpForced_v3.tar.gz - Sorry, this was an incorrect upload. I had accidentally modified the "fvSolution" file, after running the case. - circuitBoardCoolingBuildUpForced_v3b.tar.gz - Configured the "fvSchemes" on the steady-state case to be more similar to the ones on the transient case. In this case, the temperature increased within the first second. After a few seconds, the maximum temperature would stabilize. - circuitBoardCoolingBuildUpForced_v4.tar.gz - Turned off the fvOption, so that it would be less one variable situation. The same occurred, where the temperature would still increase when switching to transient, although it would stabilize after a few seconds of simulation time. Noticed that the enthalpy equation wasn't stable enough, since the residuals didn't seem stable enough. The reason was because the relaxation parameters were set to 0.2. - circuitBoardCoolingBuildUpForced_v5.tar.gz - Switched back to the stronger relaxation parameters from the original tutorial "circuitBoardCooling". Runs for 2500 iterations, without automatic stopping based on residuals. The result: - The temperature still increases between 2000 and 2500 iterations in steady state, even though the residuals seem fairly low enough (initial residuals between 1e-5 to 1e-6) and give the feeling of being converged. Maximum temperature: roughly 337K. - When switching to transient, after some 4-6 seconds of simulation time, the maximum reached the maximum of 340K and seemed to stabilize within a 1e-3 K precision. My interpretation of this is that the fvc::ddtCorr might actually be leading the solution to a more realistic result, because the steady-state run was not able to reach a similar result within an "acceptable" number of iterations. I didn't let it run for 5000 or more iterations in steady-state... because it's late already :) -------------------- @donQi: I've analysed your transient case and there are few critical flaws that can easily result in what you saw and shared: 1- Even before the first iteration of the transient simulation is processed, the solver gives us this: Courant Number mean: 225.049 max: 51237.1 This is really bad. I'm even impressed that the solver didn't crash and still managed to continue running! 2- For the transient simulation, the "maxCo" is set to 2. This might work for the tutorial case "incompressible/pimpleDyMFoam/propeller", but that doesn't mean that this is a safe maximum value for any simulation case. The usual safe value is the maximum of 0.5 and even that in some situations might be too high. --------------------- Conclusion: It might be worth checking if in the v5 example case there is a way to make the steady state solver to properly converge, in order to double check if there is something that might or might not need fixing in that steady state solver. But for today, there isn't much more I can test. |
|
|
It is not clear from these results that the simulations with ddtCorr are more accurate although they might be. The differerences in the results is likely to be well within the numerical errors for the simulations but this could be demonstrated by successive refinement to mesh independence. ddtCorr simply changes part of the time-derivative to be based on phi rather than U which is beneficial for transient running to avoid certain comutational modes which occur in time-resolved simulations but not steady-state ones. If it can be demonstrated that ddtCorr actually provides more accurate results rather than just different ones it may be possible to formulate an equivalent term for the steady-state solvers. |
|
|
I ran the case with a mesh 2x finer in each direction and the peak temperature increases from 342K to 352K demonstrating that the numerical error on the coarse mesh is much larger than the difference in the solution generated by ddtCorr as expected. Also the peak temperature on the finer mesh is the same for both the steady and transient runs. These runs also indicates that the transient solution is very slightly more accurate than the steady solution on the coarse mesh. If this can be demonstrated on a range of cases it might be worth considering adding ddtCorr to the steady solvers. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2014-07-09 02:59 |
|
New Issue | |
| 2015-02-21 20:45 | wyldckat | Note Added: 0003850 | |
| 2015-02-21 21:17 | henry | Note Added: 0003853 | |
| 2015-02-22 22:29 | wyldckat | File Added: circuitBoardCoolingBuildUpForced.tar.gz | |
| 2015-02-22 22:43 | wyldckat | Note Added: 0003854 | |
| 2015-02-22 22:54 | henry | Note Added: 0003855 | |
| 2015-02-23 03:29 |
|
Note Added: 0003856 | |
| 2015-02-23 10:28 | henry | Note Added: 0003857 | |
| 2015-02-23 10:37 | wyldckat | Note Added: 0003858 | |
| 2015-02-23 10:43 | henry | Note Added: 0003859 | |
| 2015-02-23 15:03 | henry | Note Added: 0003868 | |
| 2015-02-23 22:47 | wyldckat | File Added: circuitBoardCoolingBuildUpForced_v2.tar.gz | |
| 2015-02-23 22:48 | wyldckat | File Added: circuitBoardCoolingBuildUpForced_v3.tar.gz | |
| 2015-02-23 22:48 | wyldckat | File Added: circuitBoardCoolingBuildUpForced_v4.tar.gz | |
| 2015-02-23 22:48 | wyldckat | File Added: circuitBoardCoolingBuildUpForced_v5.tar.gz | |
| 2015-02-23 22:53 | wyldckat | File Added: circuitBoardCoolingBuildUpForced_v3b.tar.gz | |
| 2015-02-23 23:17 | wyldckat | Note Added: 0003876 | |
| 2015-02-25 11:17 | henry | Note Added: 0003903 | |
| 2015-02-25 17:19 | henry | Note Added: 0003910 | |
| 2015-02-25 17:20 | henry | Status | new => closed |
| 2015-02-25 17:20 | henry | Assigned To | => henry |
| 2015-02-25 17:20 | henry | Resolution | open => no change required |
