Simulating an occupant in a room

[MikkiSeidenschnur]

Hi everyone

So I'm trying to model this geometry Blue: Inlet Red: Exhaust

In the middle I have imported an STL model to Rhino and thereby referenced it into grasshopper, thus making it a wall boundary with a temperature of 34°C (This is prescribed in the benchmark test I'm trying to imitate).

So the problem is, that when I try to mesh this it is only the human body being meshed leaving out the surrounding geometry. So I'm wondering if there is a way to say that this body is something that is within the domain. Because it seems that it is being considered the domain rather than something inside the domain.

I hope that you guys can help me out here, Mikki Seidenschnur

Edit: Added the GH definition

MS_Case-Study 2_v1.zip

[thinklikeanarchitect]

I assume the whole geometry was meshed up, could you check the visual mesh component to ensure that inner mesh is visible (a true boolean toggle should be attached to it) ?

[MikkiSeidenschnur]

@thinklikeanarchitect I just toggled the "innerMesh" to true, and it still looks the same.

[thinklikeanarchitect]

There should be a problem with boundary definitions, could you share the model to be reviewed?

[MikkiSeidenschnur]

@thinklikeanarchitect Yes sure, I've added the GH definition in the original post.

Thank you

[MikkiSeidenschnur]

@thinklikeanarchitect How do you normally create the buildings inside the "Tunnel". I can't really see why it is possible in the "OutdoorAirflow" and not in my case. Is it because the Occupant should somehow be subtracted from the domain?

[thinklikeanarchitect]

Because you are simulating an indoor case. There's no need to subtract occupant from the domain, it should be automaatically done by defining it as solid boundary (heat source, wall or sth. like that).

[DambronOlivier]

Hi @MikkiSeidenschnur ,

I have opened your definition and recreated your error with the initial file. After setting the location in mesh of SHM different than the center of the domain which coincides with the human body, I successfully obtained all the elements meshed.

All the best, Olivier

[thinklikeanarchitect]

I have just seen the same thing, thx olivier.

[MikkiSeidenschnur]

Great! Simple fix. I'm glad. Thank you, both of you :)

[TheodoreGalanos]

@MikkiSeidenschnur I am sorry I am too late to respond was out of reach for a bit.

@thinklikeanarchitect and @DambronOlivier were on the spot. I am glad we are developing a nice community of CFD users here!

Generally, when you see weird meshes coming out of SHM, remember to check your boundary file and see if there's some boundaries missing (or some odd ones there that you didn't want, i.e. remnants of the blockMesh). It is almost always a locationInMesh issue.

As you mesh more models you will also notice the part where SHM starts "keeping cells within the region of location in mesh". At that time you will know approximately what number of cells to expect and a much smaller number will alert you to this error!

[MikkiSeidenschnur]

I must say the results of the meshing was rather satisfactory. /Mikki

[TheodoreGalanos]

@MikkiSeidenschnur Glad it worked! I will be closing this one if it's okay.

As a side note, I think this is a small enough model for you to start experimenting with nSurfaceLayers.

They are quite useful, especially when doing thermal comfort analysis, as they allow to resolve the near wall layer flows. It takes a bit of trial and error to get the right number and expansion ratio/smallest-biggest layers, but this is the model to do it for sure. You can also find the proper size of the smallest layer after the fact, by running the yplus utility after you've run your simulation (I think the solvers/boundary conditions we use currently would work well in the ~5-30 range, lower ones would probably need lowRe treatment).

I would try to start by making the size of the outermost layer close to its adjacent cell (i.e. the background cell size).

Kind regards, Theodore.

[thinklikeanarchitect]

Mikki, could you provide the latest version of your model please? It would be very helpful for beginners.

20 Mar 2017 18:41 tarihinde "TheodoreGalanos" notifications@github.com yazdı:

@MikkiSeidenschnur https://github.com/MikkiSeidenschnur Glad it worked! I will be closing this one if it's okay.

AS a side note, I think this is a small enough model for you to start experimenting with nSurfaceLayers.

They are quite useful, especially when doing thermal comfort analysis, as they allow to resolve the near wall layer flows. It takes a bit of trial and error to get the right number and expansion ratio/smallest-biggest layers, but this is the model to do it for sure. You can also find the proper size of the smallest layer after the fact, by running the yplus utility (I think the solvers/boundary conditions we use would work well in the ~5-30 range).

I would try to start by making the size of the outermost layer close to its adjacent cell (i.e. the background cell size).

Kind regards, Theodore.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ladybug-tools/butterfly/issues/210#issuecomment-287819732, or mute the thread https://github.com/notifications/unsubscribe-auth/AVssEbQsv8ZRr2pKcAe_z5QQsxul5GTdks5rnqw3gaJpZM4MiUW5 .

[MikkiSeidenschnur]

@thinklikeanarchitect Yes, I will provide it once I've looked upon the results tomorrow.

@TheodoreGalanos I know it's not SurfaceLayers, but I had quite a lot of fun meshing yesterday in another benchmark test I'm doing. Below is the result of the meshing

Also after a few grid refinements, I found that I'm getting rather good results:

Pretty satisfied so far - If you would like, I can also provide these files?

(The benchmark test was provided by http://cfd-benchmarks.com/)

[TheodoreGalanos]

@MikkiSeidenschnur excellent job! Thanks for validating cases!

Please share if you can, it will be very helpful for users.

Kind regards, Theodore.

[MikkiSeidenschnur]

@TheodoreGalanos I will make sure to share it, once I've written the reports on them. Still need to do some validation on the meshing in order to stand by the work that I've done. Also for the occupant case, I will try to apply surface layers and compare it to the current mesh that I've done.

[MikkiSeidenschnur]

@TheodoreGalanos I'm trying to do the surface layers now, and I'm really struggling with getting something that actually has a boundary layer. Do you have an example file available where it has been done?

[MikkiSeidenschnur]

MS_Case-Studies.zip

@thinklikeanarchitect Here you go, the cases that I've ran so far

Spent quite a lot of time with modelling the human body as seen in the ..._v2 GH definition in the folder - I'm still not satisfied with the result, but it's getting closer. If someone out there knows how to create proper boundary layers such as:

• Then you're welcome to share your methodology.

[thinklikeanarchitect]

Hi Mikki, I have so many experiences on validation studies both on wind tunnel and different cfd codes. Could you mention about the case that you validated, I mean was it a tunnel study or a very general case like Ahmed Body or just a cfd result from any other software?

As to validation as a wind tunnel lab researcher, I can easily say that there are even major differences reaching uo to 60% in between different wind tunnels. On the other hand when you accurately and samely define boundary conditions most of the cfd packages give nearly same result. Currently, I have compared Solidworks Flow Simulation with BF and got exactly the same result. If you interested in those, I can share the files with you, or if you desire to be in touch you can email to me : karadagi@itu.edu.tr

Lastly I am.working on optimisation issues as to wind interaction with building. However currently there is an issue which should be solved to use optimisation tools such as Galapagos. Bcs BF continously refreshes GH screen and this prevents optimisation tools to work. Since opt. tools needs an end as to anslyses. In BF case every iteration activates opt. tools unfortunately. I wonder if it may be solved in near future. Mostapha gave really great effort as to coding stuff and he may give a try to that too.

[MikkiSeidenschnur]

@thinklikeanarchitect I mostly do validation based on experimental cases. We have a lot of indoor climate chambers at my university. I'm aware that results for outdoor analysis can vary insanely much, that's also one of the reasons why I've stayed clear of wind analysis so far.

It's always interesting to see what fellow researchers are coming up with, so I'd be glad to see your validation studies - especially if you have in a report form - I find it so much easier to understand the reasoning behind the simulations.

I actually was wondering about that, I thought that might be why it sometimes seems to be slower than when I'm running my cases in OpenFOAM solely. Right now I'm at the point where I setup everything in grasshopper with the meshing and so on, and then I go to Bash for Ubuntu and run the simulation. Sometimes it's up to 3 times faster for me, and it doesn't put a huge strain on the graphics card, since Rhino/Grasshopper doesn't need to be running - trying to render the vectors for each iteration. I agree that Butterfly is a super useful tool, and I think that it could make CFD an even hotter subject in the building industry.

[TheodoreGalanos]

I can confirm that Linux is light speed ahead of running OF on windows. This is not an issue with BF of course but mostly the way OF is built and run (through Docker) in Windows. Of course this is relevant in complex models. Most indoor cases of a couple of zones would run fast in Windows as it is.

@mostaphaRoudsari Do you think we could consider adding this to the wiki? It might be good for the users to know what to expect and how to obtain faster running time in production.

Kind regards, Theodore.

[MikkiSeidenschnur]

@TheodoreGalanos Yeah I think for simple indoor cases, it's mostly fine. For these validation cases that I'm doing with a human body, I definitely prefer taking it over on Linux. I've reached 750.000 cells so far, and still not completely satisfied with the yPlus values.

Speaking of: is there a way to make the calculation of yPlus values from BF? Is it just a funcObj ?

[TheodoreGalanos]

@MikkiSeidenschnur Yes it's a function object. Haven't tried to see if I can add with custom inputs. It's on the list of upcoming features though, several function objects that is.

The hope is that users will will also let us know which ones they miss/want the most.

Currently, yPlus is quite easy to run from the terminal at least.

P.S.: I think you should go more than that. I think I was around 3.2m at my first run, without surface layers. I increased meshing refinement on the human body by a bit. Also I think you might want to snap in this case, given the geometry.

Kind regards, Theodore.

[MikkiSeidenschnur]

@TheodoreGalanos Yeah I turned on the snapping for this case. Makes the body be represented much better. Still bothers me that I'm not snapping the edges of my domain though. Probably doesn't mean anything, but I'd like to know if there is a way to do it (Snap the edges of the domain that is)

For the yPlus I'm also just running it in the terminal so far. Was thinking that it might be nice to make a utility that could prompt the user, that they should investigate the yPlus value if it exceeds the range of 5-30. At least for indoor models. Obviously for models where the wall treatment is important, it should be much lower.

[TheodoreGalanos]

@MikkiSeidenschnur Yes I think that is smth we can do easily, since you can probably report it in runtime as well. Although, I don't think we need this small of yPlus. Typically we can be somewhere between 30 and 100, below 30 you are already trying to resolve the wall layer and you probably need different boundary conditions. This is out of memory and I haven't really tested all this much.

Concerning the edges of the room you can try the following procedure. It is not exposed in BF since we are lacking paraFoam in the installation (or I'm lacking it cause I've been lazy installing it):

• Step-1: Use the surfaceFeatureExtract utility to extract features with a typical angle(e.g. 150).
• Step-2: Use the surfaceFeatureConvert utility to convert those features to an .obj file (only requires an input path and output name xxx.obj.
• Step-3: Open the .obj file with paraView and make sure that all the edges from the original STL surface are identified.
• Step-4: If you the above is ok, move to SHM. If not, check other angles.

Not sure this will fix it, but it is a good methodology for extracting edges on more complex geometries.

Kind regards, Theodore.

[TheodoreGalanos]

@mostaphaRoudsari I just realized we can do this in Rhino as well, since it can load the .obj files.

This could be a really nice feature actually. We can load the object file created by the surfaceFeatureConvert utility along with the mesh. This way the users can see if they captured all the edges.

I'll try and test it out tomorrow, kind of late right now.

Kind regards, Theodore.

[MikkiSeidenschnur]

@TheodoreGalanos I'll try it out and see if I can get it to work, thank you

[MikkiSeidenschnur]

@TheodoreGalanos Is there a way to turn on a surface-to-surface radiation model with Butterfly? Or would I have to do that manually. I can't really hit the "correct" values for the validation study discussed earlier. The temperature gradient of the room is very even, and the experiments suggests that it should be much larger.

[TheodoreGalanos]

@MikkiSeidenschnur I'm afraid that option is not yet implemented in BF. You can turn on radiation manually in OF however after you've set up your case with BF. We will probably implement this in a subsequent release. There's a couple of radiation tutorials if you want to play around with them, in the incompressible/buoyantSimpleFoam folder.

You could also try different boundary condition for the surfaces. Flux/m2 and gradient (i.e. conductivity value) might give better results than temperature.

Kind regards, Theodore.

[MikkiSeidenschnur]

@TheodoreGalanos Thanks for your response. I really find this feature essential, in order to validate any case that involves stratification in a building, so I'm glad to hear it is not off the table.

Best regards Mikki Seidenschnur

[MikkiSeidenschnur]

@TheodoreGalanos I have one more question for you with regards to turbulence modeling:

• Is it possible to use kOmegaSSTSAS model for incompressible flows, just with the use of Butterfly?

The reason I'm asking, is because the terminal executes, but then says:

"FOAM FATAL ERROR": keyword wallDist is undefined in dictionary ".../fvSchemes"

I'm guessing that it simply hasn't been implemented yet, and that it's because we're missing the Omega part in the boundary conditions. Also my temporary solution would be to implement a custom fvScheme with the heatTransfer recipe, but I really can't find a fvScheme file that represents what I need. Do you know one I can use @TheodoreGalanos ?

Best regards Mikki Seidenschnur

[mostaphaRoudsari]

Hi all,

Sorry for not being able to reply this week. This issue can/should be broken done into multiple open issues. Very interesting discussion(s). Thank you @MikkiSeidenschnur for sharing your work.

@thinklikeanarchitect in case of optimization it has been already fixed. If you input a -1 value to interval the solution will only gives you the results once the iterations are over.

@MikkiSeidenschnur for boundary conditions or any other values that are not implemented yet you can use create a solutionParameter and modify or overwrite it from inside Grasshopper.

@MikkiSeidenschnur if you're looking for an example with layers check the pipe-meshing example.

@TheodoreGalanos and @MikkiSeidenschnur if we have a simple example file that correctly models bouncy I will be happy to implement it as a new recipe or replace the current heat transfer recipe to a more accurate solution. Is it just a matter of boundary conditions that are not supported or the solver? or both?

I rather not to touch butterfly until we release honeybee[+] but if there is something critical, or there is a bug that will be an exception.

[TheodoreGalanos]

@MikkiSeidenschnur I haven't used Menter's SST implementation for a case yet so I hadn't seen this error before. OF official site describes it as a

Scale-adaptive URAS model based on the k-omega-SST RAS model.

That leads me to think that there is some adaptation going on near the wall, depending on some qualities of the mesh itself. Searching online led for that error very quickly leads you to this recommendation that suggests adding the following line to fvSchemes dictionary:

wallDist { method meshWave; }

The error should be because we are missing that from fvSchemes file, the omega file should be created correctly in the 0 folder. However, this is a good catch. It tells me that I need to go back and check all the solvers one by one to make sure we avoid these kind of errors.

I have to be honest that in this time of development I didn't expect a lot of less common solvers to be used. I'll make a case study and try to iterate across all solvers and make sure they work out of the box. Just a question, are you simulating a transient case with this one?

@mostaphaRoudsari I think concerning buoyancy, boussinesq solvers should be enough for now. At least for most natural convection scenarios they should be able to give good results. We can add additional heat transfer set ups after HB+ is out perhaps. I'll try to catalog any solver bugs I find and send a fix for them in the meantime.

Kind regards, Theodore.

[MikkiSeidenschnur]

@TheodoreGalanos and @mostaphaRoudsari I think that the solvers for free buoyancy flows (k-epsilon) will work fine for now. It's a special need for me to have it, and therefore I will make sure to find out how to implement it myself. Think I'm close to having a working example.

I would really like to have the SST model implemented, since it can give crucial differences, as said by "Turbulence Modelling for CFD" by Wilcox DC. Most of these differences are seen when there is a heat transfer from the solid wall boundaries, like a human body. The study by N. Martinho et al. 2012 called "Evaluation of errors on the CFD computation of air flow and heat transfer around the human body" emphasized that this difference between turbulence models will cause major errors in some results if only the k-e model is used.

@TheodoreGalanos I'm simulating this as a steadystate case

Best regards Mikki Seidenschnur