Fairyfly user feedback

[Gspahr]

Hello everyone, first off a huge and hearfelt THANK YOU to everyone who contributed to making Fairyfly! I’m very excited about the new tool, which is why I tried it out as soon as possible. I’d like to offer some feedback from my first experience.

Feedback #1
So far I have tried making a grasshopper definition from scratch using some random geometries and random material specifications. However I had an issue with how the boundaries were being defined, in this case I used a single line on the left side (no issues here), and a single line on the right side. In a couple of lines you will see why this is problematic. Here’s the shape geometries:

I kept struggling with the THERM simulation and getting this error:

You need to have at least two non-adiabatic boundary conditions to do a simulation. Check your boundary condition definitions.Calculation not successful

Well, I figured that the right side boundary maybe had to be broken down into 2 pieces because I had 2 material shapes on that side. I found there are two ways to fix this, either

• using 2 separate boundary lines, each coincident with the 2 shapes on the right, or
• using a single polyline with nodes coincident with the shape change.

Maybe this is common knowledge among THERM users, but it had me scratching my head for a good 20 minutes. It would be nice to have Fairyfly do this boundary geometry check automagically and break down the geometry if necessary (kind of like how the HB Intersect Solids did with rooom geometries).

Feedback #2
I can’t seem to make FF Color Boundary Attributes work in the Rhino viewport, in fact just having this component preview on, it makes FF Color Shapes Attributes disappear from the Rhino preview. However, it’s working under the hood because I can get the attributes from the component’s outputs.

Turning FF Color Shapes Attributes preview off does nothing to fix the problem. I imagine this is a bug.

Feedback #3
After finally getting things working and seeing the simulation results I started playing around with the legend parameters to see if I could get the whole rainbow from the thermal palette through my materials, but it seems like the mesh is a little coarse and the gradients jump from one color to another, while skipping the intermediate colors (see the bottom side where it jumps from black to green without going through purple-blues). This makes it harder to visualize what is happening throughout the materials. Is there any way to further refine the mesh before running the simulation?

Thanks in advance, I will be looking forward to further FF versions.

[chris]

Hi @Gspahr ,

Thank you for testing and for the feedback.

1. You are right that I was so concerned about the inverse of this case (the Boundary line is shorter than that of any Shape segment) that I didn’t really consider the inverse (the Shape segment is shorter than the boundary line). I just added a check for this in the THMZ translation process, which will split the boundary line for you with the shape vertices:

fix(writer): Add an extra step for boundaries longer than shape edges

With this tweak, you should have no problem running the models in your screenshots where there is a single boundary line segment that adjoins multiple shapes.

2. Thanks for letting me know about this. I actually did most of my testing in Rhino 7 in order to have sample files that any of our users could run (even those using old versions of Rhino). I did not realize that the way the FF Color Boundary Attributes component interacted with the Rhino 8 DisplayPipeline was not working. Admittedly, there is still a lot to the Rhino DisplayPipeline that I do not fully understand but I made a change to the component here, which I have verified works in both Rhino 7 and Rhino 8:

fix(visualize): Change output order for Rhino 8 DisplayPipeline

3. Lol. This is definitely the type of comment that I prefer to get. It’s like you are telling me the new THERM mesher is too good! I am pretty sure that I can give you the smoother mesh you want by just exposing the meshing parameter for the new Symmetrix mesher. Give me until tomorrow to get this into the Grasshopper component but, if you want to see what I am going to do, you can open your Grasshopper-exported THMZ file in the THERM interface and go to File > Properties > Calculation Options. Then up the Mesh Parameter to something high like what I have done here:
   
   

Then, simulate your model in the THERM interface, save the THMZ file, and load it back up into Grasshopper. You should see that the mesh is a lot finer and your colors look smoother. If you confirm that this is what you want, I will try to expose the MeshParameter on the FF Model to THMZ component tomorrow.

The two fixes that I pushed should now be available via that LB Versioner component if you want to get the updates on your end and test them. Thanks again for all of the feedback!

[Gspahr]

Thank you so much! The trick you proposed in the third point indeed does the trick beautifully: after a couple of tries it looks as if 20 is a good number for the Mesh Parameter. It did however shift the mesh to the right of the original geometries, not sure why.

As for the Display Pipeline issue, I managed to get the boundary visualizer working in a different file that I also started from scratch. I still don’t know why it happened in the first place, but I can send you my definition for you to find out. Turning preview on for the boundary visualizer also seems to make the results disappear from the preview.
THERM.gh (65.5 KB)

[chris]

Hi @Gspahr ,

I exposed the ability to change all of the mesh settings here:

feat(therm): Expose Meshing Control on a dedicated component

… and you can now get the new “FF Meshing Control” component using the LB Versioner, which lets you customize the mesh parameter and other parts of the meshing operation:

With the change above, I also set the default mesh parameter to 20 so that you typically get a pretty smooth mesh.

I was not able to recreate you issue with the result mesh becoming offset from your original geometry but perhaps you changed more than just the mesh parameter when you opened the THMZ in the THERM interface? Maybe you also changed the origin of the THERM model? If you can recreate the issue again, let me know.

As for the boundary visualization, your THERM.gh file did not have the updated FF Color Boundary Attributes component in it (version 1.9.2). Once I ran the LB Sync Grasshopper File component to update it, everything seems to be fine:

[Gspahr]

Thank you @chris, meshing options are working as intended. May take a little longer to simulate with a very fine setting like 50, but still, it’s very quick (it’s just a few seconds, but the resulting mesh can be a little intense to process).

As for FF Color Boundary Attributes I wasn’t able to recreate the issue either, so I don’t know what happened, perhaps it was the virtual environment on my side. The component is working just fine now.

I will try to recreate the shifting geometry issue for my next post.

[Gspahr]

Hello @chris, just a quick update. I wasn’t able to recreate the shifting geometry issue, still I have no idea why it happened. I will keep an eye out in case it happens again.

I recreated the workflow from my first try with new random shapes and this time everything went smoothly. Down below is a comparison from THERM and from FF.

While playing around with visualization setttings I came across a new pet peeve with how isotherms are drawn inside of LB Mesh Threshold Selector as opposed as how they are drawn natively in THERM.
In the next image you can see how neatly isotherms encounter the condition boundaries as well as the remaining perpendicular boundary.

Inside of LBT I get jagged isotherms, because the mesh isn’t relaxed and the resulting intersection is a bit harsh.

I tried a workaround to smooth these isotherms with Smooth Polyline…

…but I get unwanted round corner curves where lines intersect the shape boundaries because the smoothing component is working with region closed curves instead of open polylines.

Not that it is a huge problem as I can imagine a few workarounds, but it would be nice if LB Mesh Threshold Selector had an optional output with outlines that don’t include the perimetral lines of the mesh.

[Gspahr]

I made a workaround to visualize the isotherms in order to compare with LB Mesh Threshold Selector, as you can see there is a little discrepancy between the methods.

I’m sharing the grasshopper definition down below.
THERM3.gh (53.3 KB)

[chris]

@Gspahr ,

Wow. Your first suggestion for the isotherms is a really creative way to use the Rhino Geometry SDK.

For years with the Legacy plugin, I tried to get your second method to work reliably but the Rhinocommon methods for Mesh/Plane intersection are just really challenging to use if you want them to work reliably. Granted, they work really well for simple color results with really smooth, heavily subdivided meshes. But there were just so many cases I found where they fail to give you contours that I never got the Legacy Contour Mesh component that used this Mesh/Plane intersection method out of WIP or ported over to LBT.

But this other idea of just smoothing the lines that we get via the LB Mesh Threshold Selector is a whole different strategy that I had not considered. Clearly, we can get these threshold lines reliably given how we make them by just removing mesh faces or vertices. And converting these closed polylines output from the Threshold Selector to be open is not hard. All that we have to do is take the naked edges of the threshold-selected mesh and remove those that are also naked edges in the original mesh. This should give us really good starting lines to be smoothed. Then, I just need to figure out what the Rhinocommon methods are under the hood of the native Grasshopper “Smooth Polyline” component.

From there, we could even add some text labels to the contour lines like what the Legacy component did. If I get the time, I want to give a try at putting this all together tomorrow. If I don’t get all of the way there, I’m going to see if I can do it this weekend. But, whatever the case, I am sensing a new “LB Contour Mesh” component in the not-too-distant future.

Thank you for the creative problem-solving here, @Gspahr! Makes me realize how stuck you can get in one way of thinking when it’s just one person “polishing a turd” of a Legacy component. This is definitely one of those cases where I’m thankful that we have a creative community around this. To quote a good book, “The smartest person in the room is the room itself.”

[Gspahr]

Hello @chris, it’s me again. I’m humbled by your comments, I just try to give my 2 cents whenever I can. And I would never even dream of calling any of your work a polished turd!!

Turns out I’ve been playing around with THERM once again, trying to do a comparison between plain EPS vs the same EPS with an aluminum foil (low emissivity = 0.05) and got very dramatic changes on the inside’s surface temperatures. Then it dawned on me that I was getting very unrealistic values with the standard solution (standard emissivity = 0.90). For example, a 250 mm deep EPS rectangular shape with an interior temperature of 18.0 C and -10.0 C on the exterior should not have an interior surface temperature of 0.6 C.
(For comparison, I was getting 14.2 C with the aluminum foil on, which also seemed a little lower to what I was expecting.)

I was expecting something much closer to ~16.6 C (which comes from a manual calculation). Could it be that the THERM interior film coefficient is off or the internal calculations are being funny? I have to crank it up to 85 to get the same results (once again, for comparison, with this new coefficient the aluminum foil version gives 17.9 C, but I can’t verify whether it’s a valid temperature or not).

Simulating the same THMZ file inside of THERM’s software gives me the same unrealistic results, which means it’s not a bug on FF’s side. Time to bring this issue to the developers team?

[chris]

Hi @Gspahr ,

I cannot recreate what you are describing here. When I simulate 0.25 meters thick of EPS (no foil), I get pretty reasonable temperatures:

When I put foil on both sides of the material with an emissivity of 0.5, I get pretty cold outdoor temperatures (as expected) but the results still seem pretty reasonable:

In both cases, indoor temperatures are around 16C-18C.

Here are my files to recreate everything:
THERM_EPS_Test.3dm (340.3 KB)
THERM_EPS_Test.gh (27.9 KB)

Is it possible that you did not set up your Rhino model units correctly such that you’re actually simulating something like 25mm of EPS instead of 250mm?

[Gspahr]

Hello @chris, thanks a lot. My rhino units were fine, I had already double-checked. But it seems I just found out the issue!

Your gh definition indeed worked just like intended:

But then I noticed that the warm temperatures were on the right, and the cold ones on the left. I had done the exact opposite. So I decided to cross your lines’ geometry and I get again the strange unexpected results from before.

Mind you, not even the version with low emissivity gives similar results by changing the boundaries’ side.

Not that any of this makes sense (unless it’s common THERM knowledge to put interior boundary on the right, and exterior on the left), but I thought it would be useful to share.

[chris]

Thank you for digging into this and bringing this to my attention, @Gspahr .

You are correct that something was going wrong here and I am nearly positive that I have figured it out. It seems there is a bug in THERM whenever there are two boundaries that use the AutomaticEnclosure radiation model, which LBNL documented here:

https://windows.lbl.gov/two-automatic-radiation-enclosures-same-model

The bug announcement on the LBNL website says that it affects THERM 6 and 7 but it seems that it is also in THERM 8.

Long story short, it seems the best way to work around the bug is to just use the BlackBody radiation model instead of the AutomaticEnclosure one. So I made a change here, which switches Fairyfly to always use the Blackbody model (with a view factor of 0.5):

fix(condition): Always use Black body until AutomaticEnclosure is fixed

After this, I have verified that you get the exact same temperature and U-factor results no matter whether the warm side is on the right:

… or on the left:

This fix is now available with the LB Versioner if you want to test it.

Granted, I will admit that my hard-setting of the view factor to 0.5 may not be the most accurate way to model certain boundary conditions that are highly concave. I originally used the AutomaticEnclosure model because it is supposed to account for the boundary blocking the view of itself to the rest of the environment and so Charlie from LBNL recommended using it wherever possible.

But trying to account for the typically small change from 50% view factor that results from concave boundary conditions is only going to change your THERM results by a few tenths of a degree at most. Whereas encountering this bug can throw your results off by an order of magnitude as you have shown, @Gspahr . So I am going to play it safe for now and just stick to the black body model. As the saying goes, “it is better to be approximately correct rather than precisely wrong.”

If the error of a tenth of a degree or two keeps you up at night, I can probably find a way to perform our own view factor calculation during translation to THMZ. We have pretty good geometry libraries for calculating view factors after all. But the results you get after my fix above should be “not wrong enough to be useful.” And they should align correctly with the hand calculation that you performed.

[Gspahr]

@chris

If the error of a tenth of a degree or two keeps you up at night,

I tested the updated version yesterday and I literally slept well last night, which means all systems are go!

@chris

I can probably find a way to perform our own view factor calculation during translation to THMZ

That didn’t even cross my mind, but it sounds like it would be a great addition!

I will keep testing around poking my finger at FairFly over the next few days and see if I can gind anything else. Thanks @chris !

[chris]

Glad to hear that no sleep has been lost!

The more that I think about it, THERM already makes some pretty broad assumptions about the radiant environment (eg. everything is the same emissivity) such that a few tenths of a degree is well within the expected margin of error between a THERM model and reality. So I’m inclined to keep things the way that they are, at least until we have first tackled some of the other gaps between THERM models and reality (eg. hydrothermal effects and transient simulation).

I also wanted to let you know that I pushed a new “LB Contour Mesh” component to the development version of the plugin yesterday, which is now available via the “LB Versioner”:

It uses the first method that you tried except that you won’t have the contour lines around the outside of the mesh so you can up the _smooth_iter_ of the component and not end up with any artifacts of curves jumping outside the mesh. And you can see that it is full customizable with LB Legend Parameters down to the font used on the contour labels.

And the part that makes me particularly happy is that, because it uses your first method and not the plane intersection of a mesh height field (like the legacy version of this component), it can work with non-planar meshes like the radiation dome:

Or the 3D version of the hourly plot:

Or pretty much any Ladybug Radiation, Sun Hours, or View study:

I even have an idea to get the component able to also produce a colored mesh with solid bands between each of the contours, which I know made for some nice visualizations in Legacy when it worked. I’ll see if I can give this a try later today but let me know if you have any other feedback.

[Gspahr]

Hello @chris, great to hear about the LB Contour Mesh component! I updated via the versioner but I wasn’t able to get it working with the THERM results. I closed and opened Rhino a few times, I even restarted my PC, still I get the following error.

Runtime error (MissingMemberException): ‘LineCurve’ object has no attribute ‘Length’
Traceback:
line 295, in label_countours, “C:\Program Files\ladybug_tools\python\Lib\site-packages\ladybug_rhino\fromobjects.py”
line 62, in script

If the attached image is not enough, here’s my file for debugging purposes.
THERM3.gh (228.7 KB)

I noticed that the number of mesh faces is different from the number of results, but I’m unsure if that’s the cause.

I did try it successfully with the radiation dome component, but it seems that under some settings the contour lines lay just below the colored mesh, becoming obscured in certain areas.

Seems to work fine on 0 smooth iterations (but with jittier lines)…

…and it becomes worse the higher the iterations.

Of course, by refining the mesh the lines become more precise…

…which also makes the contours more robust to few iterations…

…but skips below the surface again with a greater number of iterations.

I managed to find a couple of workarounds for this visualization: basically broke up the contours into points which I then projected onto the mesh, then made them back into a polyline. This method seems to work better with a very high setting for the smoothing iterations.

I’m not used to working directly with mesh geometry, so there might be a more clever way to do this.

I also tested the 2D version of the radiation dome, and it worked fine.

It just has a little visual artifact where the contours reach near the polar point of the sphere. (screenshot with 0 and 20 iterations on top of each other)

That’s as far as I got with today’s testing, I hope this feedback helps making LB more robust.