Closed gforney closed 9 years ago
I'll take a look at the case.
Original issue reported on code.google.com by mcgratta
on 2009-06-30 15:33:28
The resolution of the grid is very coarse, but I am not sure that this is the only
problem. Have you tried the calculation with a finer grid?
Simo -- could you look at this case.
Original issue reported on code.google.com by mcgratta
on 2009-06-30 16:07:17
I lowered the resolution because the model was running for an even shorter time with
a finer grid. If I raise the grid from 12,12,24 to 24,24,24, The run time becomes
half- i.e. from approx 9 sec to 4.5 sec even though it is set to run for 900 sec. If
I lower the mesh even lower, say to 6,6,24, it runs full length.
Original issue reported on code.google.com by calibob2001
on 2009-06-30 16:45:06
Typically, the liquid fuel model works with grid cells on the order of a few
centimeters in width. The reason is because the evaporation rate of the fuel is tied
to the mass fraction of vapor in the cell nearest the surface. Your grid has very
large cells relative to the size of the pan. I don't have much experience running
the liquid fuel model at such coarse resolution.
Original issue reported on code.google.com by mcgratta
on 2009-06-30 17:05:44
Then why, when I increase to a much finer mesh, which in theory should allow FDS to
better track vapor and other prorogation's, does the run end prematurely? Is there
a
maximum HRR that is built into the code that this is reaching for some reason? Or if
the thermal/radiation expansion is above a certain rate does FDS force quit?
Also: I tried adding in STATUS_FILES under the dump command to try and track errors,
but I couldn't get it to work.
Original issue reported on code.google.com by calibob2001
on 2009-06-30 17:14:38
I'll take a look asap.
Meanwhile, issue 784 is associated.
http://code.google.com/p/fds-smv/issues/detail?id=784
Original issue reported on code.google.com by shostikk
on 2009-07-01 13:21:20
Have there been any advancements towards a solution?
Original issue reported on code.google.com by calibob2001
on 2009-09-08 14:35:16
I suggest that you run the most problematic case with FDS 5.4.0. If the calculation
is failing due to some instability or other error early in the run, post the input
file and we will work on that. If the problem has to do with the liquid fuel model
in FDS, note that in 5.4.0 we have added a warning in the User's Guide to emphasize
that this feature is very sensitive to numerous parameters.
Original issue reported on code.google.com by mcgratta
on 2009-09-08 14:40:55
I noticed that you have very coarse resolution in your case - 2 cells spanning the
pool. This is the reason for huge burning rate. Try to improve the resolution so that
you have something like 10...20 cells spanning the pool surface.
In the long run, we try to make the liquid model robust enough so that it can adapt
for different resolutions. But you should understand, that predicting the burning
rate on any realistic fire source requires fairly good resolution for the resolved
gas temperature field.
Original issue reported on code.google.com by shostikk
on 2009-09-17 12:55:28
I'm sorry it has taken me so long to continue my study on this issue but I this is
what I have found.
While running this .fds file under the newest release 5.4.3 (SVN Revision Number
5414) I am getting the same problem. FDS does not finish running the simulation and
ends without any warnings whenever I either increase the mesh setting or move the pan
closer to the center of the room.
Any ideas?
Thank You for all your help,
Rob
Original issue reported on code.google.com by calibob2001
on 2010-01-04 21:04:40
What is the basis for CONDUCTIVITY=0.01 for the liquid? I changed this value to 0.2
and the HEPTANE_CENTER case ran to completion. However, I think the results are
nonsense because of the excessively coarse grid. As said above, the liquid fuel
pyrolysis is extremely sensistive to both numerical and physical parameters,
especially the grid.
Original issue reported on code.google.com by mcgratta
on 2010-01-04 21:28:14
I'm closing this issue, as the main problem was fixed by changing the model inputs to
more appropriate.
Original issue reported on code.google.com by shostikk
on 2010-03-02 11:11:11
Original issue reported on code.google.com by
calibob2001
on 2009-06-30 15:23:46