Obstruction does not stop burning although fuel is used (No burn-away-feature)

[BastianStahra]

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:

1. Take the input file and run it.
2. Block 1 will disappear and block 2 will burn forever.

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):

• OS: Windows
• Version: [e.g. 22]

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

[rmcdermo]

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.

[rmcdermo]

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.

[drjfloyd]

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.

[BastianStahra]

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.

Thank you for your feedback.

ok, I understood that you use two different approaches when obstacles are burning:

1. with burn-away: you consider the fuel load in the cell and the cell disappears when the fuel is used/burned
2. without burn-away: HRRPUA gets changed to a mass flux BC and the fuel in the cell is not considered for the burnout; although you still calculate the fuel in the cell/XB. But for now the cell burns as long as I ramp it down.

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)).
When bulk density is given, it is used first.

Complex Geometries: In my modeling, I have complex geometries where it is difficult to predict exactly which sides of an object will burn.
Therefore, it is challenging to effectively use the RAMP function. My goal is to ensure that the burning stops when the fuel in a cell is consumed, regardless of whether the Burn-Away feature is enabled or not.

Expected Behavior: Based on the defined fuel (Hu * bulk density * volume), both obstructions should have used up their fuel after approximately 92 seconds.
While the obstruction with the Burn-Away feature disappears, the other should at least stop burning, even without the RAMP function. But I also understood that for now you did not code it that way.

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.
Pyrolysis does not seem practical for cell sizes of 10 cm or even larger than 10 cm, does it? Additionally, I frequently encounter numerical instabilities with the Burn-Away feature, so I am seeking a more stable solution.

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.
Is there an alternative method to ensure that the burning stops when the fuel is completely consumed?

Thank you for your support.

Best regards,
Bastian

[rmcdermo]

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.

1. Do what you expected to be able to do. This is possible, and I think reasonable.
2. Implement an EXTERNAL_FLUX_ONLY to a SURF that would apply a known flux to a MATL with a specified HEAT_OF_REACTION and a THICKNESS.

We need to discuss this and see who has the time to implement either of these.

[BastianStahra]

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?

[rmcdermo]

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.

[rmcdermo]

@mcgratta @BastianStahra Let's leave this open for a bit and let @BastianStahra post a case that fails with burn away.

[drjfloyd]

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.

pallet_burn_3in_a.txt

[drjfloyd]

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'/
&VENT MB='XMAX',SURF_ID='OPEN'/
&VENT MB='YMIN',SURF_ID='OPEN'/
&VENT MB='YMAX',SURF_ID='OPEN'/
&VENT MB='ZMAX',SURF_ID='OPEN'/
&VENT MB='ZMIN',SURF_ID='HOT'/

&OBST XB=0.3,0.4,0.3,0.4,0.2,0.3,SURF_ID='Top',BULK_DENSITY=100/
&OBST XB=0.3,0.4,0.3,0.4,0.3,0.4,SURF_ID='Side',BULK_DENSITY=100/

&MATL ID='WOOD',
DENSITY=460,
SPECIFIC_HEAT=1.2,
CONDUCTIVITY=0.09,
HEAT_OF_COMBUSTION=14660/

&SURF ID='Side',
RGB=102,102,0,
MATL_ID='WOOD',
THICKNESS=0.038,
STRETCH_FACTOR=1,
IGNITION_TEMPERATURE=440,
HEAT_OF_VAPORIZATION=208.,
HRRPUA=400,
BURN_AWAY=T/

&SURF ID='Top',
RGB=51,51,0,
MATL_ID='WOOD',
THICKNESS=0.019,
STRETCH_FACTOR=1,
IGNITION_TEMPERATURE=440,
HEAT_OF_VAPORIZATION=208.,
HRRPUA=400,
BURN_AWAY=T/

&SURF ID='HOT',TMP_FRONT=1500/

[BastianStahra]

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.

Thank you Randall (and all others of course, too), that is cool.
I have two main problems. First one is solved with the nightly version, indeed.

1. I made simulations with version 6.7.9-0 that ran fine. Same files don't even start with 6.9.1 anymore. This is often due to changes in "wording" or something but in this case I don't get it. With the daily/nightly version these simulations start again. Great job. Tested it with two files now and both work again 👯
   For example:
   Westviertel_V331.txt

2. There are examples where the simulations just have problems at a certain point:

first example is in the other issue:
"Errors with and without individual HOC with burn away feature #13121"

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.

[BastianStahra]

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.

Thank you Randall (and all others of course, too), that is cool. I have two main problems. First one is solved with the nightly version, indeed.

1. I made simulations with version 6.7.9-0 that ran fine. Same files don't even start with 6.9.1 anymore. This is often due to changes in "wording" or something but in this case I don't get it. With the daily/nightly version these simulations start again. Great job. Tested it with two files now and both work again 👯
   For example:
   Westviertel_V331.txt
2. There are examples where the simulations just have problems at a certain point:

first example is in the other issue: "Errors with and without individual HOC with burn away feature #13121"

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.
I started the same file fds version 6.7.9-0 and it runs fine until 2100s now and ongoing.

[mcgratta]

Try the failed cases again. I found a very simple bug that could cause these kinds of problems.

[BastianStahra]

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

[mcgratta]

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: ***@***.***>

[drjfloyd]

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.

[gforney]

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

[drjfloyd]

My full pallet burn case runs now.

[BastianStahra]

Try the failed cases again. I found a very simple bug that could cause these kinds of problems.

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.

[BastianStahra]

Try the failed cases again. I found a very simple bug that could cause these kinds of problems.

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

[BastianStahra]

Try the failed cases again. I found a very simple bug that could cause these kinds of problems.

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.

Balkon-BL0005.txt

[mcgratta]

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.

[BastianStahra]

@mcgratta Is it possible to send a case to you in private?

[mcgratta]

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.

[mcgratta]

I just noticed something. Consider these two obstructions:

&OBST ID='Verkleidung', XB=3.4,5.0,3.5,3.6,0.9,1.9, BULK_DENSITY=30.0, SURF_ID='SURF_PVCU(hart)-Verkleidung'/
&OBST ID='Verkleidung', XB=5.0,7.6,3.5,3.6,0.9,1.9, BULK_DENSITY=30.0, SURF_ID='SURF_PVCU(hart)-Verkleidung'/

If I write the two as one:

&OBST ID='Verkleidung', XB=3.4,7.6,3.5,3.6,0.9,1.9, BULK_DENSITY=30.0, SURF_ID='SURF_PVCU(hart)-Verkleidung'/

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 OBSTs into single cells. It is more efficient for the algorithm when the OBST is not broken apart by the mesh boundary. There is, however, still a problem with the boundary file. The colored contour remains even through the OBST is removed.

[BastianStahra]

I just noticed something. Consider these two obstructions:

&OBST ID='Verkleidung', XB=3.4,5.0,3.5,3.6,0.9,1.9, BULK_DENSITY=30.0, SURF_ID='SURF_PVCU(hart)-Verkleidung'/
&OBST ID='Verkleidung', XB=5.0,7.6,3.5,3.6,0.9,1.9, BULK_DENSITY=30.0, SURF_ID='SURF_PVCU(hart)-Verkleidung'/

If I write the two as one:

&OBST ID='Verkleidung', XB=3.4,7.6,3.5,3.6,0.9,1.9, BULK_DENSITY=30.0, SURF_ID='SURF_PVCU(hart)-Verkleidung'/

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 OBSTs into single cells. It is more efficient for the algorithm when the OBST is not broken apart by the mesh boundary. There is, however, still a problem with the boundary file. The colored contour remains even through the OBST is removed.

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?

[mcgratta]

The problem is simpler than that. When a single obstruction spans a mesh boundary, and that obstruction is broken into single cell obstructions via BURN_AWAY, each mesh then has its own individual obstructions. However, when the obstruction is originally broken at the mesh boundary, FDS first creates a thin obstruction in each mesh to represent the abutting surface. These thin obstructions then get broken up by the BURN_AWAY feature, leaving extra obstructions that do not disappear from Smokeview, even though they do disappear in the FDS simulation. In any case, I suggest that you do not break up obstructions at mesh boundaries. If you still see odd behavior, open a new issue because this one had become very busy.