View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002179 | OpenFOAM | Bug | public | 2016-08-03 18:27 | 2017-09-03 19:49 |
| Reporter | wyldckat | Assigned To | henry | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Summary | 0002179: Problems with running the tutorial cases in "lagrangian/reactingParcelFilmFoam" | ||||
| Description | I've confirmed that the following issue occurs with "cylinder", "hotBoxes" and "splashPanel", but I didn't even bother checking "rivuletPanel", given the issue it is. For the "hotBoxes" tutorial case, if we compare the first time step output between the latest builds of 3.0.x-1c517d6c8485 and 4.x-16624b772ab1, only the following lines are different and they affect the subsequent time steps: Evolving thermoSingleLayer for region wallFilmRegion ... 3.0.x - smoothSolver: Solving for hf, Initial residual = 1, Final residual = 2.147073609e-19, No Iterations 1 4.x - smoothSolver: Solving for hf, Initial residual = 0.000125581383, Final residual = 6.782269813e-07, No Iterations 100 ... 3.0.x - min/max(T) = 350, 350 4.x - min/mean/max(T) = 300, 300, 300 ... These are the only differences for the first time step. Consistently the hf equation never gets solved, apparently because the temperature defined for the "wallFilmRegion" surfaces never gotten to be used, namely the 350K boundary conditions are not used in this region. Attached are the respective log files that have the first time step and initial start-up output. The files are pretty much identical between the two cases, after running "Allrun" and stopping the solver after a few time steps. I'm unfortunately not familiar with this part of the code and I'm guessing that the issue behind this is related to a few recent bug reports, where the incorrect field part is being used, i.e. boundary field versus internal field. | ||||
| Tags | No tags attached. | ||||
|
|
|
|
|
|
|
|
> Consistently the hf equation never gets solved But the hf equation is solved for both versions. What is the issue with these runs? Are you reporting that there is an error in 3.0.x or 4.x or neither or both? I fixed some problems with the film heat-transfer in OpenFOAM-4.x but did not make the same changes to 3.0.x. Are you satisfied with the behavior of 4.x and want the same changes to 3.0.x or are you satisfied with 3.0.x and want 4.x to work in the same way? |
|
|
Sorry, I should have been a lot clearer in my description. The reason why I stated that the "hf equation never gets solved", is in the sense that the matrix solver for the hf equation, is 'grinding numbers to a pulp' without achieving proper convergence, at least when compared with 3.0.x. And since it doesn't reach proper convergence (edit: doesn't achieve a solution for the equation on the same order as in 3.0.x), it's as if it isn't solved. I'm not certain of which case is correct, but the symptom is that the tutorials in 4.x take a few orders of magnitude longer to simulate (possibly 10x or more), because the hf equation is always being solved to the maximum number of iterations allowed, may it be 100 or 1000. The line shown in the report above gives the notion that there isn't much to solve for each hf equation, given that the whole field is at 300K, including boundaries. This seems to be why in 3.0.x the initial residual is 1.0, while in 4.x it starts off with 0.000125... After reporting this, I've already done some looking into the class "src/regionModels/surfaceFilmModels/thermoSingleLayer", namely in the method "updateSurfaceTemperatures()" and it gave the vibe that the problem could potentially be in the case set-up itself, given that the 350K value is only defined at the mapped surfaces... I'll try to look a bit more into this and give some more feedback on what I find. |
|
|
Note that for the first time-step and many subsequent time-steps the film-thickness in 0, i.e. there is no film. What is the temperature of a film which isn't there? What is the meaning of convergence of the temperature for an entity which does not exist? I believe that the corrections I made to OpenFOAM-4.x are correct and the behavior of the film temperature is correct. If you find evidence to the contrary please report and I will investigate. |
|
|
Many thanks for the details! I believe I've figured out the problem. Hopefully I'm able to explain it properly. The case set-up in OpenFOAM 3.0.x (and older versions) always assumed that a non-existing film + a heated wall = a heated surface. I better use an example... let's take the "hotBoxes" tutorial as the main example: 1- In the region "wallFilmRegion", when t=0, 'Tf' is set to 350K for the mapped boundaries "(region0_to.*)" and 300K for the internal field. 'Tf' is (from what I can understand) the mean temperature between the temperature on the wall and the temperature on the surface. 2- On the main region "region0", T has the boundary condition "zeroGradient" on the surfaces of the cubes. 3- What the "thermoSingleLayer" class does in the method "updateSurfaceTemperatures()" is take the initial 'Tf' field and: a- transfer the values from 'Tf' on the boundary field into the internal field of "Tw_" (temperature on or in walls, not sure which); b- and transfers the internal field of T into the internal field of "Ts_" (temperature on or in the surface). So what this effectively did in 3.0.x, is define that the initial temperature on the surfaces of the cubes was 350K, i.e. the cubes were initially hot surfaces. This is apparently because there was no other way to define the temperature on the surfaces of the cubes. ---- But when the implementation was corrected in 4.x (a non existing film cannot carry heat, temperature nor mass), the cases were not updated accordingly, to maintain the same simulation set-up. Since the films are non-existent at t=0, this means that there is no way for the current case to define the 350K value for the surfaces of the cubes. Consequently, the whole simulation remains at 300K for most, if not all, of the 2s of simulation. Any temperature variation is due to the energy absorbed by the particles moving within the domain and/or hitting the cube walls. But from what I can figure out, there is no chemical reaction between the particles and the cube walls/film surfaces, therefore there is no heat released on impact either. Which leads to the conclusion that the tutorial name "hotBoxes" no longer simulates "hot boxes", but instead simulates "boxes at ambient temperature" :) ---- In order to restore the same results and functionality to the "hotBoxes" tutorial case, it's necessary to impose an initial temperature on the surfaces of the cubes (boxes) so that they are starting at 350K, even if there is no fluid on their surfaces, so that as the film starts to appear, it heats up accordingly... But unfortunately I can't figure out how to do that at this point in time :( Setting the internal field of 'Tf' to 350K is the most likely possibility to fix this, but I haven't tested it yet... |
|
|
I've left the "hotBoxes" case running overnight with 3.0.x vs 4.x. It's currently at "Time = 1.26709" for the 4.x run and "Time = 1.21912" for 3.0.x, even though I started the 3.0.x run 5 minutes sooner than the 4.x. The 3.0.x case has the surface film at: min/max(T) = 300.0104962, 349.6609094 The 4.x case has the surface film at: min/mean/max(T) = 280.1503691, 299.6841843, 338.4211029 So the good news are that: 1- the "hotBoxes" tutorial case still lives up to its name, i.e. they are hot at some point in time. 2- the 'hf' equation starts to be solved in 3 or less iterations in 4.x, starting at "Time = 0.278433", roughly an hour of wall clock time of simulation. 3- the 4.x simulation is actually faster to run than the 3.0.x, not slower as I initially estimated. Nonetheless, this tutorial case is now essentially a different case from the one in 3.0.x, from the perspective of what's being simulated: - in 3.0.x there were 4 hot boxes that cool down, starting from 350K; - while in 4.x there are 4 boxes that heat up, starting from 300K. The physics are very likely better simulated in 4.x, but the case set-up doesn't refer to the same case that was in 3.0.x. |
|
|
I do not believe there is an issue with OpenFOAM-4.x and I don't see a reason to hack the cases so that the results are the same as previous versions of OpenFOAM. If you believe this is necessary then a patch is needed to make this the case, alternatively the cases to be renamed to make it clear the results are not exactly the same as previous versions or this report can be closed. |
|
|
I started running some of these cases at "lagrangian/reactingParcelFilmFoam" yesterday in OpenFOAM-dev, 4.x and 3.0.x, to try an figure out how the results changed and to suggest new names for the affected cases. 1. The results for the cylinder case look identical between OpenFOAM-dev (commit 1888b122cc34, Sat Jul 8 14:30:28) and OpenFOAM 3.0.x. The only difference is that with 3.0.x, the "wallFilmRegion" has a non-uniform temperature, because where the film didn't exist (deltaf==0), it was experiencing similar temperature to the wall. 2. The results for the "rivuletPanel" are similar, but not identical, although it seems consistent due to the 'normalDistribution' algorithm used for the film. At least qualitatively, they are the same cases. 3. I didn't have the time to run the 'hotBoxes' tutorial again with OpenFOAM-dev and OpenFOAM-4.x, but from my previous comments, I suggest that this tutorial is renamed to "heatingBoxes" or "warmingUpBoxes" or something similar, since the boxes and the film are heating up as the simulation evolves, instead of starting as 'hot'. Although now that I look into the case set-up, I can't quickly figure out through which mechanism it's heating up... 4. Unfortunately I stumbled upon a weird bug with "lagrangian/reactingParcelFilmFoam/splashPanel", which I haven't managed to confirm if it's only happening on my machine at home or if it's reproducible with any architecture, but the tutorial case has crashed in all of these 3 versions: - In OpenFOAM-dev (commit 1888b122cc34, Sat Jul 8 14:30:28), built with 64-bit labels, it crashed at 0.0996903s, due to the temperatures going below 200 K. - In OpenFOAM 4.x, build with 32-bit labels, it crashed at 0.122409s, for the same related reason. - In OpenFOAM 3.0.x, build with 32-bit labels, it crashed at 0.122409s, same reason. In all situations, it takes around 1300s to run till it crashes in my machine. This is potentially due to the architecture combination of using GCC "5.4.0-6ubuntu1~16.04.4" and an AMD A10-7850K. I'll try to run this case on another machine at work as soon as I can and let you know. As for the case name, it looks like it can stay the same, but the splash is considerably different as it looks like it 'sticks' to the surface on OpenFOAM-dev, while with the other two versions look like the splash would jump from the wall. Either way, I can open a new bug report for this issue in the case 'splashPanel' separately, once I've run the case on another machine with a different installation and reproduced the same issue. |
|
|
I believe that this issue has been fixed when the related report #2605 was fixed. I haven't had the time needed to run these cases again and confirm, but I believe it is, based on the description for the case(s) in #2605. Closing this as "no change required". I'll re-open after I've had a chance to confirm the results. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-08-03 18:27 | wyldckat | New Issue | |
| 2016-08-03 18:27 | wyldckat | File Added: log.reactingParcelFilmFoam.3.0.x | |
| 2016-08-03 18:27 | wyldckat | File Added: log.reactingParcelFilmFoam.4.x | |
| 2016-08-03 19:43 | henry | Note Added: 0006642 | |
| 2016-08-03 20:11 | wyldckat | Note Added: 0006644 | |
| 2016-08-03 20:12 | wyldckat | Note Edited: 0006644 | |
| 2016-08-03 20:18 | henry | Note Added: 0006645 | |
| 2016-08-03 22:47 | wyldckat | Note Added: 0006647 | |
| 2016-08-04 09:22 | wyldckat | Note Added: 0006648 | |
| 2017-07-06 17:58 | wyldckat | Relationship added | related to 0002605 |
| 2017-07-06 18:31 | henry | Note Added: 0008358 | |
| 2017-07-10 00:11 | wyldckat | Note Added: 0008371 | |
| 2017-09-03 19:49 | wyldckat | Assigned To | => henry |
| 2017-09-03 19:49 | wyldckat | Status | new => closed |
| 2017-09-03 19:49 | wyldckat | Resolution | open => no change required |
| 2017-09-03 19:49 | wyldckat | Note Added: 0008677 |
