Computational Run Time Inquiry - 2 Test Cases

[Craig]

Good day,

I am fairly new to FDS and to posting on this group.  I am a mechanical engineering student tasked to run some basement fire simulations.  If I do not follow exact protocol please do excuse me and feel free to correct me if necessary.

I have attached to text files for two different simulations I have run.  I have used a third party software purely to create the geometric layout for FDS as most of my simulations involve slanted surfaces (I use BLENDER to generate the voxels for the slanted boxes).  In both cases I have some some extracts as well as sprinklers and also some "Layer Height" devices as this is the information which is required.  In TEST_CASE_2 there is also the addition of a single supply into the domain.

In both these test cases the basement volume is fairly large, TEST_CASE_1 having the larger floor area of the two cases.  Also TEST_CASE_1 is slightly larger from floor to soffit (being 3.5m vs 3m for TEST_CASE_2).  However from a computational time perspective, TEST_CASE_2 takes considerably longer to compute (around 56 hours in total vs around 18 hours for TEST_CASE_1).  Both cases are run off the same laptop using only 1 MPI process and using 4 OpenMP threads in both cases.

My question is why are the two computational times so vastly different?  At first I thought it was the mesh size but after playing around with mesh sizes I think I have ruled this out.  Also TEST_CASE_2 has a supply into the domain could this be the reason?? 

Any help would be greatly appreciated!

Thank you for taking the time to read this and for any answers in advance.

[Randy McDermott]

I can't tell from a quick scan.  The HRRPUA and RAMP seem the same.  The VENT area for the fire looks to be larger for case 1, which should lead to higher HRR and I would think possibly smaller DT.  But it is likely that case 2 needs a smaller DT for stability for some reason.  Look at the .out files to confirm this.  Read about CFL in the user and tech guides.

--
You received this message because you are subscribed to the Google Groups "FDS and Smokeview Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fds-smv+unsubscribe@googlegroups.com.
To post to this group, send email to fds...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fds-smv/d7348642-f350-4859-a682-4838dcb25cd0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[dr_jfloyd]

Runtime is a function of the number of cells and the time step size.  In your case the number of cells is similar, so the difference is the time step.  See the discussion on stability constraints in the Technical Reference Guide.

[Craig]

Thank you gentlemen for the speedy responses!

@Randy McDermott - This is precisely why I have been racking my brain.  I have some background in CFD basics (we use ANSYS at my university) which is why the VENT areas are slightly different in order to ensure that the "FIRE" area lies on mesh lines.  It is my understanding that in order to correctly resolve areas of interest (ie. the FIRE and VENTS) that these areas must lie exactly on mesh lines.  I do believe that I have adjusted the HRRPUA to ensure that both fires generate a 4MW fire with the respective change in areas for the two cases.

@Dr_JFloyd - Understood.  I definitely am aware of this and hence my original focus was on the mesh cell sizes within TEST_CASE_2's domain.  Alas the computational time is still very vastly different in the two cases.  I will consult the technical reference guide thank you for that information.  I just find it very confusing that the time step criteria for the two cases to be so very vastly different.  If i can understand this then maybe in future i can prevent such long computational times in a case such as TEST_CASE_2.

Thank you again gentlemen and if there is any more light anyone can shed on this it will be greatly appreciated!

[Randy McDermott]

Try to output a slice of CFL.  This should tell you where the time step restriction is happening.

--

You received this message because you are subscribed to the Google Groups "FDS and Smokeview Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fds-smv+unsubscribe@googlegroups.com.
To post to this group, send email to fds...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fds-smv/d1c1a87f-9325-465a-ba7c-1f18eaff81e6%40googlegroups.com.

[Craig]

Interesting I was not aware that can be done.  Any ideas of where to start placing the slice or should I do it on a trial and error basis?

To unsubscribe from this group and stop receiving emails from it, send an email to fds-smv+u...@googlegroups.com.

To post to this group, send email to fds...@googlegroups.com.

[Randy McDermott]

For a 2D slice you will just have to use some judgment.  Maybe create 3 slices, one in each coordinate plane to start.  If that fails, you can use a 3D slice.

To unsubscribe from this group and stop receiving emails from it, send an email to fds-smv+unsubscribe@googlegroups.com.

To post to this group, send email to fds...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fds-smv/afab0a6d-90d9-40b5-8d5b-f224fdce793e%40googlegroups.com.

[Craig]

Thank you Randy! I will do so and if I come across any findings I will post back onto this post.  Much appreciated I learnt new things today from this post so thank you!

[Salah Benkorichi]

Craig,

In case two. 

DT=5, RESTRICT_TIME_STEP=.FALSE.

Try to remove it and leave it simple as case 1, and see if it improves the timing. 

To unsubscribe from this group and stop receiving emails from it, send an email to fds-smv+unsubscribe@googlegroups.com.

To post to this group, send email to fds...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fds-smv/8e95a7c5-a89d-4ad5-ae35-849a8d45a5d5%40googlegroups.com.

[Craig Roman]

I have tried already with no change. Thanks for responding Salah

--
You received this message because you are subscribed to a topic in the Google Groups "FDS and Smokeview Discussions" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fds-smv/ghaemOC7S6c/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fds-smv+unsubscribe@googlegroups.com.

To post to this group, send email to fds...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fds-smv/CABK0Y1kXsj5dJq1%2BSzLxKY%2B2Eu8u1mOW3JyHyuHqf7BKmWK7BA%40mail.gmail.com.

[Salah Benkorichi]

Craig,

What are the characteristics of your laptop? 

To view this discussion on the web visit https://groups.google.com/d/msgid/fds-smv/CAAF8_BFv%2BPAmyZNe2Lma3iFvH57esnaFajsQhJ6JjyvBxJa7NA%40mail.gmail.com.

[Salah Benkorichi]

How many processors/cores, memory RAM do you have?

[Craig Roman]

Unfortunately I am not at the office now but will post tomorrow with specs. Offhand though Intel i7 2.5GHz (4 cores), solid state drive (not sure of spec) and 32GB RAM (not sure if it's ddr2 or ddr3)

To view this discussion on the web visit https://groups.google.com/d/msgid/fds-smv/CABK0Y1kBstTRFLJNCpsf0w2B4A0z5-aJGT7GZ5%2BLoC6jGK8hQg%40mail.gmail.com.

[Salah Benkorichi]

I think the differences in timing lies in with your meshes. Since, you're not using mpirun, then that's why you got that delay in between for case2. I've made two tests for demonstration, test1 with one single mesh, while test2 I divided it to 4 meshes, while keeping the same cell numbers. I set simulation time to 300 s only. Test 1 ends up after 6 mins, while test 2 ends up after 12 mins. Surely, if I increased the simulation time, the gap would increase.

What I would suggest, is you try to redo your meshes, and try to use only one whole mesh (Try to keep the same cell numbers) for CASE 2. Run it and see the how much it takes. 

Report back how it goes.

Regards,

Salah

To view this discussion on the web visit https://groups.google.com/d/msgid/fds-smv/CAAF8_BFbXqu9CYw2%3DY%3Da%2B7S7yvx%2BqysffWNup8VHYAyJY5U0tQ%40mail.gmail.com.

[Craig Roman]

Hi Salah, truth is in fact that I only had one mesh originally and that is when I tried splitting it into more meshes thinking it would help. The one I sent you was my second iteration which split the mesh. I thought perhaps one big mesh with more obstructions was perhaps inefficient.

To view this discussion on the web visit https://groups.google.com/d/msgid/fds-smv/CABK0Y1n32e-UFJLd7g9nU%3DrzKxVSKS6rqsSoW916Bvhr0TuveQ%40mail.gmail.com.

[Salah Benkorichi]

So even with setting one mesh the timing was 56h ?

To view this discussion on the web visit https://groups.google.com/d/msgid/fds-smv/CAAF8_BG0o9TxXhJp6Gf0vUfP%3DQm4eQtTRtVHCDQsSZnSQ%2BM00w%40mail.gmail.com.

[Craig Roman]

Indeed that was the best I could get it to simulate. Original mesh had a 0.5m x 0.5m x 0.3m mesh. Constrained in the z-direction for a minimum of ten mesh cells from floor to soft. Original simulation time for this mesh I estimated at around 140 hours. Immediately stopped it and adjusted the mesh to 0.8m x 0.8m x 0.3m pushing the aspect ratio to 2.7 but that is how I achieved the 56 hour simulation time.

To view this discussion on the web visit https://groups.google.com/d/msgid/fds-smv/CABK0Y1n%3DMg2%3DyQy3GOh%3D85g6zcRh1aYxtnoHQ9upL6UTSbseZA%40mail.gmail.com.

[Craig Roman]

Good day Sarah,

Please excuse my spelling error in my last response it should read that the constraint in the z-direction is at least 10 mesh cells from "floor to soffit".

I have confirmed the laptop specs to be as I described in one of the previous replies.

Just to give you an idea of what I have already tried, firstly I figured controlling the time step would be a good start.  Realised that a DT=5 is extremely large (Was my goal per 100 time steps) but learnt that if the DT is too large FDS automatically corrects this. Then I changed DT=0.05 and saw that it matched my time step for a few time steps and then readjusted once more back to normal. So I added the RESTRICT_TIME_STEP=.FALSE. into the time line. This had no observed effect. Next I added the LOCK_TIME_STEP=.TRUE. into the time line. This worked in controlling the time step but I hit numerical instability every test run around just over 1000 time steps. So I decided controlling the time step is not a great idea.

Next I moved onto the mesh which I explained in my previous reply.  Hope this helps and I hope to hear from you again.

Once again, thank you for your assistance and taking the time out to have a look at my query.

[Craig Roman]

Please excuse the auto-correct Salah it should not read Sarah as in the previous post

[Salah Benkorichi]

Craig,

One experiment I would recommend you do is try to reduce the number of the OBST, you've got more than 10000 lines. Try to reduce it to around 4000-5000 lines. You can do it through reducing the voxel numbers ( this done by increasing the ratio in blender). Try also to use regular cubes when it's necessary rather than voxel type in order to avoid extra unnecessary lines.  

I tried to remove the OBST, and I can see a big difference between the two.

Try it and report what you get.

Cheers,

Salah

To view this discussion on the web visit https://groups.google.com/d/msgid/fds-smv/CAAF8_BE5cZS_kzxsVJivfa8fegOmA_brPFpUy6LUWsZhwuXoyQ%40mail.gmail.com.

[Craig Roman]

Will do my best and report back! Thank you Salah 

To view this discussion on the web visit https://groups.google.com/d/msgid/fds-smv/CABK0Y1mjiu%3D4N74vsqfrzxOAsQjjMbnF2%2BOCgF%3DTnrUSwsOH-w%40mail.gmail.com.

[Craig Roman]

Hi Salah,

I believe the problem is found. Ok I have not run the entire simulation (pressed for time as another project has taken presidence over the project I queried) however on initial calculations I estimate about 63 hours to simulate. This is on the smaller mesh (0.5m x 0.5m x 0.3m mesh). I only let it run for the first 1000 time steps however but when I get a chance to run it properly I shall update.

Essentially I changed the resolution of the voxels and got the number of lines of code down to around 2600 lines.  So I think you are right and the trouble could stem from all the obstructions the simulation was originally taking into account.

[Salah Benkorichi]

Ok, great, I would expect it to be around/less than CASE1. Dont put       DT=5, RESTRICT_TIME_STEP=.FALSE., just leave it as CASE 1

We'll see how it goes.

To view this discussion on the web visit https://groups.google.com/d/msgid/fds-smv/CAAF8_BHJ6UbOD7K7hVbRZ8qqRJbwW1drrwZfOSFa9LDoqBMDhg%40mail.gmail.com.

[Craig Roman]

I will do. When I get the opportunity to rerun it I will do so with the larger mesh (0.8m x 0.8m x 0.3m) in order to compare with case 1 and will update my findings!

Once again thank you very much for the help you have been awesome!

To view this discussion on the web visit https://groups.google.com/d/msgid/fds-smv/CABK0Y1nxX9jqmik30%3D1YF-th%3Dg4M%3DYCZv97GxOsu8hVsC%2BuK-w%40mail.gmail.com.