ACIS

A geometry kernel is a big thing. It’s a huge thing. Maybe even big enough to see from space. By most accounts, even the Great Wall of China is not visible from space. However, other huge infrastructure is: highways, airports, bridges, and dams. This is the scale for this post. Decades of work, in a five topic flyover.

1. Creating 3D models

If you asked a guy on the street what a geometry kernel was for, odds are he’d reply "creating 3D models". Most 3D ACIS Modeler enabled applications create 3D models. And if you’ve read this far, you’ve probably created a 3D model at some point in your life. The basic steps haven’t changed a lot in the last 25 years.

Sketching is the process used to create a collection of curves, circles, ellipses, lines, and B-splines. Sketching is just connecting the dots, users input points and tangents, then applying constraints on a 2D grid. The collection of curves matches part of a design, or makes one up.

Curves can create surfaces by extruding, revolving, sweeping, or skinning. Surfaces can be trimmed and stitched to create solids.

The construction of primitive solids follows from specific parameters. This may include solids such as spheres, tori, cuboids, etc.

Finally, overlapping simple solids can be combined with Boolean operations like union and subtract to make a complex 3D model. In 3D ACIS Modeler, 3D models can also be non-manifold, combining solids, two sided sheet bodies and wires.

While all the above is standard fare for a geometry kernel, creating stable, fast high-level APIs for a geometry kernel is no small feat. One of the training exercises at Spatial for new 3D ACIS Modeler developers is writing a function to create a solid tetrahedron using low-level interfaces. It’s surprisingly hard - try for yourself.

I cover the other 4 essentials in my eBook. Please click below to download.

Debugging problems is really easy once you "have them under glass". Get all the input data, get all the code, build it on your computer, and you can bisect down on the problem in the debugger until you have fixed it. (Ok. This is an over simplification. Assume that you are really smart, can talk to someone who knows about the code you are looking at, and have an unlimited supply of time and coffee :-).)

In ACIS, journalling really helps with these problems but it has its limitations. Journalling is a feature of ACIS where you can call APIs with a special option setting which tells them to print a scheme script describing the operation, and save a sat file for the inputs. What are the problems? It is time consuming and unusual work to support. (How often to most ACIS programs manipulate strings? The c library for strings is really dangerous which makes this even more fun.) In addition, only APIs are journalled, but customers can all sorts of functionality. There are sg functions which are lower level and generally are not journalled. Then there are call backs (e.g., MESH_MANAGERs) which we don't even try to journal.

I dislike using C++ samples because it consumes a lot of time, but they have their place. Scheme scripts (or JS scripts for CGM Component) can distill a customer situation to just a bunch of solid modelling operations. A sample application often illustrates context. Sometimes an API call that seems to reveal a bug as a scheme script was actually caused by an application trying to do a workflow that doesn't make sense. Experience maintaining a solid modeler gives a person a warped perspective about what is natural.

I write this because I spent the better part of a day debugging a sample application which showed a problem that could have been journalled. I didn't know the problem could have been journalled, because I couldn't reproduce it. I had the sat file and the same code level of ACIS and a description of what the user was trying to do. It turned out that using facet_options_expert rather than facet_options_precise caused a significant change in the answer. Since the customer was using a GLOBAL_MESH_MANAGER that they wrote, I assumed some of the difference in behavior could be caused by that.

I guess it takes practice asking the right questions and getting a little creative about how to debug a problem. What is the craziest thing you have had to do to reproduce a bug?

Today, I’m going to talk about the way my attitude towards using namespaces has pretty much done a complete reversal over the last couple of years.  I started off thinking that they looked great, progressed to mild concern that they seemed to be causing unexpected difficulties, and eventually realized that they can become unmanageable if allowed to grow out of control.  Just like a bunch of tribbles. (Yes, the title is a Star Trek reference :).

  To jump to the punch-line, I’ve come to the conclusion that highly fragmented hierarchies of namespaces (such as are found in .Net and encouraged by the Visual Studio C# IDE) make life harder rather than easier.  Instead, I would recommend either name mangling strategies (incorporating an identifying string in the object name) or always using fully qualified names in your code (instead of “using” statements).

Phase I: Infatuation

  When namespaces were first introduced into C++, I thought they looked like a great idea.  It seemed wonderful to not have to worry about managing name collisions.  Unfortunately, for over a decade I didn’t have an opportunity to use them; my Physics codes were standalone executables (and so name conflicts weren’t an issue), and ACIS was written before they were portable to all compilers.  Actually, ACIS was written before they were introduced into C++.  In the tribble analogy, everyone else got to play with these cool critters but I didn’t have one.

Phase II: Nagging Doubts

This changed when I started working with C#, especially in my personal projects at home.  The .Net library makes extensive use of namespaces to indicate areas of functionality, plus the Visual Studio IDE assumes you want this sort of hierarchy in your code.  If you create a folder within your solution to manage an area of functionality, for example a Market component in an economics simulator with root namespace Econ, then the Visual Studio class wizard “helpfully” puts any classes you add to that folder into the “Econ.Market” (sub-)namespace.  And that is where the trouble started.  (If anyone knows how to turn this behavior off, please post a reply – I’ve been unable to find a way to do it.)

I quickly found myself getting frustrated by not having the correct set of “using” statements in my code, and having difficulty figuring out which “using” statements I needed to include.  For example, if I had a Trader class in a Actors folder (and corresponding namespace) and a Pit class in the Market folder, then I would regularly get compile errors when I tried to use the Trader class without “using” statement for the Econ.Actor namespace.  And the really frustrating part was that it wasn’t immediately obvious which namespace was missing – I would have to find the class then look to see which namespace it was in.  I now realize that the problem that I was running into is that namespaces (or more precisely “using” statements) lead you to write non-self-documenting code.  In other words, if I write the code

Market market = new Market(); 
GoodsType goodsType = new GoodsType(); 
Pit pit = market.GetPit(goodsType);

I don’t have any visual indication in that region of code as to which namespace Pit, Market, or GoodsType live in.  And if they come from several namespaces, I don’t know which “using” statement corresponds to which class.

This is very similar to the C++ “which header file declares this class” problem, for which a really good solution is to simply make the header name identical to the class name.  CGM uses this naming convention and I highly recommend it – you don’t have to think when writing your include statements.

Phase III: Regret

The final driver on my voyage of discovery was C3D development (in C++).  When we first started writing strong commands, I had the bright idea to use a namespace hierarchy to put a structure on the vast sea of commands we would be writing.  Unfortunately, it didn’t work out as planned.  Even though we only introduced a few namespaces, they still made life much more difficult than a simple name mangling scheme would have.  Part of the problem is that the compiler errors when you get the namespace wrong are not helpful:  we had to train ourselves to ask “did we get the namespace right” when we see an “undefined symbol” error for a class that we’re sure has the header included.  An especially nasty error occurs when you try to include a header file inside a namespace block (this typically happens if you’re using templates and so want to do another round of includes for the method definitions).  If I had it to do over again, I’d settle for a simple “_SPA” or “_CGM” at the end of each class name, e.g. Property_SPA rather than Spatial::Commands::Property.  In tribble language, I feel like Kirk standing awash in a sea of tribbles.

Phase IV:  Lessons Learned

The first thing to make clear is that I am NOT saying that namespaces are bad.  The fundamental problem that namespaces solve is the ability for application writers to manage naming clashes between libraries from different vendors.  I think it’s a great idea for every company selling component software to put everything into a single company namespace.

The problems I see come from trying to group classes into complex hierarchies, especially if you then use “using” statements to erase knowledge of the hierarchies.  I’ve come to the conclusion that any such grouping should be as simple as possible, and that the primary goal of the grouping should be avoiding name clashes rather than imposing a component structure on the classes.  The reason for this is that classes move between components fairly easily, especially if the component structure is very fine-grain.  If every time a class moves you have to do a major renaming effort (either to fix using statements or to rename the class) then you’ll generate a lot of worthless work for yourself.

With this in mind, I currently think a name mangling scheme, with the disambiguating string at the end is best, i.e. something like ClassName_NS.  The reason for putting it at the end rather than at the beginning is to help search – if you’re looking for class “Beagle” but are not sure which namespace you’re in, then you just need to look for “Bea*” in a list of all class names.

All of the above being said, I shudder to think about trying to solve this problem in a huge organization.  Would .Net really be easier to use if they had used the above naming scheme rather than relying on namespaces?

In my previous post, Creating a Better Documentation Experience, I covered highlights of our online documentation. This time we will dive into search methods, categories and navigation.

Using the Search Engine
The first, most obvious manner in finding what you need is to use the site Search. On the left side of your screen, the Navigation Side Bar contains a Search box with two buttons under it labeled Go and Search.

If you know the title of the article, the Search autocompletes your entry with one or more page titles (case-sensitive). You can then press the Go button and the Search takes you directly to that article.

Else, press Search if you simply want to search the text of all articles (this option is case-insensitive). You will be presented with a listing of Search results, or a message indicating that no matches were found.

For more tips on using the site Search, visit the Help on Searching page, which can be accessed by clicking Help on the Main Page (to the right of the Search box) or entering keywords such as help on searching in the Search.

Browsing by Category

Another method to locating what you need is browsing by Category. Spatial develops its product documentation on a MediaWiki platform. Therefore, each page is categorized so that you may find it by browsing the Category pages. You may choose to browse the complete list of categories, or you may choose to browse those specific to a product, such as ACIS, InterOp, or RADF.

Simply entering Category:ACIS Docs in the Search box will take you directly to that category and you will see that it has several subcategories, such as Advanced Blending, Components, and Local Operations.

Likewise, at the bottom of every technical article, notice that one or more categories are listed. This guides you to other similarly categorized pages and other related categories.

More Navigation Tips

And finally, as you browse through the articles, notice that many of them have breadcrumb navigation near the top of the page, or a See Also section near the end of the page. Following the breadcrumb trail takes you to a “parent” level page (usually a Portal page), while the links in the See Also section take you to related/recommended pages.

I hope this post helps you discover some key areas of our online product documentation, and helps you find what you need quickly. If you have any specific requests for future blog posts about our documentation, please leave a comment for us below.
 

My comrades and I did a performance analysis of Intel’s Hyper Threading Technology (HTT), using thread-safe ACIS and the ACIS thread manager.

In short, HTT turns one physical core into two logical cores and parallelizes instructions using available execution units to improve performance.

To be complete, we also wanted to analyze the impact of over-subscribing, since that is effectively what this technology (HTT) utilizes. So we created a test that loads and facets multiple bodies concurrently, with good work distribution. Then we ran it multiple times with a varying number of threads and with HTT enabled and disabled.

This graph shows that we experienced a 15% performance improvement with HTT:
 

Here is some detail about the comparison of hyper-threading and over-subscribing:

Hyper-threading

• The technology is logical vs. physical cores         
• It uses available execution units   
• Slight scheduling overhead (Can be seen in the graph)*
• Intel claims 15-30% performance boost        

*I find this quite interesting. Intel says it’s due to extra operations required to schedule serial operations on physical cores, not on logical cores.

Over-subscribing 

• More threads than cores (e.g. using 8 threads on a 4 core machine)
• Adds scheduling overhead (the scheduling system has more to deal with, which is different from the overhead mentioned above)
• HTT reduces impact (the performance impact of oversubscribing is lessened with HTT enabled)

In conclusion, the 15% improvement and the lessened impact of oversubscribing are well worth it.  We are now enabling it whenever possible.

Is anyone else enabling Intel’s HTT? If so, what level of performance boost are you seeing?