HT3D with multiple meshes

[tgob]

Running FDS 6.8.0-886e009 release on Windows 11 and in Linux.

The examples ht3d-sphere_48.fds and 96 have issues with temperature across mesh boundaries that are visible in SmokeView and _prof-1.csv. These problems are resolved by reverting to a single mesh. Varying NEIGHBOR_SEPARATION_DISTANCE in &MISC doesn't resolve the problem.

ht3d-sphere_96.fds also produces multiple IOR warnings associated with objects in every mesh.

ht3d_network also has issues across the mesh boundary, but this is resolved by incorporating the variable NEIGHBOR_SEPARATION_DISTANCE in &MISC.

[mcgratta]

This feature has been in beta testing, and we've fixed a number of bugs since April. Install the latest nightly build and check your cases again. Note that the input files have probably also changed.

[tgob]

Thank you for your response Kevin. I appreciate that ht3d is still in testing, and my interest in this is entirely academic.

My professional work requires a verified installation of the ‘current release’ (18 April 23), if for no other reason than conformity with regulators and peer reviewers.

When I installed a nightly build just a few days ago I was somewhat concerned with the command fds reporting ‘MPI not initialized’. Hence I reverted to current release.

I’ll experiment with htd3 further as time allows.

With kindest regards, Tim

From: Kevin McGrattan @.*** Sent: Wednesday, 3 January 2024 3:18 AM To: firemodels/fds Cc: tgob; Author Subject: Re: [firemodels/fds] HT3D with multiple meshes (Issue #12320)

This feature has been in beta testing, and we've fixed a number of bugs since April. Install the latest nightly build and check your cases again. Note that the input files have probably also changed.

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

[mcgratta]

The message that MPI is not initialized simply means that FDS has printed out version info and stopped before any MPI initialization calls are done. It is not an error message.

[tgob]

Thank you again for your previous response Kevin.

On ‘MPI not initialized’

From a users perspective this is an FDS terminal output change that was inconsistent with previous official releases, including the 6.8.0 official release, and doesn’t seem to be documented. My IB fabric took a lot of effort to install and tune and I was concerned that it wasn’t initializing when there were no apparent hardware or non-FDS software fault.

I have installed a recent nightly build and re-run the ht3d_sphere example heat transfer models.

Yes, the models have changed.

In ht3d_sphere_48.fds HEAT_TRANSFER_COEFFICIENT_BACK = 100000 has been removed from &SURF. Both HEAT_TRANSFER_COEFFICIENT parameters are not applicable to this model because it is run under SOLID_PHASE_ONLY=T. AS expected there is no change in model performance if these parameters are removed.

In ht3d_sphere_96.fds NEIGBOUR_SEPARATION_DISTANCE=10 has been removed from &MISC, and HEAT_TRANSFER_COEFFICIENT_BACK = 100000 has been removed from &SURF. Again, the HEAT_TRANSFER_COEFFICIENT parameters are not applicable to this model because it is run under SOLID_PHASE_ONLY=T.

ht3d_sphere_48.fds seems to have been fixed, but there is still a mesh boundary issue with ht3d_sphere_96.fds under the nightly fds build. It still appears to be associated with mesh boundaries because if I run the model in a single mesh, the temperature anomalies at internal mesh boundaries do not appear (either in SmokeView or in the PROF.csv output). Attached are three .jpg images from SmokeView that show the problem and the single mesh solution.

I have taken one of my old ht3d models that used to work under FDS 6.7.7 and, despite syntax adjustments for the nightly build, it no longer performs as expected. The model was originally a heat sink study for a T0220 transistor package dissipating 1 W in the Silicon die.

I simplified the model to try and identify the problem. The Si chip (chip.fds) is still working as an ht3d heat source although the heat flow field doesn’t have appropriate symmetry under SmokeView. But when the ht3d tab is added to the model (chip1.fds) the interface between the Si chip and the tab is acting as a heat sink! This results in temperatures below ambient (a physical impossibility). It appears as though the heat flow is reversing at the interface between the two ht3d solids?

I have experimented with a number of parameters including WALL_INCREMENT in &TIME, and both SIMULATION_MODE and NEIGBOUR_SEPARATION_DISTANCE in &MISC without resolving the problem. I also tried reorientation the model and mirroring in X and Y, again, without resolving the problem.

I’m not at all concerned about the performance of my TO220 model or the ht3d_spheres (relatively simple analytical heat transfer problems) but I am interested in a robust ht3d solution in FDS for situations that cannot be readily resolved analytically.

As an aside I rather enjoyed your recent post regarding 1.21 GW power for a flux capacitor. Apparently there is some discrepancy over the units (JilliWatts) and the usual metric/imperial conversions that result in a French eqivillant of 2.21 JW.

With kindest regards,

Tim

From: Kevin McGrattan @.*** Sent: Thursday, 4 January 2024 4:00 AM To: firemodels/fds Cc: tgob; Author Subject: Re: [firemodels/fds] HT3D with multiple meshes (Issue #12320)

The message that MPI is not initialized simply means that FDS has printed out version info and stopped before any MPI initialization calls are done. It is not an error message.

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

[mcgratta]

I removed the line saying "MPI not initialized". If you type "fds" in future with no input file, you will just get version info.

As far as the HT3D stuff, various parameters have changed. NEIGHBOR_SEPARATION_DISTANCE is no longer required because FDS figures out the extent of the 3D solids and establishes the proper communication protocols. Some of the "BACK" parameters on the SURF line are no longer needed as well.

Post the input file of a case that you believe to be not working properly and I'll fix it.

As for 1.21 GW, this is a reference to the move "Back to the Future," it being the power required to transport one back in time.

[tgob]

Here are the attachments that for some reason didn't transfer with my email. The ht3d_sphere_96.fds file is in Examples/Heat _Transfer. With kindest regards, Tim chip.txt chip1.txt

[mcgratta]

Glenn -- can you think of a reason why the interior temperature of the sphere is not shown for meshes that are completely within the sphere? It might be something in Smokeview or FDS. The problem only appears when the mesh is completely embedded in the solid.

[mcgratta]

There is definitely something wrong with the chip case. I'll fix.

[gforney]

Slice file? Ill take a look

On Fri, Jan 5, 2024, 4:44 PM Kevin McGrattan @.***> wrote:

Glenn -- can you think of a reason why the interior temperature of the sphere is not shown for meshes that are completely within the sphere? It might be something in Smokeview or FDS. The problem only appears when the mesh is completely embedded in the solid.

— Reply to this email directly, view it on GitHub https://github.com/firemodels/fds/issues/12320#issuecomment-1879291044, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC6UCRWNDAHUQZNKQV63GFTYNBX4RAVCNFSM6AAAAABBJZJUP6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZZGI4TCMBUGQ . You are receiving this because you were assigned.Message ID: @.***>

[gforney]

Should have looked at the issue first. Nevermind, see that you are talking about slices

On Fri, Jan 5, 2024, 4:44 PM Kevin McGrattan @.***> wrote:

Glenn -- can you think of a reason why the interior temperature of the sphere is not shown for meshes that are completely within the sphere? It might be something in Smokeview or FDS. The problem only appears when the mesh is completely embedded in the solid.

— Reply to this email directly, view it on GitHub https://github.com/firemodels/fds/issues/12320#issuecomment-1879291044, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC6UCRWNDAHUQZNKQV63GFTYNBX4RAVCNFSM6AAAAABBJZJUP6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZZGI4TCMBUGQ . You are receiving this because you were assigned.Message ID: @.***>

[gforney]

I modified ht3d_sphere_96.fds by reducing size of each grid to 6x6x6 so it would run faster on my laptop. attached image shows values at each grid cell for a slice going through center of the sphere. values shown in meshes interior to sphere are 20 C. smokeview doesn't modify values. though it is certainly possible there is a bug in smokeview think it is more likely that values smokeview is reading in are 20 C for these meshes these interior meshes. to show values in a slice mesh open settings tab of slice bounds dialog box and check "values" for the solid portion of the slice file (or gas if you want to see values in that regionk)

[gforney]

I'll check though slice values right when they are read in

On Fri, Jan 5, 2024, 10:21 PM gforney @.***> wrote:

I modified ht3d_sphere_96.fds by reducing size of each grid to 6x6x6 so it would run faster on my laptop. attached image shows values at each grid cell for a slice going through center of the sphere. values shown in meshes interior to sphere are 20 C. smokeview doesn't modify values. though it is certainly possible there is a bug in smokeview think it is more likely that values smokeview is reading in are 20 C for these meshes these interior meshes. to show values in a slice mesh open settings tab of slice bounds dialog box and check "values" for the solid portion of the slice file (or gas if you want to see values in that regionk) test_0216.png (view on web) https://github.com/firemodels/fds/assets/12403014/83964e0c-5dc5-4634-aa44-09bdad130ae5

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

[tgob]

Do let me know if there is anything I can do to help resolving these issues. I have an fds dedicated Linux cluster and Windows 11 platform at your disposal.

t.

From: gforney @.*** Sent: Saturday, 6 January 2024 4:52 PM To: firemodels/fds Cc: tgob; Author Subject: Re: [firemodels/fds] HT3D with multiple meshes (Issue #12320)

I'll check though slice values right when they are read in

On Fri, Jan 5, 2024, 10:21 PM gforney @.***> wrote:

I modified ht3d_sphere_96.fds by reducing size of each grid to 6x6x6 so it would run faster on my laptop. attached image shows values at each grid cell for a slice going through center of the sphere. values shown in meshes interior to sphere are 20 C. smokeview doesn't modify values. though it is certainly possible there is a bug in smokeview think it is more likely that values smokeview is reading in are 20 C for these meshes these interior meshes. to show values in a slice mesh open settings tab of slice bounds dialog box and check "values" for the solid portion of the slice file (or gas if you want to see values in that regionk) test_0216.png (view on web) https://github.com/firemodels/fds/assets/12403014/83964e0c-5dc5-4634-aa44-09bdad130ae5

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

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

[mcgratta]

The issue of the slice file is caused by FDS, not Smokeview. I'll fix.

[mcgratta]

If you are able to update the fds repository and recompile, you can check the issues related to the Si and Cu obstructions that are abutting. The problem in this case is that the MATL_ID for CU and SI should be listed on the OBST lines, not the SURF lines. FDS cannot figure out which OBST get which MATL, and that is why things are all messed up. So put the MATL_ID on the OBST lines and remove from the SURF lines and see if things work better.

The issue of the big blue square in the sphere case is not fixed. The problem here is that these inner meshes are not explicitly processed, and therefore their temperature field is not updated. The 3D solid solver works within these meshes, but the solid temperatures are not being transferred to the gas phase TMP array, from which the slice (SLCF) file is created.

[tgob]

Thank you Kevin.

I downloaded the latest Windows nightly bundle just a short time ago:

Current Date : January 9, 2024 09:40:39

Revision : FDS-6.8.0-1155-gb99fe1e-nightly

Revision Date : Fri Jan 5 16:22:58 2024 -0500

Compiler : Intel ifort 2021.9.0

Compilation Date : Mon 01/08/2024 08:37 AM

I moved the MATL_ID’s to the &OBST in both chip.fds and chip1.fds.

The chip model is now getting colder than ambient temperature?

The chip and tab model (chip1) is getting cold at the back of the tab and hot near the top of the tab. While the boundary temperature doesn’t make sense, it is symmetric.

With kindest regards,

Tim

From: Kevin McGrattan @.*** Sent: Tuesday, 9 January 2024 8:27 AM To: firemodels/fds Cc: tgob; Author Subject: Re: [firemodels/fds] HT3D with multiple meshes (Issue #12320)

If you are able to update the fds repository and recompile, you can check the issues related to the Si and Cu obstructions that are abutting. The problem in this case is that the MATL_ID for CU and SI should be listed on the OBST lines, not the SURF lines. FDS cannot figure out which OBST get which MATL, and that is why things are all messed up. So put the MATL_ID on the OBST lines and remove from the SURF lines and see if things work better.

The issue of the big blue square in the sphere case is not fixed. The problem here is that these inner meshes are not explicitly processed, and therefore their temperature field is not updated. The 3D solid solver works within these meshes, but the solid temperatures are not being transferred to the gas phase TMP array, from which the slice (SLCF) file is created.

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

[mcgratta]

No, you misunderstood me. This change has not been incorporated in a nightly bundle. The source code has changed. You would have to update your git repo and recompile.

[tgob]

Thank you Kevin. My mistake. I’ll try again later today. t.

From: Kevin McGrattan @.*** Sent: Tuesday, 9 January 2024 11:10 AM To: firemodels/fds Cc: tgob; Author Subject: Re: [firemodels/fds] HT3D with multiple meshes (Issue #12320)

No, you misunderstood me. This change has not been incorporated in a nightly bundle. The source code has changed. You would have to update your git repo and recompile.

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

[tgob]

Both cases are now working beautifully with the anticipated smooth heat flow wave fronts.

With kindest regards,

Tim

From: Kevin McGrattan @.*** Sent: Tuesday, 9 January 2024 11:10 AM To: firemodels/fds Cc: tgob; Author Subject: Re: [firemodels/fds] HT3D with multiple meshes (Issue #12320)

No, you misunderstood me. This change has not been incorporated in a nightly bundle. The source code has changed. You would have to update your git repo and recompile.

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

[tgob]

Dear Kevin,

with the simple cases working I continued to introduce the original obstructions to rebuild my TO220 transistor package and heat sink.

Further problems started to occur. Simulation times started to become excessive and I began to experience consistent sigsegv 174 errors, even when running on a single node.

With the chip heat source encapsulated in another ht3d solid it stopped acting as a heat source?

I haven’t had a problem with sigsegv errors for years. The hardware and Infiniband have been tested without issue.

I’ll send through the additional development models shortly with a full description of the issues for your consideration.

With kindest regards,

Tim

From: Tim O'Brien @.*** Sent: Tuesday, 9 January 2024 5:11 PM To: 'firemodels/fds' Subject: RE: [firemodels/fds] HT3D with multiple meshes (Issue #12320)

Both cases are now working beautifully with the anticipated smooth heat flow wave fronts.

With kindest regards,

Tim

From: Kevin McGrattan @.*** Sent: Tuesday, 9 January 2024 11:10 AM To: firemodels/fds Cc: tgob; Author Subject: Re: [firemodels/fds] HT3D with multiple meshes (Issue #12320)

No, you misunderstood me. This change has not been incorporated in a nightly bundle. The source code has changed. You would have to update your git repo and recompile.

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

[tgob]

Here are two further ht3d test cases for your consideration Kevin.

chip2.txt is with the previous chip1.txt heated die partially enclosed. This works as expected as an ht3d model.

chip3.txt is with the hot chip fully enclosed. The model runs but now nothing gets hot.

I believe that I have found the cause of the sigsegv 174 error - two ht3d obstructions with a minor overlap.

chip2.txt chip3.txt

[mcgratta]

Good one. I have to add a way to get the internal heat source onto the OBST without using SURF, because in this case, the SURF is not invoked. There are a number of other parameters on SURF that need to be conveyed directly to the OBST.

[tgob]

Thank you for your explanation Kevin.

While your eventual solution will undoubtedly be based on ease and efficiency of coding my preference would be to incorporate this as a material property if, for no other reason, than to reduce model syntax.

On the sigsegv 174 error, would you consider incorporation an obstruction passer to identify overlapping ht3d obstructions during model initialization? A common error (particularly when using 3rd party tools such as PyroSim) is inadvertent overlaps.

[mcgratta]

There are other SURF parameters that will need to be replicated by OBST, most having to do with how the nodes are set up. Adding these to the MATL line would inevitably cause confusion. Plus, we want MATL lines to just have physical properties, as opposed to mesh and geometry information. We want MATL lines to be somewhat scenario independent. We often keep MATL lines in separate files and invoke them using the CATF feature. Thus, we don't want to tangle up MATL with 3D or meshing parameters.

As for over-lapping HT3D OBSTs, that should be easy to flag.

[mcgratta]

Look at the files committed in PR #12377. It is a shortened version of chip3.fds that verifies that the energy generated internally is matched by heat loss to the surface after a few minutes. Update your repo and recompile the code to the run the case.

[tgob]

Thank you so much for your efforts on this Kevin.

All of my development files are working now. While have haven’t yet analyzed the results for my completed TO220 transistor package, the heat flow and temperatures are about right when compared to experimental measurements and datasheet bulk thermal parameters.

I have yet to incorporate mesh splitting in the model – maybe tonight? If there are any problems I’ll report back.

With kindest regards,

Tim

From: Kevin McGrattan @.*** Sent: Tuesday, 16 January 2024 8:26 AM To: firemodels/fds Cc: tgob; Author Subject: Re: [firemodels/fds] HT3D with multiple meshes (Issue #12320)

Look at the files committed in PR #12377 https://github.com/firemodels/fds/pull/12377 . It is a shortened version of chip3.fds that verifies that the energy generated internally is matched by heat loss to the surface after a few minutes. Update your repo and recompile the code to the run the case.

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

[mcgratta]

I split the mesh to make the case run fast, because it is now a verification case. Also, the HEAT_TRANSFER_COEFFICIENT is probably too high. I just set it high to run the case to steady state faster. If you are not using SOLID_PHASE_ONLY, FDS will compute the HTC from the gas phase solver.

[tgob]

Thanks Kevin. Yes, convection is important in my model which is looking at the efficiency of some TO220 package heat sink designs (a comparative study).

As an aside, have you considered adding the capability of incorporating a thermal contact resistance between adjoining solid surfaces?

With kindest regards,

Tim

From: Kevin McGrattan @.*** Sent: Wednesday, 17 January 2024 1:59 AM To: firemodels/fds Cc: tgob; Author Subject: Re: [firemodels/fds] HT3D with multiple meshes (Issue #12320)

I split the mesh to make the case run fast, because it is now a verification case. Also, the HEAT_TRANSFER_COEFFICIENT is probably too high. I just set it high to run the case to steady state faster. If you are not using SOLID_PHASE_ONLY, FDS will compute the HTC from the gas phase solver.

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

[mcgratta]

No, but if you point me to a simple model of it, I'll take a look.

[tgob]

It appears as though something untoward is still happening with HT3D on slices through solids. I suspect (on the basis of air velocity and temperature which is intuitively correct) that this problem is with SmokeView, or the solid slice information passed from FDS to SmokeView.

The boundary temperatures appear to be correct.

I have simplified my model so that the problem can be readily replicated without excessive run time. It is attached as HotSlab.txt.

The model runs to completion. The two attached images show the boundary temperature and a temperature slice through an internally heated thermally conductive slab. The material properties are representative of aluminium with a heat source of about 5 W.

The slice temperature shows a gridded profile n X, Y and Z within the internally heated slab. With values displayed in SmokeView the cold regions remain at 0°C.

FDS and SmokeView versions are:

Fire Dynamics Simulator Current Date : February 2, 2024 23:40:44 Revision : FDS-6.8.0-1246-g1978323-master Revision Date : Mon Jan 15 14:22:44 2024 -0500 Compiler : ifort version 2021.5.0 Compilation Date : Jan 16, 2024 13:44:35

Smokeview - Jan 8 2024 Revision : SMV-6.8.0-1743-gdf5fa68-nightly Revision Date : Fri Dec 29 12:57:43 2023 -0500 Compilation Date : Jan 8 2024 08:47:18

With kindest regards,

Tim

HotSlab.txt

[mcgratta]

Add CELL_SIZE=0.0015 to the SURF line. This is something that probably needs some attention. The current default is to use the same noding strategy near the surface like we do for 1-D heat transfer. That means that the nodes stretch out in depth, which can lead to interior cells not being covered. The heat transfer is still OK, but some cells may not be assigned a temperature. I think the thing to do for 3-D is to not allow stretching that would cause an interior cell not to be assigned a color.

[tgob]

Thank you Kevin. Reducing the CELL_SIZE to 0.0015 mm worked but there is a significant increase in the computational burden. I haven’t measured this but it’s at least an order of magnitude, and probably 2^4.

It’s been many years since I last wrote a solid iterative conduction program for multiple materials with convective and radiation boundary conditions. The maths is relatively straight forward, but increasingly tedious with increased resolution. Sub-optimal grids must surely compound the computational burden.

There are many aspects of FDS that I would like to experiment with but, despite your excellent user and technical documentation, the source code is largely a mystery to me and my efforts with Fortran are circa 1970. While I have ‘played’ with the FDS source code in the past the results were appropriately labeled ‘dirty’, and nothing worthy of contribution. The best I can do is report issues and let you NIST gurus work your magic.

With kindest regards, t.

From: Kevin McGrattan @.*** Sent: Saturday, 3 February 2024 3:17 AM To: firemodels/fds Cc: tgob; Author Subject: Re: [firemodels/fds] HT3D with multiple meshes (Issue #12320)

Add CELL_SIZE=0.0015 to the SURF line. This is something that probably needs some attention. The current default is to use the same noding strategy near the surface like we do for 1-D heat transfer. That means that the nodes stretch out in depth, which can lead to interior cells not being covered. The heat transfer is still OK, but some cells may not be assigned a temperature. I think the thing to do for 3-D is to not allow stretching that would cause an interior cell not to be assigned a color.

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

[mcgratta]

This is the trade off. For most FDS use cases, we are mainly concerned about heat penetration near the surface, and so we cluster internal cells there and stretch the others that are farther away. When you set CELL_SIZE, you are asking for uniform cells throughout. In your case, I suspect that this is appropriate, but it costs more. You could investigate the use of STRETCH_FACTOR between 1 and 2. The default is 2, which means that each internal cell doubles in size in depth. Try 1.5 and see if it helps rid you of the blank spots.

As for "dirty", that is merely git telling you that the version of the source code that you "touched" has not been committed. When we are doing our day to day work, we are working with dirty code. When we are happy, we commit it and then it gets an actual hash and is permanently archived.

[rmcdermo]

For HT3D, I would start with the simple strategy that each 3D cell gets a 1D node. Then worry about stretching the surface grid cell. I would like to avoid the need for CELL_SIZE.

[mcgratta]

At the moment, HT3D will work like the default 1D solver because I think many will use the 3D option on materials that are somewhere between highly insulating (i.e. building materials) and highly conducting (i.e. metals). Using the default 1D stretching approach ensures that steep thermal gradients are captured even if the gas phase grid is coarse. For cases like the one described in this thread, the CELL_SIZE setting is appropriate and easy to set. I don't want to get rid of it entirely, no matter what we decide on for a default.

[drjfloyd]

I think there will ultimately be a large interest in using HT3D for pyrolysis where materials are going to be largely insulative. .

[rmcdermo]

The surface cells need the stretching to capture high heat flux gradients. Generally, the internal cells are well enough resolved (with the caveat that someone, maybe Tim, mentioned, that we should probably add a contact resistance between layers). The implicit time stepping makes the rest of the scheme fast for the 3D geometry at the MESH resolution.

I don't think setting CELL_SIZE is very easy when geometries get read in from CAD models. If it is easy, we should set it automatically with an option for a user over-ride. But I suspect we would still need some strategy for filling in cells that get lost (skipped) in the normal 1D stretch. I don't understand why we need to maintain the stretch beyond the first surface cell.

[mcgratta]

I'm going to close this issue and restart another if more HT3D questions arise.