Biosystems Engineering Blog (Posts about gsoc)

GSoC Week 5 recap

Kurt Kremitzki — Tue, 11 Jul 2017 19:45:35 GMT

This week started out with some interesting discussions on the future Python structure of FreeCAD, over on the forums. This was especially salient as I have a bit of pain interacting with parts of the FreeCAD Python API and improvements to it would be a good long-term goal after finishing GSoC.

I decided that the TestPartDesignApp.py file I had been working in thus far needed splitting up, as I was cramming almost every new test into it. The new version of this file is a pretty nice indicator of the overall status of PartDesign test coverage.

I also added some basic tests for datum tools, covering simple creation scenarios. While exploring the 4th datum tool, ShapeBinder, I found a bug that causes a crash, so I will need to look into that shortly to see if it's an easy fix.

LinearPattern and PolarPattern got 6 new tests each, covering all the major variations of sketch- or primitive-based features.

Finally, I added one new test for each of the dressup features, Fillet, Chamfer, Draft, and Thickness.

Here's the pull request summarizing my work: https://github.com/FreeCAD/FreeCAD/pull/869

tool category	initial, current test count	status	notes
datum tools	0, 3	ready	found shapebinder crash bug
add. & sub. features/primitives	15, 15	ready
transformations	3, 15	ready	all done but MultiTransform
dressup features	0, 4	ready
boolean operation	0, 0	ready

GSoC Week 4 recap

Kurt Kremitzki — Fri, 30 Jun 2017 10:48:06 GMT

I started this week out with the goal of troubleshooting the bugs I found with PartDesign Pipe and Revolve. However, I ended up running into several annoying issues. The LLDB debugging integration I previously wrote about began showing some inexplicable errors:

error caught in async handler 'exec ('continue',)'
Traceback (most recent call last):
  File "/home/kurt/.config/nvim/bundles/repos/github.com/dbgx/lldb.nvim/rplugin/python/lldb_nvim/__init_
_.py", line 49, in _exec
    self.ctrl.safe_execute(args)
  File "/home/kurt/.config/nvim/bundles/repos/github.com/dbgx/lldb.nvim/rplugin/python/lldb_nvim/control
ler.py", line 101, in safe_execute
    self.safe_call(self.exec_command, [cmd])
  File "/home/kurt/.config/nvim/bundles/repos/github.com/dbgx/lldb.nvim/rplugin/python/lldb_nvim/control
ler.py", line 94, in safe_call
    raise EventLoopError("Dead event loop!")
EventLoopError: Dead event loop!

Eventually I found an issue on Github which refers to a now-deleted comment in the author's original repository, stating the project was no longer being developed. The question remains as to how it was working just fine when I began and only just now stopped working, but the end result was that my debugger-editor integration was broken, which makes it quite a bit tougher to debug the C++ side of the codebase.

One option I had was to just use GDB as a standalone command line application, but it's really convenient, e.g. to not have to manually type out file names and line numbers for breakpoints, and otherwise have your debugger wired up to your editor.

However, this was inexplicably not working either! Basic features of GDB worked, but trying to specify breakpoints to step through the code was not. I banged my head on this issue for a while until I figured up ccmake to take a look at my build options. The issue? Somehow, the CMAKE_BUILD_TYPE, which had been set to Debug, was unset. So, I set it again and started the debug build, which takes quite a long time. (Around 2 hours with make -j4.)

I also did more research on options for debugger integration. I found an interesting option called Pyclewn which is a debugger front-end for (neo)vim. This option was attractive since I could have a unified front-end to both my C++ debugger as well as a Python one. However, setup wasn't straightforward, so I continued searching for a simpler option.

Luckily, I stumbled upon neovim_gdb.vim, a simple combination of vim settings, available in the contrib folder of the neovim repository.

Once that was taken care of, I started working on my original objective for the week. I found that the PartDesign Pipe issue was being caused by the code checking for whether or not the Pipe's AuxillerySpine (sic) was a part of the active body, but didn't check if the thing existed first. This resulted in a check to see if a null pointer was part of the active body, which is never the case. Checking for existence first resolved the issue. With that bug fixed, I also added two tests each for PartDesign Pipe and Loft.

tool category	initial, current test count	status	notes
datum tools	0, 0	ready
add. & sub. features/primitives	11, 15	ready	all additive & subtractive features now have at least one test
transformations	3, 3	ready
dressup features	0, 0	ready
boolean operation	0, 0	ready

GSoC Week 3 recap

Kurt Kremitzki — Thu, 22 Jun 2017 16:15:49 GMT

Howdy! I wasn't sure of the best way to represent my progress thus far, but I figure a table is an alright way to summarize.

tool category	initial, current test count	status	notes
datum tools	0, 0	hold	waiting on attachment editor work in phase 2
add. & sub. features/primitives	3, 11	blocked	basic Pipe not working; when fixed, all tools in this category (but not all their options) will have test coverage
transformations	0, 3	ready	Mirrored added, still need Linear and PolarPattern
dressup features	0, 0	ready
boolean operation	0, 0	ready	Previously seemed to misbehave but recent changes to containers may have fixed this

I got my Pad & Pocket tests added, so right now the total Δtests is 11. Next up is Loft and Pipe. However, Pipe has a bit of a blocking bug right now. My test scenario involves a simple circle centered at the origin in an XY-attached sketch, serving as the base Profile, and a simple line on the Z axis in an XZ-attached sketch. The test construction is illustrated in figure 1.

This should result in a cylinder, as the preview indicates in figure 2. For some reason, when clicking OK, an external reference warning is being generated, and this is blocking any test constructions for PartDesign Pipe.

Figure 1. PartDesign Pipe Profile and Spine sketches which should form a simple cylinder.

Figure 2. PartDesign Pipe erroneously warning about external references.

I also ran into a bug in PartDesign Revolve, which, as bugs are wont to do, ended up being two bugs. The construction case to see them is depicted in figure 3.

Figure 3. Simple sketches attached to the three base planes.

I attached a simple circle sketch to each of the three base planes, and offset them so they wouldn't be symmetric with respect to the origin or any base axes. When attempting to add a Revolution with these sketches, they behave as expected, until one attempts to revolve them about the axis which is normal to the sketch's plane. For the XY- and YZ-attached sketches, the following error appears:

Unhandled Base::Exception caught in GUIApplication::notify. The error message is: Rotation axis must not be perpendicular with the sketch plane

However, if one tries to revolve the XZ-attached circle, FreeCAD gives it the ol' college try, but ends up with an awfully thin "solid":

Figure 4. An "error-free" PartDesign Revolution.

I'll also be looking into these bugs this week.

GSoC Week 2 recap

Kurt Kremitzki — Sun, 18 Jun 2017 23:40:33 GMT

With the four major bugs blocking the usage of PartDesign Mirrored fixed, I started out the week exploring the now-functioning tool with the goal of getting what I call "command test coverage". In short, this means testing major variations for tools presented to the user in the PartDesign WB.

For reference, they are depicted and categorized in figures 1 and 2, with the newly redesigned icons made by Alexander Gryson (kudos to his major rework of all of FreeCAD's icons!)

Figure 1. Datum tools, additive/subtractive features and primitives.

Figure 2. Transformations, dressup features, and multi-body boolean operation.

The Mirrored tool takes as input feature(s) and a mirror plane, but the other transformation tools like LinearPattern and PolarPattern behave in a fundamentally similar way. By that reasoning, I figured that tests regarding the Mirrored tool really only have two major permutations if one assumes valid input: the case where a choice of features and plane succeeds, and one where it doesn't.

Figure 3. Success!

Figure 4. Failure...

So, I cleaned up the test case submission I started GSoC out with, testMirroredSketchCase, and added the new case depicted in figure 4, testMirroredOffsetFailureCase. However, I noticed both of my test cases involved Sketch-based additive features, but no additive primitives. So, I also included testMirroredPrimitiveCase in FreeCAD PR#816.

What's nice is that besides PartDesign Mirrored now being fixed, several other transformation tools' bugs were resolved. Altogether, the PR resolved four issues, 2235, 2248, 3006, and 3065.

With all that wrapped up, I moved on to adding tests for the various options for the fundamental sketch-based features Pad and Pocket. Altogether, I added testPadToFirstCase, testPadtoLastCase, testPadToFaceCase, and testPadTwoDimensionsCase to cover the options for PartDesign Pad. Unfortunately, these test cases are not very interesting to look at and mostly involve 2-4 lined up cubes similar to what figure 3 looks like.

However, for PartDesign Pad, things do get a little more interesting. The base case is a simple reversed pad with a pocket in the middle, shown in figure 5.

Figure 5. The base Pocket test construction.

It was straightforward to add testPocketDimensionCase, testPocketThroughAllCase, and testPocketToFirstCase. However, covering the last Pocket option with testPocketToFaceCase is not (necessarily) so trivial.

If you refer to figure 5, you'll note that the base Pad feature is a hexahedron, or six-sided shape. The Pocket feature adds four new faces to the overall shape, Face7 through Face10. However, references relying on the numbering of those faces is inherently brittle and it turns out that a particular face number OpenCASCADE > 7.0 does not correspond to the same face in a lower version, e.g. the version used on the FreeCAD CI machines over at Travis.

GSoC Week 1 Recap

Kurt Kremitzki — Tue, 06 Jun 2017 19:28:12 GMT

The first week of Google Summer of Code has ended, and so it's time for a recap post!

The main topic this week was PartDesign Mirrored, a fairly self-explanatory feature, with a show-stopping bug explained in FreeCAD issue 3006.

Figure 1. The base of my PartDesign Mirrored experiments.

In this picture, we have a simple 1 mm square sketch (pictured in white) attached to the \(xy\)-plane. One corner is at the origin, and the sketch is the base for a Pad feature 1 mm high. Length is handled internally as mm by FreeCAD, so this "unit cube" serves as a useful basis for testing behavior. A useful alteration involves displacing this cube, say, 1 mm up the \(y\)-axis. This constructs a case where mirroring not all mirrorings should succeed, but we'll get into that later.

Let's turn now to the bug itself, depicted in figure 2. The unit cube is supposed to be mirrored about its vertical sketch axis (the \(y\)-axis, pictured running off to the top right.) Obviously, it's not, and the failure is helpfully represented in red.

Figure 2. FreeCAD bug 3006 in action.

Note that the body diagonal of the mirrored part should run from the origin to \((-1, 1, 1)\). Instead, it's going to \((1, -1, -1)\), in the opposite direction.

Well, this was my first really serious bug to tackle for the summer. I chose this as a way to really dive in, since it directly involves Open CASCADE, the open source C++ geometry kernel at the heart of FreeCAD.

However, my programming background is chiefly with Python (as well as JavaScript and Lua), all interpreted languages. One nicety of that sort of language is that it can be very quick to debug and examine behavior using the interpreter. There is a Python debugger, pdb, but I rarely needed to use it for my mostly personal-sized projects. Even then, it's quite straightforward to use since you're already in an interpreter-native environment.

C++ is a very different beast. In this case, stepping through the code with a debugger was my only choice. I use Neovim as my IDE, though, so I wanted a way to combine the power of my text editor with my debugger. So, I found and set up LLDB.nvim, an LLDB frontend, with an event-based, non-blocking UI, session-saving, and "... takes advantage of Neovim's job API to spawn a separate process and communicates with the Neovim process using RPC calls."

Pretty nice. Anyway, I was able to step through the code and see exactly what was flying around, just like I wanted.

Figure 3. Neovim in an LLDB debug session.

So, what was the problem? Hah! Not so simple. Turns out there are at least four bugs here!!

First, the algorithm which first checks if the mirrored shapes are adjacent and thus, can be fused, was broken.

Once this failed, FreeCAD then attempts to generate a mesh from the shape, and then converts a generalized transformation object representing the mirroring into a matrix to put the mesh in the correct place. It turns out that in Open CASCADE 7.0.0, the gp_Trsf API was changed so that gp_Trsf::VectorialPart() returns a 3x3 matrix including the scale factor. The previous behavior was to return the homogeneous part of the transformation which does not include the scale factor, and the FreeCAD algorithm for constructing the 4x4 matrix for the mesh included multiplying every term by a scale factor. In other words, the scale factor multiplication was happening twice. The scale factor I had observed in the debugger was -1, so this perfectly explained the inverted positioning of the failure result!

The third bug, of a much more minor nature, involved a a classic "failure... success!" message displayed in the event of a mirroring failure, and was easier to fix.

The fourth, though, was a bit trickier! It only appeared when fixing the mesh placement.

Figure 4. A strange, new mirroring bug.

This one was diagnosed by ickby, my mentor for this project. It turns out the failure meshes' faces were getting constructed inside out, and so the material's color was not considered "illuminated".

The three of us considered a few different options to get around this. One way would be to use Coin3D, FreeCAD's scene graph library, and change the material properties to define something that looked the same, illuminated or not. Another is to essentially duplicate each face with the second instance having an inverted normal, so that you're guaranteed to have an outward-facing face.

The fix ended up being much simpler than that! It was possible to simply change the vertex ordering. Originally, it was set to COUNTERCLOCKWISE. However, in figure 4, you can see that simply changing it to CLOCKWISE would not be an obvious fix. Abdullah also fixed this one, presumably by checking the docs for that option and finding that there was an "option C", UNKNOWN. That did the trick!

So now, PartDesign Mirrored is fixed and ready. Not a bad start for the summer!