HIDE/SHOW information in SMV is not based on Initial State logic of Controls.

[bwklein]

FDSVERSION
FDS-6.10.1-0-g12efa16-release

Describe the bug

See the attached FDS files.

hole_control-Default.zip

The 'and' control on line 11 of the .fds file should set the initial state of the OBST on line 21 to 'TRUE'. If you look at the _ctrl.csv file you will see that it is reporting a value of 1 at t=0.

In the .smv file, on line 263 and 264 it says:

HIDE_OBST     1
     1      0.000000

Which is hiding the OBST at t=0 in Smokeview (and in the PyroSim Results viewer).

Then after the first timestep in the .smv file lines 269 and 270 we see:

SHOW_OBST     1
     1      0.159665

Which makes the OBST show up as it should have been at t=0.

The OBST is then removed at t=2.0 based on the input file, where the inputs from lines 12 and 14 change to FALSE, which changes the 'and' CTRL to FALSE.

In the .smv file on lines 273 and 274, we see the input change state with DEVICE_ACT to FALSE at 2.08 s and on lines 275 and 276 this state change is reflected a timestep later at 2.235310 s where the 3 OBST are all hidden at the same time.

HIDE_OBST     1
     1      2.235310
HIDE_OBST     1
     2      2.235310
HIDE_OBST     1
     3      2.235310

Then on lines 281 and 282 we see 'Vent01' open at 2.24 s, which begins flow.

OPEN_VENT     1
     2      2.24

Expected behavior

The OBST controlled by the 'and' CTRL should have not been hidden at t=0 by the HIDE_OBST information on lines 263 and 264 as the initial state should be TRUE, as it is shown in the _devc.csv file. Then there wouldn't be a need for the SHOW_OBST on lines 269 and 270.

The Vent should be shown at the same time as the OBST are removed. I think that it is not in sync because the time values controlling the OBST are written with more precision, where the DEVICE_ACT and CLOSE/OPEN_VENT information seems to be rounded to 2 places after the decimal. The same precision should be used for all time values written in this section of the SMV file.

Additional context

The 'invert' and 'and' controls are a quirk of PyroSim, where we convert HOLE records to OBST and invert the logic to accomplish the user's intent. It is related to how we have to show original CAD geometry and Actual FDS geometry in the Results at the same time, with Controls changing the state of both in a reliable way. Having said that, it is only to explain the Control logic and shouldn't change the behavior or reflection of state in Smokeview or PyroSim Results.

[mcgratta]

I'll take a look to see if this is an FDS or SMV issue.

[bwklein]

I assume it is FDS, as it is what writes the information to the SMV file that seems to be the core of the issue.

[mcgratta]

Yes, this is an FDS issue. It is a bug in the order of routines called at start-up. I think I have a fix but need to test.

[mcgratta]

Jason -- could you take a look at this. I can solve Bryan's issue by moving the initial call of UPDATE_CONTROLS in main.f90 just in front of the first call to CREATE_OR_REMOVE_OBSTRUCTIONS (right around line 495. However, if I do this, there are seg faults in various routines, for example, the DV%SMOOTHED_VALUE gets touched in UPDATE_CONTROLS when it is still a large negative number. Moving other routines around led to additional issues. Can you think of a way to initialize the CONTROL to T without having to move routines around. The CONTROL for the first OBST is F making the OBST disappear initially. The call to UPDATE_CONTROLS fixes this, but leads to other issues.

[drjfloyd]

Getting the intial state of a CTRL means being able to get the inital state of any DEVC inputs that the CTRL might use. That initial state could be from some math operation on a DEVC for a solid object which means we have to wait until the solids are defined. Anything we did to force someting before CREATE_OR_REMOVE would not work for all possible CTRL functions.

[mcgratta]

Is the control logic in the input file reasonable, or have we created a endless loop?

[drjfloyd]

The first CTRL uses the second CTRL and second DEVC as input.
The second CTRL uses the first DEVC as input.

There is no loop.

[mcgratta]

Right, but we have to somehow update/initialize the controls, make initial show/hides of obstructions based on those controls, then initialize pressure solvers and pressure zone logic, which is what we need to do before we update/initialize the controls. Some thing along these lines. We may need to split a routine.

[drjfloyd]

We can't do controls until we have devices updated for the first time to set their initial values. UPDATE_GLOBAL_OUTPUTS needs to be done before the first call to UPDATE_CONTROLS. We might need a loop.

1. Call UPDATE_GLOBAL_OUTPUTS, EXCHANGE_GLOBAL_OUPTUTS, and UPDATE_CONTROLS.
2. Call CREATE_OR_REMOVE.
3. Call UPDATE_GLOBAL_OUTPUTS, EXCHANGE_GLOBAL_OUPTUTS, and UPDATE_CONTROLS. If in input processing we flagged DEVC and CTRL that are tied to an OBST, HOLE, or VENT then we could check if anything tied has changed and if so loop to 2. If not go on to 4.
4. Dump initial DEVC and CTRL data.

[mcgratta]

Yes, I think a flag of some sort to force a loop. I'll see what can be done.