MASS_FLUX_TOTAL not influenced by TAU_V

[charlie-thornton]

The attached file defines a supply SURF whose rate is defined using MASS_FLUX_TOTAL. The parameter TAU_V=10.0 is used to cause the rate to ramp up over ten seconds.

test.fds.txt

test.fds
Generated by PyroSim - Version 2016.1.0727
Jul 27, 2016 2:58:48 PM

&HEAD CHID='test'/
&TIME T_END=10.0/
&DUMP RENDER_FILE='test.ge1', COLUMN_DUMP_LIMIT=.TRUE., DT_RESTART=300.0/

&MESH ID='mesh', IJK=12,12,12, XB=0.0,3.0,0.0,3.0,0.0,3.0/

&DEVC ID='vel', QUANTITY='VELOCITY', XYZ=1.5,1.5,0.25/

&SURF ID='supply',
    RGB=26.0,204.0,26.0,
    MASS_FLUX_TOTAL=-10.0,
    TAU_V=10.0/

&VENT ID='Vent', SURF_ID='supply', XB=1.0,2.0,1.0,2.0,0.0,0.0/ 
&VENT ID='open', SURF_ID='OPEN', XB=0.0,3.0,0.0,3.0,3.0,3.0/ 

&TAIL /

The parameter TAU_V does not seem to impact the results - a device measuring velocity shows the full value achieved after four seconds. I expected it to take ten seconds.

[mcgratta]

Try using TAU_MF=10.

[charlie-thornton]

That works well. Thank you.

Table 10.1 "Parameters for controlling the time-dependence of given quantities" incorrectly lists TAU_V and RAMP_V as the parameters for MASS_FLUX_TOTAL.

[charlie-thornton]

It looks like we've got some work to do in PyroSim. Since TAU_MF is used to ramp both MASS_FLUX_TOTAL and individual species injection using MASS_FLUX(N) with TAU_MF(N), we're going to need to ensure that the two aren't both used on the same surface - which is actually what the user was trying to do that led me here. Is my thinking correct on avoiding using MASS_FLUX_TOTAL with MASS_FLUX(N)?

[mcgratta]

I'm going to transfer to Jason Floyd, who implemented this. I'm not exactly sure if this mix of parameters is kosher.

[drjfloyd]

A user should only be specifying one set of boundary conditions (species, temperature, and velocity). MASS_FLUX_TOTAL sets the velocity as does MASS_FLUX (which also sets species). I'll add error trapping for this.

I'll look at the TAU issue and make sure documentation agrees with what is coded.

[drjfloyd]

Due to the way boundary conditions are implemented in wall.f90, within FDS an outgoing MASS_FLUX_TOTAL is converted to a VEL input and an inflowing to a MASS_FLUX input. Originally MASS_FLUX_TOTAL was added to support removing a constant mass flux which is why it was tagged to TAU_V. Later we added logic for inflowing, but did not make sure we converted any TAU_V or RAMP_V inputs to TAU_MF and RAMP_MF inputs. Since the input is called MASS_FLUX_TOTAL, I think it makes more sense for the input to be always be TAU_MF and convert to TAU_V for outflow rather than the other way around.

[drjfloyd]

On second thought, does it make sense for MASS_FLUX_TOTAL to be used as an inflow or should we just force user's via error trapping to use MASS_FLUX at that point?

[mcgratta]

Trap it as an ERROR.

[drjfloyd]

Fixed. TAU_V remains the parameter to use since outflow is treated as a VEL input and inflow is now trapped.

[charlie-thornton]

Thank you. As I understand where things sit now:

• MASS_FLUX_TOTAL can only be used for outflows. Attempting to use MASS_FLUX_TOTAL with an inflow (i.e. setting the parameter <0) will result in an error.
• MASS_FLUX_TOTAL should be ramped using TAU_V and RAMP_V as shown in the manual. Earlier discussion of ramping it with _MF was only possible because I was using it in the wrong context.
• MASS_FLUX(N) can only be used for inflows and is ramped with the TAU_MF and RAMP_MF.
• MASS_FLUX(N) should not be used on the same SURF line as the other inflow velocity boundary conditions VEL and VOLUME_FLOW.

(What is the protocol on this issue tracker? Am I the one who clicks close?)

[drjfloyd]

Your understanding is correct. You can click close if you are satisfied.