firemodels / fds

Fire Dynamics Simulator
https://pages.nist.gov/fds-smv/
Other
650 stars 618 forks source link

Initial Region issue #12187

Closed antoniomaze closed 10 months ago

antoniomaze commented 11 months ago

Hi Everyone,

I am simulating a building that is venting outside via openings and I want to set out different inside and outside temperatures (inside 25 and outside 37 degrees) to see how this would impact the performance of the opening in case of fire within the building. To set the outside temperature I have used the Initial Region model. For example

&INIT ID='37', TEMPERATURE=37.0, XB=0.0,6.5,0.0,28.0,0.0,8.0/

However, when I checked the initial velocities field outside and inside of my building, I noticed some air movement that in my opinion is not correct and alters the results.

I have then run a test and I believe I found an issue that maybe you can help me to solve. I am sure that solving this issue will lead me to solve the issue in my main project.

I have modelled a simple rectangular space with open boundaries other than the bottom. I have run two tests and displayed the velocities fields as per the below figures.

  1. Test No.1- Figure above • Initial Region (same size as the box) with 37 degree • All sides considered open with 37 degrees (for example &VENT ID='Mesh Vent: MESH-01 [XMAX]', SURF_ID='OPEN', XB=6.5,6.5,0.0,28.0,0.0,8.0, TMP_EXTERIOR=37.0/, etc.) • Ambient temperature in the simulation parameter 25 degrees (&MISC TMPA=25.0/)
  2. Test No.2- Figure below • Initial Region (same size as the box) with 37 degree • All sides considered open with 37 degrees (for example &VENT ID='Mesh Vent: MESH-01 [XMAX]', SURF_ID='OPEN', XB=6.5,6.5,0.0,28.0,0.0,8.0, TMP_EXTERIOR=37.0/, etc.) • Ambient temperature in the simulation parameter 37 degrees (&MISC TMPA=37.0/)

The only difference between the two tests is the Ambient temperature in the simulation parameter changed from 25 to 37 degrees (&MISC TMPA=…). As you can notice Test No. 2 gives what we expect to happen. Velocities close to zero and no air movement. On the other hand, Test No. 1 shows an air movement that should not happen in a box at the same temperature inside and at the boundary.

It looks like when we use the Initial Regions the temperature is forced to be 37 degrees from the beginning but other quantities are not or two different flows with different temperatures are forced in the same space(????)

Please bear in mind that I cannot use the configuration of Test No.2 in my model because I need to set up two regions with different temperatures. Therefore, I am forced to keep the Ambient temperature in the simulation parameter at 25 degrees.

Could you please advise if this is an FDS issue and if there is any way to modify Test No.1 to have the same velocity field as Test No.2 which is physically correct? If not how can I model two spaces with different temperatures avoiding using Initial Regions? Thanks

test no 1

test no 2

mcgratta commented 11 months ago

Post a simple input file that demonstrates the problem.

antoniomaze commented 11 months ago

TestFinal_1.fds Generated by PyroSim - Version 2023.1.0524 Oct 11, 2023, 12:32:55 PM

&HEAD CHID='TestFinal_1'/ &TIME T_END=60.0/ &DUMP DT_SL3D=1.0/ &MISC TMPA=25.0/

&MESH ID='MESH-01', IJK=13,56,16, XB=0.0,6.5,0.0,28.0,0.0,8.0/

&SURF ID='ADIABATIC', COLOR='GRAY 80', DEFAULT=.TRUE., ADIABATIC=.TRUE./

&INIT ID='37', TEMPERATURE=37.0, XB=0.0,6.5,0.0,28.0,0.0,8.0/

&OBST ID='Obstruction', XB=0.0,6.5,0.0,28.0,0.0,0.0, SURF_ID='ADIABATIC'/

&VENT ID='Mesh Vent: MESH-01 [XMAX]', SURF_ID='OPEN', XB=6.5,6.5,0.0,28.0,0.0,8.0, TMP_EXTERIOR=37.0/ &VENT ID='Mesh Vent: MESH-01 [XMIN]', SURF_ID='OPEN', XB=0.0,0.0,0.0,28.0,0.0,8.0, TMP_EXTERIOR=37.0/ &VENT ID='Mesh Vent: MESH-01 [YMAX]', SURF_ID='OPEN', XB=0.0,6.5,28.0,28.0,0.0,8.0, TMP_EXTERIOR=37.0/ &VENT ID='Mesh Vent: MESH-01 [YMIN]', SURF_ID='OPEN', XB=0.0,6.5,0.0,0.0,0.0,8.0, TMP_EXTERIOR=37.0/ &VENT ID='Mesh Vent: MESH-01 [ZMAX]', SURF_ID='OPEN', XB=0.0,6.5,0.0,28.0,8.0,8.0, TMP_EXTERIOR=37.0/

&SLCF QUANTITY='VELOCITY', VECTOR=.TRUE., ID='Slice', PBY=15.0/ &SLCF QUANTITY='VELOCITY', VECTOR=.TRUE., ID='vel', PBZ=1.0/ &SLCF QUANTITY='VELOCITY', VECTOR=.TRUE., ID='Slice01', PBZ=7.0/ &SLCF QUANTITY='VELOCITY', VECTOR=.TRUE., ID='Slice02', PBX=3.0/ &SLCF QUANTITY='TEMPERATURE', ID='Slice03', PBY=15.0/ &SLCF QUANTITY='DENSITY', VECTOR=.TRUE., ID='Slice04', PBY=15.0/ &SLCF QUANTITY='DENSITY', VECTOR=.TRUE., ID='Slice05', PBX=3.0/ &SLCF QUANTITY='TEMPERATURE', VECTOR=.TRUE., ID='Slice06', PBX=3.0/ &SLCF QUANTITY='PRESSURE', VECTOR=.TRUE., ID='Slice07', PBX=3.0/ &SLCF QUANTITY='PRESSURE', VECTOR=.TRUE., ID='Slice08', PBY=15.0/ &SLCF QUANTITY='TEMPERATURE', VECTOR=.TRUE., ID='Slice01', PBZ=7.0/ &SLCF QUANTITY='TEMPERATURE', VECTOR=.TRUE., ID='Slice01', PBZ=1.0/ &SLCF QUANTITY='DENSITY', VECTOR=.TRUE., ID='Slice01', PBZ=7.0/ &SLCF QUANTITY='DENSITY', VECTOR=.TRUE., ID='Slice01', PBZ=1.0/ &SLCF QUANTITY='PRESSURE', VECTOR=.TRUE., ID='Slice01', PBZ=7.0/ &SLCF QUANTITY='PRESSURE', VECTOR=.TRUE., ID='Slice01', PBZ=1.0/

&TAIL /

mcgratta commented 11 months ago

I don't have a good answer yet. I simplified the case to this, but I still see the movement. `` &HEAD CHID='TestFinal_2'/ &TIME T_END=10.0/ &MISC TMPA=25.0/

&MESH IJK=13,56,16, XB=0.0,6.5,0.0,28.0,0.0,8.0/

&WIND STRATIFICATION=F /

&INIT ID='37', TEMPERATURE=37.0, XB=0.0,6.5,0.0,28.0,0.0,8.0/

&SURF ID='FLOOR', ADIABATIC=T /

&VENT SURF_ID='FLOOR', XB=0.0,6.5,0.0,28.0,0.0,0.0 / &VENT SURF_ID='OPEN', XB=6.5,6.5,0.0,28.0,0.0,8.0, TMP_EXTERIOR=37.0, TMP_EXTERIOR_RAMP='tmp' / &VENT SURF_ID='OPEN', XB=0.0,0.0,0.0,28.0,0.0,8.0, TMP_EXTERIOR=37.0, TMP_EXTERIOR_RAMP='tmp' / &VENT SURF_ID='OPEN', XB=0.0,6.5,28.0,28.0,0.0,8.0, TMP_EXTERIOR=37.0, TMP_EXTERIOR_RAMP='tmp' / &VENT SURF_ID='OPEN', XB=0.0,6.5,0.0,0.0,0.0,8.0, TMP_EXTERIOR=37.0, TMP_EXTERIOR_RAMP='tmp' / &VENT SURF_ID='OPEN', XB=0.0,6.5,0.0,28.0,8.0,8.0, TMP_EXTERIOR=37.0, TMP_EXTERIOR_RAMP='tmp' /

&RAMP ID='tmp', T= 0., F=1. / &RAMP ID='tmp', T=60., F=1. /

&SLCF QUANTITY='TEMPERATURE', PBX=3.25, VECTOR=T / &SLCF QUANTITY='PRESSURE', PBX=3.25, CELL_CENTERED=T / &SLCF QUANTITY='H', PBX=3.25, CELL_CENTERED=T /

&BNDF QUANTITY='WALL TEMPERATURE', CELL_CENTERED=T /

&TAIL /


JH -- since you've recently looked at pressure and temperature BCs, could you have a look at this.
drjfloyd commented 11 months ago

With ADIABATIC, FDS finds a surface temperature such that the convective flux plus the radiative flux is zero. In case 1, the gas temperature next to the ADIABATIC OBST is 37 C but the radiative flux is primarily determined by radiation from the OPEN boundaries which are at 25 C. The surface temperature is going to wind up between 37 and 25 C. This will mean a slight heat loss from the gas to the surface and a slight reradiation from the surface out the OPEN boundaries. Since you are losing heat from the gas next to the wall it is cooling, increasing in density, which is causing flow.

mcgratta commented 11 months ago

I still see the flow even if I turn radiation off.

drjfloyd commented 11 months ago

Are we processing the TMP_EXTERIOR RAMP in initialization? If not then in the first PREDICTOR we would have 25 C air over 37 C air.

mcgratta commented 11 months ago

I printed out the values of TMP_F, RHO_F, etc, at the OPEN boundary. I didn't see anything obvious. Everything was 37 C. But I'll look for other things.

drjfloyd commented 11 months ago

I changed the inputs to this (adjust VENTs accordingly): &MISC TMPA=25.0,NOISE=F/ &MESH IJK=10,1,10, XB=0.0,1.0,0.0,1.0,0.0,1.0/ &RADI RADIATION=F/ &WIND STRATIFICATION=F /

With no NOISE and no STRATIFICATION we should see DP=0 everywhere and the FVX,Y,Z should each be the same.

I write row and column 5 of various arrays. I see at the start of the first time step that:

divg:DP(5,1,:): 0.000000000000000E+000 -2.903549004351795E-004 0.000000000000000E+000 ... mass:FVY(5,1,:): 0.000000000000000E+000 -6.413490463399427E-009 0.000000000000000E+000 mass:FVZ(5,1,:): 6.165346455588860E-008 -0.394700047364822 -0.394699983229918 ... velo:FVY(5,1,:): 0.000000000000000E+000 -6.413490463399427E-009 0.000000000000000E+000 ... velo:FVZ(5,1,:): 6.165346455588860E-008 -0.394700047364822 -0.394699983229918 ...

drjfloyd commented 11 months ago

divg line 546 added: IF (IIG==5) WRITE(,) 'DPK:',IOR,JJG,KKG,DP(IIG,JJG,KKG),B1%AREA_ADJUST,B1%Q_CON_F,B1%RDN,WC%Q_LEAK

DPK: 3 1 1 0.000000000000000E+000 1.00000000000000 10.3518493571633 10.0000000000000 0.000000000000000E+000

There should be no Q_CON_F as the gas and wall temperature should be the same at t=0.

drjfloyd commented 11 months ago

skip that. I forget to set TAU_T = 0.

drjfloyd commented 11 months ago

Fixing TAU_T = 0 the DIV, FVX, etc are now fine. It is looking like something in setting up the pressure solver as the first solution for H gives a veritcal gradient.

rmcdermo commented 11 months ago

Turn off gravity. Things stay put.

drjfloyd commented 11 months ago

It is FVZ:

    FVZ(I,J,K) = 0.25_EB*(VOMX - UOMY) - GZ(I) + RRHO*(GZ(I)*0.5_EB*(RHO_0(K)+RHO_0(K+1)) - VTRM)

RHO_0 is set using TMPA. In the first call to velocity flux VOMX,UOMY, and VTRM are all zero (NOISE=F). This leaves:

     FVZ(I,J,K) =  - GZ(I) + RRHO*(GZ(I)*0.5_EB*(RHO_0(K)+RHO_0(K+1))

or FVZ(I,J,K) = GZ(I) (-1 + RRHO(0.5_EB*(RHO_0(K)+RHO_0(K+1))

RRHO is the gas rho which is 37 C. RHO_0 is 25 C. So RHHO * RHO_0 /= 1

rmcdermo commented 11 months ago

Right. So, this case seems to be behaving as we would expect, no?

drjfloyd commented 11 months ago

It is not intiutive that if you have TMPA=25 but set all the domain boundaries to TMP_EXTERIOR=37 with a RAMP that has T=0,F=1 and INIT the domain to TEMPERATURE=37 that you would expect to see flow.

antoniomaze commented 11 months ago

Thanks, guys for your effort. Could you explain the last message? Are you saying that the velocity field in the model was expected?

mcgratta commented 11 months ago

The gravity force term in the momentum equation is $(\rho - \rho_0) \bf{g}$ where $\rho$ is the density at the given point in space and $\rho_0$ is the background density. The background density is assumed to be related to the ambient temperature via the equation of state. In your case, the ambient temperature is 25 °C, not 37 °C. This example is really not what TMP_EXTERIOR was designed to do. In fact, using the INIT functionality for the entire domain causes these kinds of conflicts.

Maybe it would be better to revisit your original problem. This simplified problem has led us astray. I think the more pressing issue is how you create an indoor environment that is different than the outdoor.

antoniomaze commented 11 months ago

I have created a simplified model of my building using TMP_EXTERIOR and INIT functionality and displayed below the velocities fields (test 3). As we expected the results are not physically correct.

I thought the INITIAL functionality would override the initial condition and I could have two different zones with different temperatures. You have explained to me that this is not the case.

I would expect to see through the holes the behaviour shown in my Test 4 below where I haven't designed the outside space and added some vents at the boundary of the holes with TMP_EXTERIOR=37. Small air movement from the hotter space to the colder space.

Is there any way I can get the same initial conditions, without excluding the outside space from the design?

I have also attached the original study for your info.

test 3 image

test 4 image

LB2_Station-Train_Fire_Nea.txt TestFinal_4.txt TestFinal_3.txt

mcgratta commented 11 months ago

I'll look at Test 3

mcgratta commented 11 months ago

Why don't you set TMPA=37 and use INIT lines to set the interior temperature to 25? You can then use TMP_EXTERIOR=37 at the OPEN doors.

antoniomaze commented 11 months ago

sorry had a busy week at work.

I have tried what you suggested in my main model before posting and it seems that is still not working.

I have run a test (Test 5). Velocities are still a factor of 20 higher than Test 4 and have only one direction (down the holes). I would expect to see the behaviour in Test 4, flow down then up once the air in the proximity of the hole gets hotter with velocities very small.

I have also reported below a screenshot of my original model where you can see the velocity field goes too down after the hole (14 meters from the hole to the nearest obstruction in pink) to be physically correct.

Test 5 image

Original model image

Test5.txt

LB2_Station-Train_Fire_Near_InT37 - Copy.txt

mcgratta commented 11 months ago

The only thing I suggest is that you move the exterior boundary away from the building and then set the inside temperature to 25 C and TMPA=37. If the OPEN boundary is put exactly in the doorway, you cannot expect a perfect flow. Provide some space between the door and the exterior boundary of the computational domain.

antoniomaze commented 11 months ago

Do you mean as my test 5 but with a larger outside space?

On Thu, Oct 19, 2023, 21:24 Kevin McGrattan @.***> wrote:

The only thing I suggest is that you move the exterior boundary away from the building and then set the inside temperature to 25 C and TMPA=37. If the OPEN boundary is put exactly in the doorway, you cannot expect a perfect flow. Provide some space between the door and the exterior boundary of the computational domain.

— Reply to this email directly, view it on GitHub https://github.com/firemodels/fds/issues/12187#issuecomment-1771653603, or unsubscribe https://github.com/notifications/unsubscribe-auth/BDGEYIJJFYWCFHNSUIEUIQTYAGD6FAVCNFSM6AAAAAA54SOBQKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZRGY2TGNRQGM . You are receiving this because you authored the thread.Message ID: @.***>

mcgratta commented 11 months ago

Yes

On Fri, Oct 20, 2023 at 4:03 AM antoniomaze @.***> wrote:

Do you mean as my test 5 but with a larger outside space?

On Thu, Oct 19, 2023, 21:24 Kevin McGrattan @.***> wrote:

The only thing I suggest is that you move the exterior boundary away from the building and then set the inside temperature to 25 C and TMPA=37. If the OPEN boundary is put exactly in the doorway, you cannot expect a perfect flow. Provide some space between the door and the exterior boundary of the computational domain.

— Reply to this email directly, view it on GitHub https://github.com/firemodels/fds/issues/12187#issuecomment-1771653603,

or unsubscribe < https://github.com/notifications/unsubscribe-auth/BDGEYIJJFYWCFHNSUIEUIQTYAGD6FAVCNFSM6AAAAAA54SOBQKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZRGY2TGNRQGM>

. You are receiving this because you authored the thread.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/firemodels/fds/issues/12187#issuecomment-1772269194, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACWPCF7LZG2XCIVXLMJXGYLYAIV4TAVCNFSM6AAAAAA54SOBQKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZSGI3DSMJZGQ . You are receiving this because you modified the open/close state.Message ID: @.***>

antoniomaze commented 11 months ago

thanks. I believe the last one is the better solution.

I have another quick question. Is the below the right device to measure the net smoke flow produced by a fire through an opening?? need to model two different openings layout and see which one can vent more smoke to the outside

&DEVC ID='GAS', QUANTITY='VOLUME FRACTION', SPEC_ID='SOOT', XYZ=0.0,0.0,0.0/

mcgratta commented 11 months ago

No, this is not. First off, SOOT is modeled in FDS as a gaseous component of the combustion PRODUCTS, but in reality it is not a gas but rather particulate. A better way is to do this

&DEVC ID='soot mass flow', QUANTITY='MASS FLUX N', SPEC_ID='SOOT', XB=..., SPATIAL_STATISTIC='AREA INTEGRAL' /

Set XB to be the coordinates of a plane that spans the opening. Set N to either X, Y or Z accordingly. This will output the mass of soot particulate flowing out the vent.

antoniomaze commented 11 months ago

perfect thanks. Your help was very useful.

I have one last question. We are thinking of increasing our modelling capacity by buying new PCs. I wondering if you could advise the minimum characteristics a PC should have to run multiple scenarios in parallel.

drjfloyd commented 11 months ago

Minimum is going to depend on what you want to be able to do.

How many physical cores do you think you need (number of parallel simulations x number of MPI processes per simulation)?

Suggest looking at 2 - 4 Gb per core for RAM.

Running multiple large simulations at once plus old run data means you will need to think about drive space. Look at storage for things you have been running and think about what kind of drive space you will need based on future plans.

You can put a couple intel xeon platinum processors on a dual CPU board and get close to 100 cores but this will be pricey. If you need mulitple computers for the desired number of cores then you will need to make sure your network is fast. Though if your goal is 100s of cores a linux rack server type option may be better than a bunch of PCs.

Another thing to consider is utilization, i.e. on average what fraction of the cores will you keep busy running FDS. If your utilization is going to be low, you might want to limit in-house capability and consider cloud options for those rief periods of high usage (AWS, Sabalcore, CloudHPC, etc.).

antoniomaze commented 11 months ago

for a 50-core PC where I want to run two scenarios assigning for each scenario 20 mesh with a total cell of 10 million per each scenario (which I believe is the maximum we will to need to run in a reasonable amount of time), what would you suggest in terms of ram, processor etc?

drjfloyd commented 11 months ago

For 50 physical cores on a PC, I'd look at mutli-CPU configurations so you have good memory bandwidth. As I said in my prior post suggest 2 - 4 Gb per core. You may want to find a vendor with expertise in designing PCs for scientific computing to help you figure out exactly what your best options are.

antoniomaze commented 8 months ago

Hello again!

I hope it's not an inconvenience to revisit our discussion on PC capacity. We've progressed to the stage of determining the appropriate scale for modelling buildings in one of our Middle East projects. Our simulations will involve scenarios with 30 to 40 million cells, and we're currently evaluating two PC options: a 48-core PC and a 128-core PC (I have attached specs regarding two quotes we have received). We're uncertain about which configuration would be more beneficial for efficiency in our case. I have observed from my modelling experience that increasing the mesh count can potentially slow down the running time. Interestingly, for certain scenarios, reducing the number of meshes and increasing the number of cells might lead to shorter running times. Given this, my question is as follows: If I have to run, for example, a 40 million cells model, would it be faster to run it on the 48-core PC by building 40 meshes and assigning an MPI_PROCESS to each, or on the 128-core PC by dividing the mesh into 120 parts and running it with 120 MPI_PROCESS? I would appreciate your opinion on this matter.

Q54671 - New Top-end MPC (INTEL).pdf Q54676 - New Top-end MPC (AMD).pdf

mcgratta commented 8 months ago

I have never worked with a single computer with this many cores. Our linux cluster has 12 cores per node and 36 nodes. I can run jobs with up to 432 meshes. I typically get the best results using multiple meshes until the cell count per mesh drops below, say, about 10000. But you might see different results because your cores are going to compete for access to the single bank of RAM. On our cluster, the RAM and CPUs are distributed across the nodes. My only advice is to take a typical large job and divide it into multiple meshes until you see an unacceptable degradation in the performance.

marcosvanella commented 8 months ago

Following Kevins comment, I would be careful with high core counts on the AMD chips. I don't have experience with the latest hardware, but I have used an AMD computer in the past (128 cores, years ago) and it was exhibiting substantial speed degradation as you loaded it with larger problems and more MPI processes. Memory speed seemed to be the issue. Maybe someone else can comment on this.

antoniomaze commented 8 months ago

I have never worked with a single computer with this many cores. Our linux cluster has 12 cores per node and 36 nodes. I can run jobs with up to 432 meshes. I typically get the best results using multiple meshes until the cell count per mesh drops below, say, about 10000. But you might see different results because your cores are going to compete for access to the single bank of RAM. On our cluster, the RAM and CPUs are distributed across the nodes. My only advice is to take a typical large job and divide it into multiple meshes until you see an unacceptable degradation in the performance.

Thanks, The rule of thumb of 10000 cells, is something I have experienced as well. Could you please give me an idea of how long would it take for you run a 432 mesh model and how many cells we are talking about?

drjfloyd commented 8 months ago

We have Intel Platinum 8358 for our cluster. 32 physical cores per CPU. At 8 cores being used we start to see memory bandwidth impacting strong scaling. Not enough that there isn't net benefit in using all 32 cores. Not sure that would be the case with 64 cores.

mcgratta commented 8 months ago

The run times on our computer are probably not relevant. The chips are about 10 years old.

antoniomaze commented 8 months ago

Thanks all for your comments. In the end, based on the specs I have attached, would you suggest me to by two 48-core clusters (and run for example my biggest model using both clusters if only one cluster is not fast enough) or you would go for the server cluster option with the 128 cores? considering that what we need is to minimize the running time and buy only the two 48-core clusters or the 128-core one.

An opinion on this would be much appreciated.