Closed gforney closed 9 years ago
Hrm. Only hrr file uploaded. Here is the input. Thanks.
Original issue reported on code.google.com by Stephen.Olenick
on 2014-02-25 20:30:32
Topi,
Please have a look.
Thanks.
Original issue reported on code.google.com by randy.mcdermott
on 2014-02-25 21:35:58
This issue is related to pyrolyzing surfaces that don't conform to the grid. If I change
the pool side length from [-.2216,.2216]to [-0.2,0.2] the heat of combustion calculated
from _hrr.csv is correct. Also if I replace the liquid pool with a mass flux boundary,
the problem goes away.
The quick fix is to only use pools that conform to the grid.
I think there is AREA_ADJUST factor missing somewhere in SPECIES_BC.
Original issue reported on code.google.com by Topi.Sikanen
on 2014-02-26 14:22:24
Ok. Just so I understand, the HRR is correct but the burn_rate is being output incorrectly
because the area adjustment is not being incorporated correctly?
Original issue reported on code.google.com by Stephen.Olenick
on 2014-02-26 14:29:51
Does the pyro model return a mass flux or a velocity bc? It should return a mass flux.
The area adjust is done on line 831 of wall.f90.
Original issue reported on code.google.com by randy.mcdermott
on 2014-02-26 14:36:42
(No text was entered with this change)
Original issue reported on code.google.com by randy.mcdermott
on 2014-02-26 14:37:03
Yes I just noticed that.
The pyro model write the massflux in ONE_D%MASSFLUX and ONE_D%MASSFLUX_ACTUAL. The
output in _hrr.csv is (dump.f90:6232)
WC%ONE_D%MASSFLUX_ACTUAL(REACTION(1)%FUEL_SMIX_INDEX)*WC%AW*WC%ONE_D%AREA_ADJUST
so the scaling is apllied here too.
Original issue reported on code.google.com by Topi.Sikanen
on 2014-02-26 14:40:54
Ok.
I'm pretty sure I've pinpointed the culprit. The issue is not lack of AREA_SCALING
but rather too much of it. PYROLYSIS gets called on the CORRECTOR step every WALL_INCREMENT
timesteps. This is when massflux(:) gets overwritten. The AREA_ADJUST scaling however
is applied every timestep on both CORRECTOR and PREDICTOR.
I'll upload a fix for this later today.
So in summary for Stephen: Nothing in the results is correct (if the pool doesn't conform
to the grid).
Original issue reported on code.google.com by Topi.Sikanen
on 2014-02-26 16:02:45
Good to know. I wonder what will happen to the liquid pool fire results in the validation
guide...
Original issue reported on code.google.com by Stephen.Olenick
on 2014-02-26 16:10:07
All the validation pool fire cases are grid conforming so this shouldn't affect them.
Original issue reported on code.google.com by Topi.Sikanen
on 2014-02-26 16:18:18
Good point. Agreed. Let me know once the change is committed and I'll either compile
a new version. I've had issues compiling in the past, so if so, I might beg you for
an executable. Thanks for the sleuthing on this.
Original issue reported on code.google.com by Stephen.Olenick
on 2014-02-26 16:22:18
Nice work, Topi. Can you please add a verification case for this. Attached is a simple
case I was playing with, constant HRRPUA and non conforming OBST. It gets the correct
HOC=HRR/Burn Rate. Perhaps you could just add the pool fire instead of the burner.
Note: you don't necessarily need a write up. Just add something to dataplot that gets
checked every night so this does not bite us again. Thanks.
Stephen, good catch! Thanks!
Original issue reported on code.google.com by randy.mcdermott
on 2014-02-26 16:47:33
Just committed a fix for this. Note that cell_burn_away seems to be broken but apparently
it was already broken and has nothing to do with this update.
Original issue reported on code.google.com by Topi.Sikanen
on 2014-02-26 18:20:57
Topi. If fixed, please mark as fixed.
Stephen, please verify. Thanks.
Original issue reported on code.google.com by randy.mcdermott
on 2014-02-26 19:07:41
Cool. I got the new source. I am a little tied up, but I'll try to compile in the
next day or two and will give it a roll and will report back. Thanks again.
Original issue reported on code.google.com by Stephen.Olenick
on 2014-02-26 19:09:43
Confirmed.
Ran the same off-gridline pool fire and heat of combustion is back to reasonable numbers.
I'll let you know if I hit any other related issues. Thanks.
Original issue reported on code.google.com by Stephen.Olenick
on 2014-02-27 12:44:18
Great.
I also uploaded a verification case for non-gridconforming vent.
MArking this as fixed
Original issue reported on code.google.com by Topi.Sikanen
on 2014-02-27 13:05:48
Topi,
If Stephen has verified, you can mark as verified and it comes off your "to do" list.
I have done this here.
R
Original issue reported on code.google.com by randy.mcdermott
on 2014-02-27 14:08:31
Note, while I ran the run I attached above with svn 18493, I tried a different one about
10 minutes ago and it crashed almost immediately. No real output indicating why it
doesn't like it. Compiled with gfortran, so that could be the issue. Also, there
are build errors on the firebot.
Original issue reported on code.google.com by Stephen.Olenick
on 2014-02-27 14:12:21
Yes, current SVN is not a green light. We're working on it. Please post the case that
crashes in a new Issue.
Original issue reported on code.google.com by randy.mcdermott
on 2014-02-27 14:15:48
Reposted as issue 2096. Thanks.
Original issue reported on code.google.com by Stephen.Olenick
on 2014-02-27 14:25:18
Another followup question on this topic. If you have a non-grid-conforming pool geometry,
how does the liquid pyrolysis model deal with that? For instance, if one inputs a
non-conforming vent with a HRRPUA, FDS adjusts to make sure the intended HRR is achieved
even if coming from a non-conforming vent. But what about a pool fire with liquid
pyrolysis? Or any, non-liquid, pyrolysis I guess. I get that we have corrected the
output of the burn rate, but if I put in a non-conforming grid pool fire, will it try
to adjust the pyrolysis rate based on my intended pool size, or is the geometry input
and then pyrolysis occurs based on whatever shifting of the pool geometry takes place?
Original issue reported on code.google.com by Stephen.Olenick
on 2014-03-03 15:47:24
Everything in pyrolysis is done on "per unit area " basis. The routines don't know
the size of the pool. The predicted burning rate is then correvted she same way as
for the HRRPUA case.
Original issue reported on code.google.com by Topi.Sikanen
on 2014-03-03 16:29:32
Per unit area of the intended (input) area, or per unit area of the actual grid-snapped
geometry? Thanks Topi!
Original issue reported on code.google.com by Stephen.Olenick
on 2014-03-03 16:32:17
In other words, if a liquid pool gets its geometry adjusted from whatever is input (intended)
to whatever the grid size is, even if the pyrolysis submodel is based on per unit area,
is that MLRPUA adjusted to the intended pool size, or is it simply applied to the adjusted
pool size?
Original issue reported on code.google.com by Stephen.Olenick
on 2014-03-04 11:41:29
The MLRPUA is adjusted to the intended pool size.
Original issue reported on code.google.com by Topi.Sikanen
on 2014-03-04 12:36:25
Original issue reported on code.google.com by
Stephen.Olenick
on 2014-02-25 19:32:40