Product's mass in pyrolysis

[gforney]

Please complete the following lines...

FDS Version:6.0.1.
SVN Revision Number:17534
Compile Date:Tue, 26 Nov 2013
Smokeview Version/Revision:6.1.5.
Operating System: Window 7

Describe details of the issue below:
The total mass of reactant material is 8 kg, and it  should consume completely. 
The relative amounts of products respects the yield NU_SPEC, but the total mass of
the products is much lower than what I expect.

Original issue reported on code.google.com by ilenia.manassero on 2014-04-01 16:24:37

---

• _Attachment: 0104_prova2.fds_

[gforney]

I'll take a look.

Original issue reported on code.google.com by mcgratta on 2014-04-01 16:49:26

[gforney]

Are you sure that the cube evaporates completely in 2000 s? It does not when I run it.
I still see the total gas mass rising.

Original issue reported on code.google.com by mcgratta on 2014-04-01 17:08:35

[gforney]

The attached test case is a simplified version of what I think is the problem. There
is a wall patch that off-gases 4 inert gases when heated. I made the background gas
NITROGEN, and added ARGON as an additional tracked species. The initial mass fraction
of ARGON is 1. I expect that the total mass of NITROGEN and ARGON should not change.
However, the ARGON mass increases steadily. If I add a solid residue, ASH, with a 1%
yield, and I set its density to 1% of the original solid, I do not see the ARGON mass
steadily increase. I think that this means when I prevent shrinking/swelling, the mass
flux boundary conditions works. When the solid shrinks away, the mass flux boundary
condition has an error. I cannot understand why this should be. I checked the MASSFLUX
of all species in the wall routine where the species BC is computed, and everything
looks OK. But I can't be sure that the density and/or temperature at the wall will
ensure proper mass conservation.

This simplified case (burnaway.fds) seems to explain the problem in the originally
posted test case.

Original issue reported on code.google.com by mcgratta on 2014-04-03 17:35:44

---

• Attachment: burnaway.fds

[gforney]

I will work on this next week.

Original issue reported on code.google.com by shostikk on 2014-04-04 06:45:48

[gforney]

Thank you very much for your work.
I expect that the cube evaporates completely in 2000 s (it should do it in real).
I have ran the same code for more second but at about 5000 s it returns numerical instability
error. So I have increased the domain, it works properly until the end and the cube
evaporates completely at 5350 s. However the total mass of the products is still much
lower than the reactant's mass.
I have applied the code to other materials, and it returns always the same problem.

Original issue reported on code.google.com by ilenia.manassero on 2014-04-04 16:27:02

[gforney]

This file confirms Kevin's observation. It may not be directly related to Ilenia's problem,
which can also be due to the solid not burning completely.

However, let's work first on this, more fundamental problem: The enclosed file has
four species:
&SPEC ID='NITROGEN', BACKGROUND=.TRUE. /
&SPEC ID='OXYGEN', MASS_FRACTION_0=0.0 /
&SPEC ID='CARBON DIOXIDE', MASS_FRACTION_0=1.0 /
&SPEC ID='CARBON MONOXIDE', MASS_FRACTION_0=0.0 /

The pyrolyzing material yields only OXYGEN. Still, the mass of CARBON DIOXIDE within
the (closed) gas space increases. However, CARBON MONOXIDE does not change. NITROGEN
first increases and then decreases. Plotting the 'MASS FLUX'es of each species does
not show anything wrong. 

Adding the char did not resolve the problem. It just made the pyrolysis much slower.
With long enough simulation time and enough heat, it would also show increasing CO2
concentration. 

The only thing that seems to matter is the time step DT. Decreasing DT substantially
(from 0.05 to 0.001) decreases the CO2 mass increase substantially. It does not eliminate
it, though.

Changing the pyrolysis model into a specified MASS_FLUX boundary condition removed
the problem of increasing CO2. So, the boundary condition type seems to be important.

Conclusion: the problem is somewhere in the density/species calculation and is numerical
in nature. 

Original issue reported on code.google.com by shostikk on 2014-04-16 10:46:13

---

• Attachment: burnaway.fds

[gforney]

I wonder if this this a CHECK_MASS_FRACTION error?  

Original issue reported on code.google.com by drjfloyd on 2014-04-16 11:52:51

[gforney]

The plot thickens...

Take a look at the two cases I've attached. In one case, I set a REFERENCE_TEMPERATURE.
In the other, I set A=0.1, E=0. The case with A and E does what I expect -- 0.4 kg
of gas are generated from a patch of surface that is 0.2 m by 0.2 m by 0.1 m thick
with a density of 100 kg/m3. There is some error initially in the background gas (N2),
but very little error in the inert species (Ar) that has an initial mass fraction of
1. The case with REF_TEMP has the same problem I have seen with the original file.
Both cases have N_REACTIONS=1, both are doing very similar things. I haven't figured
out why one works and not the other.

Original issue reported on code.google.com by mcgratta on 2014-04-16 20:43:02

---

• Attachment: burnaway3.fds
• Attachment: burnaway2.fds

[gforney]

I think I fixed this, but I will wait for firebot to confirm that I have not caused
more trouble. The problem was in the calculation of UW and UWS. In wall.f90, for specified
mass flux, in the corrector step, the UW value was erased in divg.f90. We have been
using only UWS from the PREDICTOR step to calculate du/dt, dv/dt and dw/dt at boundaries.
The value of UW from wall.f90 was not being used, and that caused inaccuracies, especially
in one of the cases above where the mass flux oscillates.

Original issue reported on code.google.com by mcgratta on 2014-04-18 18:44:36

[gforney]

Very good. It would take me a year to find that. Thanks 

And I will have to do something to those fluctuations. But thats another issue. 

Original issue reported on code.google.com by shostikk on 2014-04-18 19:46:06

[gforney]

since firebot has been fairly happy as of late marking as verified

Original issue reported on code.google.com by drjfloyd on 2014-05-19 18:25:56