HVAC applied to GEOM

[rmcdermo]

As the title indicates, I am working on a complex geometry case and need to be able to apply HVAC to a suction and discharge of a fan. In the user guide we still say this,

"No VENT implies HVAC cannot be applied to a GEOM surface. This is on our priority list and will be
available in the future."

I do not see any examples in either HVAC or Complex_Geometry, so I assume this is still the case. Let's discuss, as this is now a high priority. Thanks

[drjfloyd]

hvac.f90 has logic for getting the boundary condition for a CFACE (CFACE has a NODE_INDEX). In wall HVAC just uses existing specified mass flux routines for setting the wall condition so CFACE should be good there as well.

All the setup logic in HVAC is tied to VENTs. If VENTs aren't something that can be done with CFACE, then we will need to think of something else. CFACE now takes SURF_ID which could be HVAC but we would need some other input to ID the node.

[marcosvanella]

We can bring in the VENT information with the GEOM line in similar manner as what we do with SURF, that is, a list of VENTS attached to the geometry and then an index to this list for each triangle associated with the VENT. That information can be inherited by CFACEs once they are computed.

[rmcdermo]

To me it seems the simplest thing would be to link VENT and SURF (sort of the reverse of what we usually do). I don't want to add more to GEOM input, that would mean all the preprocessors have to change.

[rmcdermo]

Or, would it be possible to simply give an HVAC_ID to a SURF line?

[marcosvanella]

To me it seems the simplest thing would be to link VENT and SURF (sort of the reverse of what we usually do). I don't want to add more to GEOM input, that would mean all the preprocessors have to change.

That's an issue, now we have 4 indices per triangle, the 3 node indices and an index to the SURF_ID list. Using the GEOM line we'd need the extra index for VENTs.

[johodges]

Could we add two parameters GEOM_ID and FACE_ID to VENT which get processed after GEOMs are processed? The code could then over-write the stored surface definition on the geom/cface.

[drjfloyd]

@rmcdermo that is not a bad idea.

Right now SURF_ID='HVAC' is a predefined SURF used by VENT that denotes the VENT is connected to the HVAC system. There is code in a number of places tied to the use of a special surface and boundary type for just HVAC that I would not want to have to redo. One option along the lines of your suggestion would be to have NODE_ID on SURF (I would want that so we have consistent inputs across namelists). The input for a SURF would then become:

&SURF ID='MY SURF ID',NODE_ID='MY NODE ID'/

Then when we go to process GEOM inputs, if NODE_ID is set we would actually assign the HVAC SURF_INDEX to those triangles. We would need NODE_INDEX in the CFACE type. That would get set by just looking up the NODE_ID in the list of NODE (which we would alreayd have at that point). We could have some logic to throw an error if the NODE_ID is an internal node (more than one duct).

For HVAC we could make it so that VENT_ID='GEOM' lets FDS know that a NODE is connected to GEOM and not to try searching the VENT IDs.

One potential hitch is right now you can only have one VENT assigned to a NODE. With GEOM to get a square VENT you would need more than one triangle with the SURF_ID. That in itself if fine for getting the gas boundary conditions, but it means that users could assign that SURF_ID to disconnected GEOM triangles all over the domain. We do have checks now for VENT that don't allow a VENT to cross PRESSURE_ZONES. We could do the same for GEOM; however, that wouldn't catch lots of disconnected GEOM using the same SURF_ID in the same ZONE. HVAC should still work in that case, but you might get some odd behavior.

[rmcdermo]

@drjfloyd I like your plan. As for the potential hiccup of disconnected CFACES, for the immediate application all the CFACES are connected.