HB PMV Comfort Map - Accepting CFD Inputs For Air Speed

[victorbrac]

@chris -

Is it currently possible to read in CFD results to inform air speed input in PMV comfort map? If not, what is your take on this?

I see “air speed” is currently flagged as a “single number” input.

Best,
Victor

[chris]

It’s not too difficult to do this since we already do it for the UTCI mapping recipe:

UTCI. Accounting for both external glazing and point-by-point wind speeds

Ok, I just merged a version of the component that can accept a folder of air speed values that align with the sensors. After you run the Versioner and restart Rhino, you’ll see that you can plug the folder into the _wind_speed_ input of the recipe: [image] … and this is what the folder should look like in relation to the model sensor grids: [image] [image] It looks like the Edddy team did a good job making it easy to run OpenFOAM simulations when the meshing isn’t complex and everything …

But no one had asked for it with PMV until now.

If you confirm that you can test it and you have a project where you’ve run CFD simulations to get a matrix of hourly air speeds for each sensor, then I’ll try to add this as soon as I get the chance.

[nasrollah]

Hi,
This is what I am looking for. However, I am not familiar with CFD. I like to integrate CFD with energy and thermal comfort to consider natural ventilation’s impact on both of these objectives in my project. Is there any example file or article showing step-by-step stages to read and follow?

[victorbrac]

That’s where I got the idea.

Yes, I have CFD models in which I can extract air speed results to test updated PMV mapping recipe.

Do you think it makes sense to allow for similar option to overwrite dry bulb temp at each sensor as well i.e. to allow import of air temp gradient you’ll get from CFD result?

[chris]

@victorbrac

Yes, I have CFD models in which I can extract air speed results to test updated PMV mapping recipe.

That’s great and I’ll try to add this soon if I get the chance. Can I ask how you are extrapolating the point-in-time CFD results into hourly values for the comfort maps? I know for the UTCI comfort maps, we typically had to run multiple CFD simulations from different directions and then relate those to the hourly EPW wind speeds and directions.

For this indoor case, are you assuming that all air speed is driven by a mechanical system that is constantly running? And it’s always supplying air at the same temperature so that the air circulation pattern is always the same and you effectively have the same air speeds everywhere all of the time? Are you worried about the circulation pattern changing depending on whether a heating or cooling system is active?

Or are you primarily trying to show the effect of something larger like ceiling fans, which could be turned on or off and will probably dominate the air circulation when they are on?

I’m asking because it would be good to write some best practices for this into the description of the new input that I add.

@victorbrac

Do you think it makes sense to allow for similar option to overwrite dry bulb temp at each sensor as well

That seems a little more ambiguous in terms of how to use it correctly because the average air temperature of the room is typically changing on an hourly basis depending on the heat gains and losses. And I am sure that any stratification pattern varies even more than the average air temperature. Maybe we could eventually expose something that lets your specify how the air temperature at a sensor differs from the average room air temperature but I still would worry that an input like that might not be used correctly and could give people a false sense of accuracy.

[victorbrac]

@chris

That’s great and I’ll try to add this soon if I get the chance. Can I ask how you are extrapolating the point-in-time CFD results into hourly values for the comfort maps? I know for the UTCI comfort maps, we typically had to run multiple CFD simulations from different directions and then relate those to the hourly EPW wind speeds and directions.

For this indoor case, are you assuming that all air speed is driven by a mechanical system that is constantly running? And it’s always supplying air at the same temperature so that the air circulation pattern is always the same and you effectively have the same air speeds everywhere all of the time? Are you worried about the circulation pattern changing depending on whether a heating or cooling system is active?

Or are you primarily trying to show the effect of something larger like ceiling fans, which could be turned on or off and will probably dominate the air circulation when they are on?

I’m asking because it would be good to write some best practices for this into the description of the new input that I add.

Good questions! I’ve read your paper on UTCI, thanks for publishing this.

You’re right, users should be careful taking steady state, point in time CFD analysis results and applying across 8760 energy model. In the most accurate sense, CFD results should be applied to the same energy model scenario that was used to set the CFD boundary conditions.

My assumption is that you’re testing a design case and not trying to create full year hourly profile of airspeeds and air temperatures from CFD results. Therefore, the HVAC system is on, has achieved steady state air circulation pattern, and will drive indoor velocity and local air temperature. Therefore, I’d have unique steady state CFD result datasets for each concept being tested. Examples below.

Scenario 1: Design Heating - high temp supply air on design winter day
Scenario 2: Design Cooling - cool supply air on design summer day
Scenario 3: HVLS fan or other scenario as necessary

If I understand correctly, the PMV recipe accepts single air speed and applies it to each sensor in the plane across hourly simulation. I’d like to calculate point in time airspeed and air temperature for each sensor and apply it similarly across a period of interest in the hourly energy model simulation e.g., coldest week (heating) or hottest week (cooling). Or I could apply it to a design cooling or design heating day. Applying indoor CFD result to the full year probably does not make sense unless you have a constant HVAC/local fan strategy.

I have not found a CFD platform that does a great job at PMV calculation and includes spatial MRT otherwise I could just stay with CFD platform rather than hybrid approach.

With ability to set airspeed and/or air temp at sensor locations, even without a CFD analysis, users could potentially use catalog fan or diffuser throw velocity data to estimate local airspeeds and impact on PMV map.

[victorbrac]

@chris

That seems a little more ambiguous in terms of how to use it correctly because the average air temperature of the room is typically changing on an hourly basis depending on the heat gains and losses. And I am sure that any stratification pattern varies even more than the average air temperature. Maybe we could eventually expose something that lets your specify how the air temperature at a sensor differs from the average room air temperature but I still would worry that an input like that might not be used correctly and could give people a false sense of accuracy

Thanks for challenging my thoughts!

Understood! But I’m thinking of this applied more in a steady state fashion e.g., to design cooling/heating cases or to coldest/hottest weeks. For example, close to diffuser discharging 55F or 85F air you’ll have local temperature gradient. Depending on air circulation pattern, you may find that air is not well mixed / stratified from CFD result. the comfort map could pick up this new air temp from CFD result.