-
Notifications
You must be signed in to change notification settings - Fork 614
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
Obstruction does not stop burning although fuel is used (No burn-away-feature) #13181
Comments
You have HRRPUA and a THICKNESS specified on the no BURN_AWAY case. When you use a THICKNESS to model pyrolysis you need to impose a heat source and a material reaction, see the user guide. Then the solid with shrink and stop burning. Do not use HRRPUA unless you use a RAMP. See 9.1.3 Thermally-Thick Solids that Burn at a Specified Rate. |
By the way, I do not disagree with your idea. But from what I can tell we have not coded things up this way. The MASS of an OBST figures into the REMOVE logic, but not into the MASS_FLUX logic in the code. Maybe @drjfloyd can correct me if I am wrong. But I think we would have to discuss whether this is the behavior we want or if we should throw a warning or error if the BULK_DENSITY and HRRPUA are specified without BURN_AWAY. |
We don't have things coded up to reduce thickness when HRRPUA is given. HRRPUA gets changed to a mass flux boundary condition. Outside of input processing, FDS no longer checks if an HRRPUA was defined. It just knows there is a mass flux BC. For that BC, we don't force the surface mass based on layers and materials to have anything to do with the total mass implied by either a mass flux or a mass fraction BC. The challenge here would be that when burn away is enabled, the OBST gets divided into one OBST for every grid cell, and the bulk density is applied to each of those sub-OBST. With burn away we track the mass in each grid cell of the OBST and can remove grid cell-by-grid cell. Without burnaway, we still compute the OBST mass when BULK_DENSITY is set, but now it is based on the entire XB. The OBST is not subdivided. We could check this mass value when the boundary condition is a mass flux or mass fraction condition, but we'd only be able to remove the entire OBST and not grid cell by grid cell. Unless we wanted BULK_DENSITY alone to trigger an OBST breakup, but I am not sure if we would want to do that. |
Thank you for your feedback. ok, I understood that you use two different approaches when obstacles are burning:
For both approaches, the fuel in the cell/XB is either calculated with the bulk density (Hu * bulk density * volume) or with the thickness (thickness * area of a cell surface * density(material)). Complex Geometries: In my modeling, I have complex geometries where it is difficult to predict exactly which sides of an object will burn. Expected Behavior: Based on the defined fuel (Hu * bulk density * volume), both obstructions should have used up their fuel after approximately 92 seconds. Simulation of Ignition and Burn-Out Behavior: I am looking for a straightforward method to simulate free ignition and burn-out behavior depending on the fuel in a cell. I would like to better understand how I can model this behavior without having to set the RAMP function individually for each possible burn scenario. Thank you for your support. Best regards, |
The only alternative to BURN_AWAY that is in the code now is using a RAMP (hrr curve). I can think of a couple of ways to do what you want, but they both require coding.
We need to discuss this and see who has the time to implement either of these. |
Thank you for the response, the new insights, and the discussion. When I think about it, my current wish is for an optimization of the burn-away feature so that it runs more stably and results in fewer crashes. I would like to improve this feature because of its great applicability to practical problems. How can I help with this? |
OK, I agree that a more robust burn away would be the best solution in the end. Kevin has been working hard to fix issues with minimum layer thickness. So, you can work in coordination with him. In the meantime, we post test_bundles here from our nightly continuous integration testing. The first step is to please run any cases you have that are failing using this latest source. The more examples we have where we fix the problem the more robust the feature should be. |
@mcgratta @BastianStahra Let's leave this open for a bit and let @BastianStahra post a case that fails with burn away. |
I have this somewhat complicated case which fails after about an hour. I ran in debug yesterday and it fails in about a day, and the error is in wall.f90 trying to access the RHO NWP array outside its bounds in 1D heat transfer (tries to get the 96th wall node when there is only 49 nodes). It is mutiple OBST types with burnaway. On type is half the thickness of the other which suggests that at some point an OBST with the thinner surface type burns away and that some wall cell variables get set for the thicker SURF but some keep the allocation for the thinner. If I make all the OBST the same type it runs to completion. I'll see if I can make a simpler case but posting this here as an example. |
This simple case fails with the same error in debug in a few minutes &HEAD CHID='burn_away_simple'/ &MESH XB=0,1,0,1,0,1,IJK=10,10,10/ &RADI NUMBER_RADIATION_ANGLES=200/ &TIME T_END=100/ &REAC ID='WOOD',C=1,H=1.8,O=0.9,CO_YIELD=0.008,SOOT_YIELD=0.004,HEAT_OF_COMBUSTION=14660/ &VENT MB='XMIN',SURF_ID='OPEN'/ &OBST XB=0.3,0.4,0.3,0.4,0.2,0.3,SURF_ID='Top',BULK_DENSITY=100/ &MATL ID='WOOD', &SURF ID='Side', &SURF ID='Top', &SURF ID='HOT',TMP_FRONT=1500/ |
Thank you Randall (and all others of course, too), that is cool.
first example is in the other issue: I will test my other problem-files now with the nightly version. That could take some days because the problems sometimes don't occur in the beginning but later in the simulation. |
I just tested that Westviertel_V331 file, for which I posted the file in the post above, with the nightly version and it was able to start BUT had problems after about 93 s, see screenshot below. |
FDS Source: Issue #13181. Fix bug related to OBST removal
Try the failed cases again. I found a very simple bug that could cause these kinds of problems. |
Yes, you will need the latest nightly build
…On Sun, Jul 21, 2024, 2:39 AM BastianStahra ***@***.***> wrote:
Try the failed cases again. I found a very simple bug that could cause
these kinds of problems.
Do I need a new nightly version for that? The nightly I find is still from
Jul 18
image.png (view on web)
<https://github.com/user-attachments/assets/3fa831eb-a329-45c5-84c5-590c8cf43876>
—
Reply to this email directly, view it on GitHub
<#13181 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACWPCF25HRGUQRNU7UOV65DZNNJQZAVCNFSM6AAAAABK5EGAGOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENBRGQ4TONJUGI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Firebot didn't seem to push up a test release overnight. The bug fix has the burn_away_simple case working. Trying now with the full case. |
current nightly bundles are up there now.
https://github.com/firemodels/test_bundles/releases/tag/FDS_TEST
…On Sun, Jul 21, 2024 at 7:39 AM Jason Floyd ***@***.***> wrote:
Firebot didn't seem to push up a test release overnight.
The bug fix has the burn_away_simple case working. Trying now with the
full case.
—
Reply to this email directly, view it on GitHub
<#13181 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC6UCRW4OIDZYPFWIPU2JJDZNOMYZAVCNFSM6AAAAABK5EGAGOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENBRGU3TQMRXHE>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
--
Glenn Forney
|
My full pallet burn case runs now. |
My case Westviertel_V331.txt runs longer than 93s now. At the moment it is at around 132s. I will keep you updated wheather it fully runs or not. |
330s and still running I try out the other cases now |
I made a testcase (Balkon-BL0005, see attached) with an easy balcony structure and 8 meshes to test the new nightly build from July 20th. The burn-away runs without a problem but on the mesh boundaries thin layers remain. At the moment they don't seem to disturb or result in an error; at least not in this small simulation. |
I'll see if I can fix this. When the cell-sized obstructions abut a mesh boundary, the opposite mesh creates a thin obstruction on which it performs the heat transfer calculation. For some reason, this thin obstruction is not being removed when the rest of the obstruction has burned away. |
@mcgratta Is it possible to send a case to you in private? |
I am currently focused on the Balkon case shown above. I would prefer not to accept a private file because then it will not be possible to follow this conversation in the future. |
I just noticed something. Consider these two obstructions:
If I write the two as one:
then I do not see a fictitious artifact at the mesh boundary. This has something to do with the fact that FDS breaks up these |
Could it be that FDS calculates boundary data, like temperature or pressure, on a per-cell basis, making them sensitive to mesh boundaries? While geometry spanning multiple mesh boundaries is correctly represented, might the boundary data lack the same flexibility, leading to discontinuities or artifacts in the boundary files? Does this suggest that while FDS handles large XB geometries well, boundary data calculations could struggle at mesh boundaries? |
The problem is simpler than that. When a single obstruction spans a mesh boundary, and that obstruction is broken into single cell obstructions via |
Describe the bug
I modelled two blocks. One with and one without burn-away-feature. Both have the same settings with the same HRRPUA and bulk density. Although burn-away feature is off, the block should stop burning after fuel is used.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Due to its defined fuel: Hu * bulk-density * Volume both Obstructions should have used their fuel after about 92 seconds.
With burn-away on: the obstruction should disappear,
burn-away off: the obstruction should at least stop burning.
Screenshots
Desktop (please complete the following information):
Additional context
As Kevin mentioned, the burn-away feature has problems and one should try to avoid it. But when fuel is used/burned-away, things should stop burning. It is not possible to model it via the ramp-function because in a complex situation you don't know how many sides of the cube or obstruction are burning.
noBurn-Away-nBA0001.zip
The text was updated successfully, but these errors were encountered: