Question regarding DEVC temperature drop after relocating sprinkler

[drjfloyd]

Discussed in #16052

^{Originally posted by Heng-sen March 15, 2026}
Dear FDS experts,

I would like to ask for your advice regarding an unexpected change in the DEVC temperature curves in my CSV output.

I am currently working on a stocker fire simulation. In my initial model (Version A), I checked the DEVC temperature curve at the height of Z=9.35m, and it successfully reached 68°C.

Subsequently, I modified the location of the sprinkler in a revised model (Version B) in an attempt to make it activate. However, I found that the peak temperature at the exact same monitoring location actually decreased, and the sprinkler still failed to activate.

What could be the possible reasons for this temperature drop? Any insights or suggestions would be greatly appreciated!
Stock(A).txt
Stock(B).txt

[drjfloyd]

Running the two cases there is a slight divergence in SPRINKLER LINK TEMPERATURE from LINK TEMPERATURE for the same RTI and C_FACTOR=0 and no droplets present. These should have the same result up until the sprinkler version has water flow.

[drjfloyd]

for S_L_T we do VEL^0.5*(TMP_G - TMP_DEVC)/RTI and then multiply by DT. The change is determined in two steps.
for L_T we do DTVEL^0.5(TMP_G - TMP_DEVC)/RTI which means we multiply by DT before dividing by RTI and the change is determined in one step.

Either the order of operations or the splitting is resulting in a slight divergence at machine precision that grows over time.

If I make the code duplicate except for C_FACTOR and C_DIMARZO then the results are identitcal.

@mcgratta in S_L_T we have this line that I do not think we should be doing:

DV%TMP_L = MAX(MIN(TMP_G,PY%INITIAL_TEMPERATURE) , DV%TMP_L + DT*RHS)

You could have the case where at the start there is no HVAC and no fire. Then HVAC with A/C turns on. This will start to drop the sprinkler link temperature. This would be captured as TMP_G would be below PY%I_T and the DV%TMP_L would drop below the initial temperature. However, if a fire then started TMP_G could suddenly jump above the PY%I_T and the MAX would force the DV%TMP_L to jump as well. If the concern is the explicit update running away we could make this implicit with Crank-Nicholson. However looking at the Tech Ref:

The Dimarzo term is meant to account for the cooling effect of droplets but it is a constant term. If the sprinkler were at the current temperature of the droplets attached to the link then the Dimarzo term should no longer have an effect. There should be some kind of temeprature difference for that term so it does not result in non-physical cooling when a sprinkler should be at steady-state.

There is another issue with this case. It dies in an MPI exchange. I modified the original case to run using more meshes. It is dying with both dv and release. Takes 6-7 minute to die.

case_c.txt

[drjfloyd]

Looking at the original NIST GCR I think Eq 11 is not completely correct. Droplets on the sprinkler link will exchange heat with the gas and the sprinkler. If conditions are right in terms of the local humidty and the droplet temperature, the droplets will evaporate; however, the energy to evaporate does not come from the link. It comes from the droplet. As the droplet cools it will convect heat away from the link but as the link temperature and doplet temperature approach one another that rate of heat transfer will not stay constant.

[drjfloyd]

A better approach for C_DIMARZO could be to simulate the tests with the two different spray nozzles, see what the droplet temperatures are at the link location, and then use that to derive some kind of effective heat transfer coefficient as a function of droplet temperature and spray density.

[mcgratta]

Yes, I remember that extra term being somewhat different in character than the other two. But I was afraid that the reported value of the "C_DIMARZO" (my coinage) only worked in that particular form. In any case, do what you think is necessary. I'll take a look at the failed MPI call.

[mcgratta]

The failure of case_c.fds has something to do with the fact that mesh 5 is getting hung up when a sprinkler activates, and then meshes 1, 6, and 7 get stuck in the density exchange waiting for mesh 5, which will never arrive. I'll hunt it down.

[drjfloyd]

Ah.... You know I think I know what the issue could be. If you look in smokeview the sprinkler is near a bunch of OBST. I wonder if it is just stuck in the insertion loop trying to randomly get a droplet in the gas phase.

[mcgratta]

Yes, I think that's it. The sprinkler appears to be embedded at the top surface of an OBST. I'm going to move it just to make sure.

[drjfloyd]

We could have a counter in the insert loop that gets incremented each time we fail in the solid check and then exit with an error message about checking sprinkler location after some reasonably large but not too large attempts (100? 1000?)

[mcgratta]

Yes, but maybe we can implement a percentage; as in, if you're missing more than 50%, say, of your attempts,

[mcgratta]

In any case, case_c works when I move the sprinkler 0.2 m higher.

[drjfloyd]

I think it nededs to be a counter. Say you had a sprinkler in a corner with a ceiling that was close to the corner. Only 1/4 of the hemisphere would be available. You could have a dozone failures before finally getting in the gas. Those first 12 failures would all be 100 % failure rate. We would need some counter so we aren't computing failure too quickly. Since we would already need a counter, having 100-1000 successive solid failures would only take a few ms of runtime.