A better way to develop software?

Dave Wilson talked to Chris Burkett at Flow Solutions, a user of Matra Datavision’s new CAS.CADE software environment, to find out how easy it was to develop a standalone CFD product

In the past, developing engineering software for the CAD/CAM marketplace has meant that engineers were tied into software development tools provided by a particular CAD vendor. Because these tools were so product specific, they did not offer the software developer a way of writing code that could run in a stand alone mode. Worse still, most could not be used across many different computer platforms.

Indeed, the tools tended to be so specific to one particular CAD package, that software developers familiar with one programming environment were reluctant to face the learning curve associated with another. Hence islands of software expertise were created relating to each software package.

While this may be to the advantage of the CAD software vendors, it provides a problem for software developers who would prefer to write programs that could be used by more than just one group of designers.

Breaking the stranglehold

Before Matra created its new generation of CAD/CAM/CAE software, Euclid Quantum, it first concentrated on providing its own developers with a STEP-compliant application framework to build their applications. The framework incorporates a set of reuseable C++ objects for a number of different operations, including geometric modelling, parametrics, computation, documentation and databases.

One of the aims of the framework was to break the old proprietary stranglehold on developers. And to prove the point, Matra itself used the CAS.CADE development environment to develop its own new set of packages: Euclid Designer, Analyst and Machinist.

The CAS.CADE architecture is divided into several subsystems. These comprise a Dialog Engine, a Front-End, an Application Engine and the Database itself. Software application developers need to be aware of how these subsystems interact before embarking on a software design.

For its part, the Dialog Engine is simply responsible for the `look and feel’ of the application. It defines features such as a multiple view interface, a main window with a menu bar, two columns of icons, one status bar as well as a collection of reuseable widgets. Common to all CAS.CADE applications, the Dialog Engine is dynamically linked to the Front End. On UNIX operating systems, it is implemented in Motif and contains the physical event loop. Standard events are processed in the Dialog Engine, while other application dependent events are sent to the Front End.

The Dialog Engine manages the user interactive aspects of the application. But because applications may consist of several different processes, all of which may be running concurrently, the Dialog Engine is also responsible for co-ordinating the communication between these processes, acting as a method for interprocess communication between the system software components.

The Front End reacts to the events that are triggered by the Dialog Engine. It calls commands both in the Dialog Engine (to control the dialog flow) and in the Application Engine (to execute the action).

For its part, the Application Engine executes the requests sent to it by the Front End. It implements all the functionality that the user expects from the application: object creation, visualisation and object selection, algorithmic behaviour and data storage.

The Application Engine itself is a separate process controlled from the Front End. It comprises reuseable interfaces which are implemented from object libraries. In reality, any given application may have many `Engines’ that are distributed over the network.

This has its advantages. The user of a Silicon Graphics station running a solids package, for example, may be unaware that the modelling performed by the Euclid Designer module is actually running on a Sun file server across a network, not specifically on his own Silicon Graphics machine. While the front end to the package, however, might well be. By distributing the application, network resources can be optimised and the performance of the system enhanced.

The Application Engine also communicates with the Database. Because object-oriented-technology is used throughout the CAS.CADE environment, the Database itself is also object oriented, comprising a schema that defines how geometrical objects are stored. The user is able to access the objects from the Database for importing to his own `engine’ and then displaying on screen via the front end.

For the software developer, the modularity and independence that CAS.CADE provides is very important too. Not in the least because it also applies to an object toolkit written in C++ that software developers can reuse in their own applications.


One such developer who has made use of the CAS.CADE environment, and specifically, the object toolkit, is Chris Burkett of Flow Solutions. A specialist software developer and consultancy, Flow Solutions has developed two specialised aerodynamic software CFD packages based on the CAS.CADE environment. These are used for the solution of pressure distribution problems about external configurations like aircraft or motor cars.

Newpan, one of Flow Solutions’ CFD packages, has already been used by several Formula One and Indy Car racing teams to predict the aerodynamic characteristics of racecar configurations. In addition, it can also be used to determine the influence of wind tunnel walls and support structures that are employed in traditional aerodynamic testing programmes. Another package, Pansak, is aimed at tuning the design of yachts, having been employed on New Zealand’s victorious America’s cup challenge in 1995.

For Burkett, “the CAS.CADE product provides a software development environment that gives companies who write a lot of customised programs the opportunity to create a stand alone product that can run on many different platforms”.

What is more, developers like Flow Solutions can be selective in the use of the reuseable class libraries that are used from the CAS.CADE toolkit. They can elect to use just part of a library relating to surface modelling if they so wish, or the other parts of the toolkit that encompass user interfaces, documentation, or object structure databases.

Flow Solutions had some exacting requirements while developing its application software. First off, it was important to develop software that designers could seamlessly integrate into their existing CAD environments. With that it mind, it was important that the software would allow data to be imported from other CAD packages using standards such as IGES and STEP. But more importantly, the software also needed to be able to manipulate the raw CAD data as surface descriptions, and then create a mesh of grid points, which would be input into its flow solver software.

Because of the requirements of aerodynamic analysis, Flow Solutions also needed to be very exacting about the grids that were used to obtain the best definition of the flow field features. In certain instances, the mesh might need to be tightly distributed around the leading edge of an aerofoil to accurately capture the air distribution, for example.

To accomplish the task of developing software to meet these needs, Flow Solutions was faced with developing a pre-processor for its CFD product. In the search for the optimum way to develop such a product, it decided to make use of the CAS.CADE development environment.

“The CAS.CADE environment draws upon the 20 plus years of Matra’s solid and surface modelling functions to provided a low-level set of functions, in this case, a class library of C++ functions,” says Flow Solutions’ Burkett. This allowed the company to bolt together components to create a custom product while choosing from a number of graphical front ends and development toolkits.

“By capitalising on the expertise of Matra in developing solids and surfacing routines for their own CAD systems, we found that we could create an accessible stand alone product,” he adds.

Large software projects

The CAS.CADE development environment has been defined to manage large software projects. Many CAD software design projects are very large, and many lines of code need to be managed. But using object-oriented technology, software developers can focus on just one aspect of the program development at a time. This provides a clear definition of particular responsibilities, as well as highlighting how one part of the software will interact with code developed by other co-developers.

To help out, Matra Datavision developed a description language called CDL (Cascade Definition Language) that is used to describe various parts of a given application. Matra developed such a system of structured programming methodology as part of the CAS.CADE setup to avoid some of the complexity and dangers of using C++.

“Because C++ is very powerful, it’s also easy to abuse it, and what is required is a very stable subset of the C++ language used in a consistent form, which is what the CDL language provides,” says Burkett. CDL also describes how C++ classes are grouped into packages and how the packages interact.

Once created, CDL descriptions are compiled to produce C++ header files and template files. The software developer then uses these templates to write specific parts of his code. The CDL description file acts both as a framework for describing the functionality appearing in that class or package, and how it interacts with other user-designed classes.

The actual libraries in CAS.CADE are also written as C++ objects, and are each provided with a CDL description. The objects themselves form a hierarchy. For instance, all types of geometry inherit from a class geometry. Various operations can be performed on the higher level classes, for example transformations, scaling, and general methods that apply to any geometrical object.

Surfaces and classes

Then, there are various descendants from class geometry, such as surfaces, curves, lines and points. In the case of surfaces, there are particular specialisations of surface classes too, such as Bezier surfaces, b-spline surfaces, quadric surfaces. These inherit from their class surface, which in turn inherit from the geometry itself.

In this way, the library of functions can be used to build up the operations that a developer may need in the development of his own application program.

In order to communicate information to the user, objects that need to be visible to the Front End must be exported as visually presentable objects.

In the case of the CAS.CADE product, the Front End is interpreted, and uses Lisp-based scripting. The front end has various high level components that are useful to developers for displaying graphics. It allows the user to rapidly build graphical user interfaces from various components like pull down and pop up menus, viewers. It also has a 3D viewer component that can be inserted into the application that automatically provides for the display (3D rotation, translation, scaling) of graphical objects, which is useful for developers.

There are some disadvantages to interpreted languages, however. Ease of use is traded against performance. An interpreted front end will always be slower than an equivalent compiled application.

For its part, Flow Solutions decided not to use the CASCADE Front End, because of the development work that the company had already done using Motif-based graphical user interface components. Because it developed its own X-Windows interface, Flow Solutions did not need to create an `engine’ to interface its package to CAS.CADE. “But developers who plan to use the Matra front end would need to go that route,” says Burkett.

“For our initial implementation, we are not using the CAS.CADE front end but an X-windows C++ based Motif compiled front end that we are able to interface to the CAS.CADE toolkit quite satisfactorily,” says Burkett.

“We feel that Matra are very strong in solid and surface modelling and we wanted to use those parts of the product predominantly. The object toolkit is the strength of the product and those are the parts of the product that interest us as a company most,” says Burkett.

As software developers, Flow Solutions has developed grid generation applications within many of the contemporary CAD systems like Euclid and CATIA, and has experience of using the application programming languages of various CAD systems.

Because Flow Solutions also wanted to replicate that work in a stand-alone package using CAS.CADE, it focused on using just the parts of the CAS.CADE object libraries that were needed for surface modelling. It also picked some of the elements of the development environment that CAS.CADE does well, using them in conjunction with other development tools to create the application.

Burkett admits that he didn’t use the entire CAS.CADE toolkit partly because of time constraints, and partly because his overriding requirement was simply to use a high quality set of surfacing functions that he could integrate into his own environment. Burkett is still debating how much of the development environment, such as the Front End and the Dialog Engine, he will use in the future.

{{Flow SolutionsTel: Bristol (01179) 736497Enter 500