Optimization post processing

[DambronOlivier]

Hi @mostaphaRoudsari,

I am running some tests after the recent commit 905764f .

In order to benchmark the testing I am following a paper written by Peren et al. on the "Impact of eaves on cross-ventilation of a generic isolated leeward sawtooth roof building: windward eaves, leeward eaves and eaves inclination" 3. Impact of eaves on cross-ventilation of a generic isolated leeward sawtooth roof building- windward eaves, leeward eaves and eaves inclination .pdf

I have replicated the parametric model of this example and am using ladybug_fly to compute multiple Eave inclinations. Although in the paper the simulations are 3D, I am proceeding in this case with 2D and using -1 for interval.

The vectors are unitized here.

A paraview visualization.

1. As I am looking forward to capture each mesh and associated vector to animate visually all the iterations within gh, I have set the Case name to change for each iteration, resulting in creating as many cases as iterations.

I tried in vain to load the probes and associated meshes to be able to scroll through the results, though I am unsure how to load the mesh.

2. Although most of the cases were successfully created after the convergence of the respective previous one. Some induced errors which I think are due to meshing. I am using explicit meshing feature with a surfaceFeatureLevel = 2.

This one was successful.

This one failed. Please find the log file here simpleFoam.err

Would you know a way I could get around these issues? Many thanks again.

Kind Regards, Olivier

[mostaphaRoudsari]

Hi @DambronOlivier! It is quite exciting to see your work. Well done. I can help with number 1 and will leave 2 to @TheodoreGalanos.

Back to 1 you should use your analysis mesh which is generated by genTestPoints component and not the OpenFOAM mesh itself. The way you're reading the values for velocities should just work fine.

BTW what is the error message from load case from folder? You should be able to load the case from the folder.

[DambronOlivier]

@mostaphaRoudsari ,

here is a screen with the error messsages. The issue seems to be that the number of results do not match the mesh faces. I conclude that some probes were skipped? I am unsure of the reason and as I try to load them an error comes.

[mostaphaRoudsari]

@DambronOlivier can you share one of the folders with me?

[TheodoreGalanos]

Hi @DambronOlivier I'll try and post some ideas of what could be wrong here but it is a bit hard without taking a look at the cases.

First of all the error is the typical 'divide by 0' error of openfoam, which happens for a variety of reasons. In your case does it happen during or at the beginning of the case?

Furthermore, I am guessing you are using SHM to mesh your 2D cases. I've found it is a bit dangerous to do so, as the (potential) refinement introduced to inlets, outlets, and walls, can cause mesh irregularities (mostly alignment issues) which leads sometimes to errors like these (but this error would happen at the start of the run not during). I would strongly suggest you mesh this case with blockMesh. In order to achieve a variable meshing, you can use the gradient mesh component and give more mesh density where the room is.

Concerning the error with visualization, I have a feeling this could be cause due to the meshes actually being different. If I understand your case correctly, you are simulating different angles of the eaves which would mean that the probes are linked to different meshes and that could cause the mismatch error (imagine one has a probe where the other has an eave). I am not sure how we would bypass this, if it were true, @mostaphaRoudsari will have more knowledge on this. Maybe we can use a mesh/probe value kind of visualization? Or maybe I'm way off in my thinking here. Have you tried loading them one by one, with their respective meshes, to see if that at least works?

As @mostaphaRoudsari said, if you'd share your folders it would help. That said, give me a bit of time and I will try to replicate your case while using some of the suggestions I made above.

Kind regards, Theodore.

[DambronOlivier]

@mostaphaRoudsari @TheodoreGalanos , I was unable to upload a zip file directly, please find the case folders through this wetransfer link. https://we.tl/SoEqzhAVvn I will figure it out and upload it here tomorrow.

I have put inside the gh definition which is hard to digest though there are titles for the different bits. outdoor_airflow_2d_peren_Wn45_L0 is the failing case folder. outdoor_airflow_2d_peren_Wn45_Ln45 is a successful one.

It is getting a bit late in London, count on me tomorrow to come back at you on this. Kind regards, Olivier

[TheodoreGalanos]

Hello @DambronOlivier

I have tried to replicate and run one of your models. It was successful however that says little about the ones that gave you the error. Since it's hard to test one by one all the cases I tried to make a sort of best practice approach (even though it's probably not ideal, was done in a hurry). The basic things I added were:

• a much more refined blockMesh. This is especially useful in 2D cases since most of the refinement can be achieved here with little effort.
• a gradient blockMesh, to allow smaller blockMesh, hence more refining, in the area near the building. This gives higher quality mesh near your geometry, with the same amount of cells. It is also a very good way to control cell expansion. In your meshes, as seen from the screenshots, the jump from indoor to outdoor is way too big and will eventually lead to problems (either divergence or quality of results).
• a bit more surface refinement. Both surface and feature extraction levels are set to 4 . This was probably the least important thing but it's quite cheap to do in 2D models.
• a refinement region around the building for further volume (i.e. interior of the house) refinement. It is probably ok to run it without this but I just added it since it is again quite cheap.
• a short windward region and an elongated leeward region. You can clearly see in the attached screenshots that the pressure near the outlet is 0, which shows that the distance allowed after the building is adequate for the free stream flow. This is important because in our standard BCs for the outlet we assume a 0 pressure, so we need to kind of build a mesh that achieves this in practice.

The end result is a quite nice quality mesh I would say, with only around 400k cells. I feel this is a decent number of cells for this case and should run quite fast. I think I run 1000 iterations in the span of a few minutes (wasn't really paying attention, maybe 10 or so) in my computer on a single core, so it should certainly be feasible to get all the runs done with this in a matter of few hours (maybe overnight) in a standard muti-threaded PC.

Hopefully, this setup will not give you any run-time errors, at least concerning the physics of the case. If you want, feel free to try the attached definition on your own models. If I've modeled the house correctly it shouldn't be too different to just change the input geometry and run it as it is. Although it is always good practice to check the blockMesh and make sure the cell expansion makes sense. One thing you would have to correct is the leeward window, I reduced the height of it when extruding the eave downwards! Oh, and remember to adjust the incoming wind velocity your values!

Hope this helps! Let us know!

Kind regards, Theodore.

Wind Velocity Plot

Pressure Plot

A view of the glyphs, showing the recirculation patterns on the leeward side

HouseWithEaves_Model.zip HouseWithEaves_CaseFolder.zip

[mostaphaRoudsari]

@DambronOlivier just wanted let you know that I'm working on this. There are a couple of minor issues with the import components that I need to fix. Generally speaking it's always better to subtract the test geometry from the test surface to not end up with missing probes. I'll keep you posted.

[mostaphaRoudsari]

@DambronOlivier @TheodoreGalanos you should be able to import the case with no issues with the new fix.

Back to loading the probes I added a new component to load the probes from the same file that it loads the results. This will be a temporary solution until we implement #61.

Also I checked the log for simpleFoam and it seems to be canceled and not converged. Did you cancel the run or is it a bug?

--------------------------------------------------------------------------
mpirun noticed that process rank 3 with PID 31767 on node default exited on signal 15 (Terminated).
--------------------------------------------------------------------------

[TheodoreGalanos]

Any progress on this one @DambronOlivier ?

Curious to see if a different meshing strategy, and @mostaphaRoudsari commit, fix this issue.

Regards, Theodore.

[DambronOlivier]

@TheodoreGalanos , First of all many thanks for sharing the case folder with the blockmesh well set and also for all the information you shared. I really feel the pedagogic aspect of Butterfly. It really breaks down the complex CFD journey from entry to deeper.

I have not managed to sort out my schedule this week to properly follow up as I would like to, after solliciting you and Mostapha on this matter. Please do accept my apologies.

@mostaphaRoudsari , Thank you for having been responsive as always. My apologies as well for my late reply. I have indeed subtracted the test geometry from the test surface for each iteration. As I parse each case, the number of values do not match the last genTestpoints mesh... for sure. Therefore I am not able to visualize dynamically the colored mesh at the end.

I have tested the new component with the set of cases I had computed previously without rerunning them after updating BF, nor integrating Theodore's adjustments. There is a minor error as follows. I will recompute the files considering the updates.

Kind Regards, Olivier

[mostaphaRoudsari]

OpenFOAM still filters a number of points out as skipped points. The new workflow ensures that you get the points and values in the same order from the same file.

The import error should be solved once you update butterfly and re-start Rhino.

If you don't mind and once we have the meshing setting updated as @TheodoreGalanos suggested maybe we should add this file as one of the example files. Much better than my boring box examples :)

[mostaphaRoudsari]

This new component Sample Case should make it easier to post-process the results. You can sample using any points.

[DambronOlivier]

@mostaphaRoudsari
If you wish, please do use it in the example files. :) glad to contribute as I can.

Would there be a way to reverse the genTestpoints component and obtain the mesh from the probes?

[mostaphaRoudsari]

@DambronOlivier thanks!

I believe you can use Mesh Spray component in Grasshopper. You have the base mesh, and then use the points and colors to color the mesh based on the values. We can also write a script to remove faces with results and color the rest.

Also should we close this issue?

[DambronOlivier]

@mostaphaRoudsari Many thanks for the tip. We can close the topic indeed.

I will run other cases of optimisation as I understand them. I will try to do form-finding with constraints applied over the perpendicularity of the normals of the geometry to the airflow vectors. I was also looking forward to run a case of optimization to size the outlet according to the volumetric flowrate by assessing the average wind speed values at all the points included inside the geometry or the average at the inlet and outlet. I will keep you posted when I achieve it.