Looking Back on 2017

2017 has been an incredible year for me with lots of opportunities, but many challenges as well. In the spring, I got a (lab) teaching opportunity for a 50-student Measurement & Control of Biological Systems course, culminating in 17 teams making maze-solving autonomous robots. There's a higher level of mastery to be attained by teaching others, and in that regard, it was an incredible experience. Teaching, however, is well outside my comfort zone, and in that regard it had some difficulties.

In the summer, I was able to work on a Google Summer of Code project/pseudo-internship. Working in a mix of Python and C++ was again an interesting challenge since I'm much more familiar with the former than the latter, and even my experience with other languages lies on the Python side of the interpreted/compiled, dynamic/static typing divide. Still, it was an invaluable experience since C++ rules the domain of finite element analysis and computational fluid dynamics, which I want to explore further. Particularly, FreeCAD is the perfect vehicle for engineering computer modeling, so I have high hopes for my future with the project.

At the end of the summer, I passed the exam for the Linux Foundation Certified System Administrator. This was an opportunity provided by a scholarship given in part because of my work using Python to analyze the efficiency of backyard irrigation systems in the Yucatán back in early 2016, so it was great to finally see the culmination of that work. As a little celebration project, I decided to begin running my own Linux mail server, which has been a great success. There were a few hiccups with blacklists on Yahoo and Outlook, but I was ultimately able to get it working with all the major email providers.

I also embarked on a project I've been wanting to do for a long time: running my own Linux router. I found a great series of tutorials on setting up such a router using Ubuntu and the Pine64 board, and have had excellent results since.

I have also been spending time here and there researching a really promising project, FreeIPA. It's a sort of competitor to Active Directory in the identity management space, mostly made up of a combination of an LDAP, Kerberos, and certificate server. I'm running a sort of pseudo-small business in my home network using my FreeIPA server as a centralized authentication, authorization, and identity server, and it's been a great experience so far; I hope to apply it in reality with the FreeCAD project one day. Look out for future posts on the topic.

In the fall, I began my final year at Texas A&M. My capstone project and team was assigned. Our project involves analyzing the flood resiliency of the Houston area and proposing an ecological engineering design to improve that resiliency and mitigate the effects of future extreme flood events such as was seen during Hurricane Harvey. We are using an open-source toolchain involving PostGIS, Python, and QGIS, and the project is really quite exciting since our analysis could be applied to other coastal cities and regions facing extreme weather events in the future.

Altogether, it's been a great year, but I foresee 2018 being even better. If you're reading this, I want to wish you a happy new year with hope for the same!

GSoC Week 12: Final Work Product

Well, it's time to finally wrap up the summer!

It's been a really great and rewarding opportunity, so I first want to thank everyone at Google and beyond who helped put GSoC together, as well as my mentor Stefan Tröger for providing feedback and guidance.

I was able to work with code that ranged almost the entire stack of FreeCAD dependencies: from low-level OpenCASCADE code involving quaternions & transformations, geometry & topology; to the scene graph library Coin3D we have to thank for our pretty screenshots; the connection between C++ and Python code, which I have a feeling will be useful later in my engineering career; and all the way up to the Qt GUI in both C++ as well as its Python interface PySide.

As a result, I feel very prepared to continue working with the FreeCAD project and look forward to doing so. I really think it's a great program and hope to use it for many years in the future.

So again, my thanks!

The main goal of the project was to get test coverage of the Part Design Workbench, and to explore it to find showstopping bugs. The only remaining one involves a crash in ShapeBinder, discussed at https://freecadweb.org/tracker/view.php?id=2517.

I fixed quite a few bugs and I think the general experience with the workbench is better. Test coverage is there for all the tools, and I'd say the workbench is ready for the public, so now the major work is to release FreeCAD 0.17, the biggest FreeCAD release ever, with its new Part Design (no longer "NEXT") Workbench.

My other goal of improvements to Boolean Operation was made unnecessary by someone else's PR in May.

The last goal, improvements to the Attachment Editor, ended up being a little too big for this GSoC, and could even possibly serve as a good GSoC project for next summer, although whoever does it had better be fairly artistic at making explanatory yet small icons.

In my opinion, I'd say the summer was a success.

Altogether, my code contribution can be summarized with 7 PRs and one experimental branch:

PR's:

  1. https://github.com/FreeCAD/FreeCAD/pull/816
  2. https://github.com/FreeCAD/FreeCAD/pull/829
  3. https://github.com/FreeCAD/FreeCAD/pull/848
  4. https://github.com/FreeCAD/FreeCAD/pull/869
  5. https://github.com/FreeCAD/FreeCAD/pull/899
  6. https://github.com/FreeCAD/FreeCAD/pull/920
  7. https://github.com/FreeCAD/FreeCAD/pull/957

Experimental Attachment Editor/PartDesign Datum Tools branch:

Here's my summary posts, summarized:

  1. /blog/gsoc-week-1-recap/
  2. /blog/gsoc-week-2-recap/
  3. /blog/gsoc-week-3-recap/
  4. /blog/gsoc-week-4-recap/
  5. /blog/gsoc-week-5-recap/
  6. /blog/gsoc-week-6-recap/
  7. /blog/gsoc-week-7-recap/
  8. /blog/gsoc-week-8-recap/
  9. /blog/gsoc-week-9-recap/
  10. /blog/gsoc-week-10-recap/
  11. /blog/gsoc-week-11-recap/

GSoC Week 11 Recap

Unfortunately, it looks like solid, usable improvements to the Attachment Editor are unlikely to be ready for a PR by the end of my GSoC, although I will publish my experimental branch which uses Python for the datum tools and uses the Python-based Attachment Editor I mentioned previously.

However, as a consolation I did finalize some additional tests for PartDesign Hole, so my goal of functional coverage of the PartDesign tools succeeded.

Also, I think with this foray into GUI code, I've hit nearly the full stack of libraries used in FreeCAD this summer. It feels pretty nice, because I feel prepared to tackle whatever problem I want to in the FreeCAD project.

GSoC Week 10 Recap

The final portion of GSoC for me will be dedicated to working on improvements to the Attachment Editor, and this post will essentially be my design for what those improvements will look like. The Attachment Editor is available in the Part Workbench through Python. One can for example create a simple Part Cube, select it, then click Part -> Attachment. It also is used when creating datum geometry in Part Design, or when creating a primitive.

Here are a few screenshots:

command palette

Figure 1. The Python-based Attachment Editor in the Part workbench.

command palette

Figure 2. Creating a Datum Plane.

Creating datum geometry is a key part of the Part Design process, so it's helpful for it to be very easy and intuitive. The current Attachment Mode information especially can be quite overwhelming to a beginner, however. Especially considering how improvements to the Attachment Editor could be reused in a future Assembly Workbench, it was decided to look into improving these tools.

The first, most obvious improvement here would be inactivating the "Extra placement" section when inactive. This could possibly be accomplished by making a separate collapsible section which automatically hides when there is no attachment.

The second, and tougher improvement, involves reworking the current the four attachment selections and the attachment mode. Reference names probably don't need to be more than 3/4ths the width of the page. The methods for selecting references via an activation button, and deleting via clearing out the text are not user-friendly.

The four-reference list here would ideally be replaced with an icon-based grid, which starts out empty. Each selection's icon would be based on its type, e.g. Vertex, Edge, Face, Curve, etc., where available, and a generic icon for unrecognized types. The selection's name could be displayed in a shortened form, e.g. "MyLongShapeNameIs...". This approach could be extended for future Assembly use by adding a scrollbar on the icons, allowing for several rows of attachment references, 4 at a time.

This tool could be very user-friendly, as invalid reference icons can be highlighted red, and when the attachment is complete, the reference set's icons can be highlighted green. Ghosted icons can be displayed as needed for a selected Attachment Mode.

A similar approach for Attachment Mode could be used. Using a 4-icon row with a scrollbar, attachment modes can be explained with a short label and an icon, where feasible; hopefully the large size will allow for expressive icons. When a mode is moused over or selected, the remaining references required can be displayed in the reference selection area.

Altogether, (i) splitting out the placement and toggling when it has no effect (i.e. there is no attachment) and (ii) reworking Reference Selection and Attachment Mode dialogs to use unified icon list GUI code, as well as (iii) making the icon set to explain the attachment concepts to users, comprise the components of this "Attachment Editor Improvement" project.

GSoC Week 9 Recap

I celebrated my birthday in south Texas last week! I was about 3 miles from the future SpaceX launch facility opening in 2018. It'll be great to possibly see launches to Mars from there in the next few years.

I mostly spent this week working on the bugs I mentioned last week. I wanted to try to make a dent in the outstanding bugs I've found. Unfortunately, my lack of C++ background (compared to Python) really hampered this; it's a little bit like trying to run before you walk. In the end, I only fixed the Revolution bug(s). In the case where a revolution is attempted on the same plane as the sketch, resulting in e.g. a flat disc, the issue was that the code was checking the angle between the sketch's normal and the revolution plane's normal, looking for a 0° angle. However, it was failing to fail in the case of a 180° angle.

I also added a simple convenience check for all tools in Part Design: if you open a document with only one body and try to click a PDN tool's button, the single body will be auto-activated instead of popping up a warning. If there are no bodies or more than one, the warning still occurs.

GSoC Week 8 Recap

Total tool coverage lasted less than a week! It's a good thing though, because that means a new tool landed in master: PartDesign Hole.

Part Design Hole tool

This is a really great tool for the Part Design WB not only because holes (and their corresponding fasteners) are ubiquitous in part design generally, but also because the tool does a good job of capturing that information into a FreeCAD object that can be later be hooked into for both the Assembly and TechDraw workbenches. For example, the options I've selected in the following screenshot could be used to complete a technical drawing for this part in FreeCAD, and that information exchange could be done in an automated and customizable way.

Part Design Hole tool

This information could also be used by the Path WB to generate control code for open-source, automated manufacturing processes and machines, so it's really great to have such a full-featured tool added.

I spent some time trying to find bugs in the tool, but didn't really find any. The only gotcha I noticed is related to the orientation of sketches which serve as the basis for holes. There is no Reverse option for the Hole feature itself, so for example, if you have a sketch on the "bottom" of an object but not attached to it, you may need to set the Map Reversed option for the sketch itself to true.

Some tests will be forthcoming for Hole, but besides that, I also spent some time looking at few outstanding bugs in C++-land.

Particularly,

  • (mentioned in week 5) ShapeBinder crash when base object not initially selected due to null pointer dereference
  • (mentioned in week 3) Revolution has unhandled error for some bad revolution axis choices, does bad revolution without error for others
  • (new) Pipe fails when its path is a loop. For example, a Pipe with a circle as a base and a larger, orthogonal circle passing through the base should become a torus. Currently, it fails with the wonderfully verbose error message 'TopoDS::Shell'.

GSoC Week 7 Recap

I hit a nice milestone this week! With PR 899 I hit total tool test coverage for the Part Design workbench. Now, what exactly does that mean? Well, if you look at my screenshot of the workbench tools from Week 2, every one of those is now covered by tests with most key functionality hit. Some of them, like the dressup features Fillet and Chamfer, only have one test, either because the tool is simple or because further tests lie outside the scope of the Part Design workbench (e.g. testing the topological naming robustness of Fillet to recalculation.)

The PartDesign Primitive (Box, Cylinder, Sphere, Cone, Ellipsoid, Torus, Prism, and Wedge) tests were interesting to write. I was able to cover basic construction of both Additive and Subtractive primitives of each type by simply making a large Additive Primitive and smaller Subtractive Primitive inside the first, and then ensuring that the ensuing Shape's Volume property was about equal to the difference in volumes according to the formula for that shape, e.g.

\[ \mathrm{Shape.Volume}\ \approx V = \frac{4}{3}\pi (R^3 - r^3) \]

for Additive-\(R\) and Subtractive-\(r\) Primitive Spheres. I had to look up a few volume formulas but otherwise the tests for the lengthly list in the parentheses above went quickly.

I also fixed a bug with Loft sections not being hidden, so e.g. the Sketches being lofted to or through were still visible.

Additionally, there was an issue with both Loft and Pipe not claiming children correctly in the tree which I fixed.

GSoC Week 6 Recap

Short post this week! I was in Spokane, Washington, from July 15-19th for a robotics competition being held at the Annual International Meeting of my professional society, the American Society of Agricultural & Biological Engineers, or ASABE. I only had a smattering of time to work on the various FreeCAD bugs I have mentioned in previous posts so there isn't much to report on that front. Instead, I'll leave a picture from the beautiful Spokane downtown area.

/images/gsoc-6-1.jpg

GSoC Week 5 recap

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

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