WorldCAD Access

Standards for collecting point cloud data

3" or 1/4"

 

3D point cloud data (nothing to do with storage or computing clouds) recorded by high-speed laser measuring devices are the new norm for data collection, inside and out. They are used to produce large-size scans of roads, buildings, and manufacturing plants. Versions are available also for small size scans, such as of just-manufactured parts and car bodies. 

The problem of raster has dogged it since it was invented: the higher the resolution (ie, more accuracy), the bigger the file size. For 2D images, like photograph, the increased file size is by the square: twice the resolution make the file size 4x bigger. Compression schemes, such as ZIP and JPEG, reduced sizes by about 10x.

For 3D laser scans, the problem is cubed: doubling the resolution makes the file size 8x bigger (2x high by 2x wide by 2x deep). While storage space is dirt cheap these days, and new algorithms tackle the problem of billion-point files, there still is the time it takes to collect points. So there is an interest in balancing resolution against file size. 

Defining Accuracy

The Massachusetts Association of Land Surveyors & Civil Engineers (MALSCE) has taken a stab at the problem, last month releasing a brief Best Practice Guidelines. In brief, the guidelines recommend lower resolutions for feasibility studies, and higher resolutions for construction documents.

3"-resolution (coarse) laser scan

Different stages of a project gain different levels of accuracy:

Level Purpose         Precision     Accuracy       

D     Feasibility     Undefined     n/a

C     Planning        3"            0.25'

B     Design          1/2"          0.10'

A     Documentation   1/4"          0.04' (half-inch)

1/4"-resolution (fine) laser scan

The Guidelines note that surveyors should be aware of insufficient control and target checks, vibration during scanning, wind, and shadows from blocked areas.

Download the PDF from http://files.engineers.org/file/MALSCE-Point-Cloud-Standards-V1-9.pdf

 

 

A.I. for classifying point clouds

Learning how to paint by numbers

 

Does AI have to actually incorporate artificial intelligence to be called "A.I.?" With failures of AI  becoming increasingly publicized, some industry commentators have taken it calling it "actually ignorant."

Never mind the insult. Any time I get a press release landing on my desk touting A.I., I cast a gimlet eye upon the text. Most recently, this was from a Berlin firm named Pointly, which, in fact, is owned by a larger Germany company Supper & Supper (as in dinner).

Pointly says that we can upload a 3D point cloud to its servers and then tag items with color, to identify them. For instance, tag walls of houses on a street in blue, roofs in red (the traditional color in Germany for roofs), and the street itself in light blue. I tried it out, and found that I was working with what felt like the flood tool of paint program from the 1990s. See figure below. It did not feel like AI. Or, if there was AI, my brain was the intelligence behind the artificial.

Flood-filling areas of a 3D point cloud

 

So I asked the firm what was going on. It turns out that I had tried it out too soon:

Pointly, which is live now, is a tool for accelerated manual classification of point clouds. Features for automated processes in Pointly will follow and are being developed [currently].

So, Pointly eventually will figure out what I am doing and, hopefully, start doing the color classification itself. "We want to implement self-learning algorithms," the spokeswoman told me, "So that the more point clouds you label the more the neural network learns and the following labeling work becomes way faster, because the network learned from the work you’ve done before."

Pointly, as part of data science firm Supper & Supper, is trying a few different things, of which flood-fill is one. Other examples include A.I.-supported automated object recognition and CAD model generation from laser scans of freeways. Use-cases include the following:

• Tree inventory (see figure below)
• Road sign and lamp post inventory
• Road mapping
• Building modeling with roof & wall surface analysis
• Change detection in gravel pits

Identifying stumps and trees

For more on Pointly, see https://pointly.ai/

 

Autodesk joins Open Design Alliance

IFC, not DWG

 

Autodesk and the Open Design Alliance are today announcing that the former joining the latter for the ODA's expertise in IFC (industrial foundation classes), used for data exchange in the AEC world. 

The news comes as a shock to those who know the history of Autodesk's law suits against the Open Design Alliance, as well as the history of the ODA being formed originally to open up the DWG format, which, at the time, Autodesk refused to document. ('We have an open format, it's called DXF', was the famous excuse from Autodesk at the time.) Given that Autodesk repeatedly for years also sued a number of the larger members of the ODA, I wonder how well the news is being taken internally -- on both sides.

 

IFC Only

Autodesk's only interest in the ODA is for its IFC libraries, now that BuildingSmart has made the ODA the official supplier of APIs and SDKs. BuildingSmart is the organization that defines the content of IFCs.

The move is steeped deeply in irony, as it was Autodesk itself that came up with IFCs (and object enablers) to solve the problem created by AutoCAD Release 13's user-definable objects (a.k.a. custom objects) -- how to exchange data between AutoCADs that don't understand specific custom objects. Autodesk later handed the troublesome IFCs to an external organization, who, over the decades, expanded IFC to become the de facto exchange format among BIM and AEC programs.

To this day, custom objects continue to dog DWG editors, just as IFC remains an unsatisfactory exchange medium, except that there is nothing that improves on it.

 

The Reason(s)

Autodesk's joining of ODA is part mea culpa and part cost savings. As Autodesk said in a blog post today:

In one of my recent posts responding to some of the constructive criticism we’ve received from our architecture customers, we promised to do a better job of listening to our customers, engage in an open dialogue, and do better where we’ve fallen short.

One of the areas highlighted was progress with our products on international data exchange standards, specifically the need to better support IFC, an open file format increasingly used by our AEC customers.

The cost savings come from the ODA charging relatively modest fees to access its APIs and SDKs as compared with other tools providers. Autodesk, I believe, was already using someone else's IFC toolkit, which I suspect may have cost the company more in license fees.

 

No DWG

Another surprise is that the agreement is for IFCs only, no access to DWG or contributions to the same. As it is Autodesk that defines the DWG format, I would have thought they could -- finally -- start contributing to the ODA, so that there is no longer that six-month lag between Autodesk changing the format and the ODA releasing its APIs to  members.

On the other hand, Autodesk is showing less and less interest in AutoCAD. At one time, Autodesk was changing the DWG format every year. Upon complaints from customers and third-party developers, it promised to change it only once every three years. Now the company can go five years and longer with no changes. This is good, as it brings stability to the entire DWG editor industry.

So, perhaps the ODA doesn't need Autodesk's contributions to DWG, especially as it is the ODA has taken the lead in enhancing the DWG format.

 

 

Here's what's new in DWG from Open Design Alliance

New for 2020

 

The Open Design Alliance has taken over in setting the pace for advances in the DWG file format, now that Autodesk seemingly has lost interest in its best-selling software.

At last week's online DevCon developers conference for members of the ODA, we got shovelfuls of information on what's new in DWG. It overwhelmed us journalists in attendance and so we asked for a summary list, which was promised for this week. Here it is.

 

PDF & DGN Import and Export

Improvements to importing PDF files into DWG databases:

• Import full lines of PDF text as MTEXT
• Import linetypes
• Support for clipped regions during import

PDF export now uses graphics caching to improve the performance in cases where multiple views of a model are exported to the same PDF file.

Microstation DGN export from a DWG database is new, so that the ODA now supports both DGN-to-DWG conversion and DWG-to-DGN conversion.

 

Revision Control

ODA’s native revision control for DWG is refactored for easier integration into real-world client applications.

The new implementation allows clients to more easily implement revision history for groups of related files, including non-DWG files.

 

Point Clouds

Conversion of point cloud data to Autodesk's RCS ReCap Source format.

Automatic level of detail selection for RCS point cloud visualization supports fast visualization and manipulation of large RCS point clouds.

 

Model Documentation

New VIEWSECTION, VIEWBASE, and VIEWPROJ commands create model documentation (2D) views of models. See figure.

Documentation views generated from a 3D model

 

Saving model documentation views to standard DWG files is in progress.

Precision hidden-line removal is in progress.

 

3D Modeling

Boolean operations (such as union and intersection) are now supported by the ODA Solid Modeler on OdDb3dSolids in DWG database.

Visualization for OdDbGeoData objects, which includes map data from third-party providers, is now integrated with the ODA visualization framework.

- - -

Contact www.opendesign.com  for more information.

 

How Programming CAD Goes On, Behind the Scenes

One hierarchy, many algorithms

 

From Ralph: We have no appreciation for the hard work that goes into modern life, whether food that appears magically in grocery stores, the tight-knit hardware-software of smartphones, and the code that goes into today's CAD programs. In this blog entry, which first appeared on the LEDAS blog, we get an inside glance of some of the thinking that goes on behind the code that goes into our favorite software.

- - -

by Ivan Rykov, LEDAS Group

Geometrical modeling projects often contain some form of central hierarchy of objects. A geometric kernel, for example, has a hierarchy of geometric entities. Another example is a geometric solver which has a hierarchy of objects and constraints. Simplified inheritance diagrams for these hierarchies are shown in the figures below.

Many routines/algorithms of other modules need to process all the entities in a hierarchy in a similar fashion, although with different implementation details. So, polymorphism naturally is used with these kinds of hierarchies.

Assuming we are talking about C++ (and this is usually the programming language of choice for algorithmic libraries in CAD), using virtual functions is the first consideration for implementing polymorphic behaviour.

However, a variety of routines applied to the entire hierarchy, or even part of it, is usually quite big. When speaking of geometric solvers, this would include translate/update (to systems of equations and back), validation (for constraints), auxiliary object calculations, technical stuff like serialization/deserialization, and UI representation.

A simplified hierarchy of entities in geometric kernel

 

A simplified hierarchy of entities in a geometric solver

 

If we were to place all of these function as virtual functions in the base, each of the derivative classes would clutter the hierarchy, create huge classes and break the “single responsibility” principle.

class Entity
{
public:
    virtual bool Validate() = 0;
    virtual void Update(SystemContext*) = 0;
    virtual void Translate(SystemContext*) = 0;
    virtual void Serialize(Stream*) = 0;
    virtual void Deserialize(Stream*) = 0;
    virtual void Draw(DrawContext*) = 0;
    // ...
};

Besides the problem of loading the base object with too many responsibilities (and thus making an ugly, hard to read interface), there are other problems with such an approach.

One of the problems is that adding a new algorithm to the system requires modifying all of the hierarchy, by adding a new virtual method to every class of the hierarchy. This not only affects compilation time, but also prevents any algorithms from being put into separate libraries/executables. For example, the Draw() method would be better implemented in the GUI application, instead of the core computational library.

Another problem arises when we need the algorithm to handle only the part of the hierarchy (e.g., only the constraints, but not the objects). In this case we either have to place the virtual function in the very base class (but then have an empty implementation in all the irrelevant objects) or else put it into the first suitable successor in the hierarchy. The former option additionally worsens the interface of the base class with irrelevant functions, while the latter requires to downcast objects to the required class in hierarchy, which breaks the whole idea of using the virtual functions.

The problems I mention here were really bothering us in our software projects, so applying a Visitor pattern was very beneficial in refactoring, which allowed us to make good progress in code organization.

From “switch” statement to virtual functions

Polymorphism provided by virtual functions is a core basis of object-oriented design, which allows client code to work uniformly with all objects in the hierarchy, using the interface of the base class. It is considered a major step forward, as compared to switch statements with downcasting.

Let’s look at these approaches with a simple example. (For simplicity, only two classes of hierarchy are shown and all names are simplified, keeping in mind that such names are highly not recommended for industrial code!) We assume a very common scenario, in which the client code works with an array of objects in the hierarchy, holding them as pointers to the base class. The switch statement implementation looks like this:

void SerializeEntity(Stream* s, Entity* e)
{
    switch (e->GetType()) {
    case tPoint: {
        Point* p = static_cast<Point*>(e);
        // put data of p into s
        break;
    }
    case tLine: {
        Line* l = static_cast<Line*>(e);
        // put data of l into s
        break;
    }
    // ...
    default:
        break;
    }
}

/// CLIENT CODE

void Serialize(Stream* s, const vector<Entity*>& ents)
{
    for (auto ent : ents) {
        SerializeEntity(s, ent);
    }
}

The virtual functions implementation distributes logic between classes of hierarchy, but no casting is required:

class Point : public Object
{
public:
    virtual void Serialize(Stream* s) { /* put data of p into s */ }
};

class Line : public Object
{
public:
    virtual void Serialize(Stream* s) { /* put data of l into s */ }
};


/// CLIENT CODE

void Serialize(Stream* s, const vector<Entity*>& ents)
{
    for (auto ent : ents) {
        ent->Serialize(s);
    }
}

It is worth noting that the switch statement version still relies on one virtual function, GetType(). Then we need to downcast to derived classes to extract specific information, such as the origin/direction of lines. A similar approach without using virtual functions is to employ a series of dynamic_casts with checks for non-zero results.

Everyone knows that using casts usually signals bad design, so there is no doubt that the first implementation is not well written. Casts (static) can cause undefined behaviour or (dynamic) require additional checks and slow down performance. Moreover, introducing changes to the hierarchy (such as adding a new type of object) requires programmers to look through all of the code in a search of “switch” and “if-else” blocks, and then extending them accordingly. This is what polymorphism was intended to resolve.

However, as discussed above, the virtual functions approach also has serious drawbacks. It fills the entity’s public interface with tons of functions completely unrelated to one another. Moreover, it spreads the algorithm’s logic (e.g., serialization logic, modelling logic, and so on) between different classes of hierarchy, and so between different files. This makes it harder to refactor, to extract common parts of the functionality — thus provoking code duplication.

So, we would like to have some kind of valid object-oriented solution that still keeps the code of the same algorithm for different types in the hierarchy close to one another (like in the “switch-case” approach), but avoiding the ugly casts. Visitor pattern provides us with such an opportunity.

… and “back” to Visitor

Let’s see how the visitor-based implementation looks like. (Note: in the real code, either Accept() function of hierarchy classes or Visitor class methods have to be implemented in a .cpp file to allow forward declaration and avoid cyclic dependencies; the code shown here is simplified for compactness.)

class Visitor;
class Entity {
public:
    virtual void Accept(Visitor& v) {v.VisitEntity(this); }
};
class Point : public Object {
public:
    virtual void Accept(Visitor& v) { v.VisitPoint(this); }
};
class Line : public Object {
public:
    virtual void Accept(Visitor& v) { v.VisitLine(this); }
};

class Visitor {
public:
    virtual void VisitEntity(Entity* e) {}
    virtual void VisitObject(Object* o) { VisitEntity(o); }
    virtual void VisitPoint(Point* p) { VisitObject(p); }
    virtual void VisitLine(Line* l) { VisitObject(l); }
};

class Serializer : public Visitor {
public:
    Serializer(Stream* s, Entity* e) :_s(s) { e->Accept(*this); }
    virtual void VisitPoint(Point* p) { /* put data of p into _s */ }
    virtual void VisitLine(Line* l) { /* put data of p into _s */ }
private:
    Stream* _s;
};

/// CLIENT CODE
void Serialize(Stream* s, const vector<Entity*>& ents)
{
    for (auto ent : ents) {
        Serializer(s, ent);
    }
}

Instead of a separate virtual function for each algorithm in the Entity class, we again have a just one virtual function, Accept(), responsible to dispatch any algorithm class, derived from Visitor, into the proper subclass of the hierarchy.

All the disadvantages of virtual functions in the base class are now eliminated:

• Entity interface is now clean, containing only one “technical” function for all of the algorithms
• Algorithm class now again holds together all the code related to the algorithm, so code duplication can be easily eliminated
• Visitor subclasses do not necessarily belong to the same module, so, for example, a “Drawer” visitor can now be implemented in a GUI executable directly, interacting with the corresponding canvas/painting classes

One of the drawbacks of the “switch statement approach” is back again: when extending the hierarchy with the new subtype, we need to check all the visitors to see which of them has to be extended with corresponding Visit… functions. However, searching for subclasses of Visitor is a much more regular task compared to looking for switch statements or casts to subclasses of the hierarchy — especially when we remember that some developers prefer to use C-style casts to using C++ casts. In fact, modern IDEs assist in this task, providing the ability to find all subclasses of a specific class.

In any case, in the projects we work with, the main hierarchy is usually formed at the start of the project, while various processing algorithms are added during the whole project lifecycle. Thus, we usually rather add new visitors than extend them with new processing functions. This really is the scenario for which Visitor is best suited.

Base Visitor class: abstract, or with empty implementations?

When implementing a Visitor pattern it is popular to make the base Visitor class abstract, leaving VisitSomething() functions purely virtual. This might seem a smart choice, because it will guarantee that all Visitors will be reviewed when a new class is added to the hierarchy. At the very least, an empty implementation will have to be added to each of the derived Visitors to compile.

However, we strongly prefer the implementation listed above: all functions of the base Visitor class have implementations, calling the Visit of the direct predecessor in the hierarchy. (The topmost class’ function is empty.) This leads to two benefits, as described next.

Implementation for the needed classes only

Some algorithms make sense for only part of the hierarchy. For example, we might want to draw only objects and not constraints. In this case we just implement the corresponding functions for the visitor, and so do not have to tediously list all of the other functions corresponding to the whole hierarchy.

class Drawer: public Visitor {
public:
    Drawer(Canvas* c) :_c(c) { }
    // Draw what you want only
    virtual void VisitPoint(Point* p) { /* ... */ }
    virtual void VisitLine(Line* l) { /* ... */ }
    virtual void VisitCircle(Circle* c) { /* ... */ }
private:
    Canvas* _c;
};

Compare this to the virtual base Visitor approach: you need a Visitor for, for example, just lines and points, but you have to list all, say, 30 classes of the hierarchy with empty implementations. There is a great temptation to write a couple of dynamic_casts instead. On the contrary, if you write a class with just two functions, you most likely will prefer that to the casts.

Common implementation for part of the hierarchy

If the processing of a certain algorithm is the same for all subclasses of some intermediate class of the hierarchy (for example, all constraints must be processed equally), then it is sufficient to implement a corresponding function of the visitor — VisitConstraint in our example. The following code demonstrates a trivial example of a common processing filter:

class ConstraintsFilter : public Visitor {
public:
    ConstraintsFilter(const vector<Entity*>& iEnts) {
        for (auto ent : iEnts) {
            ent->Accept(*this);
        }
    }
    vector<Constraint*> operator()() const { return _constraints; }

    void VisitConstraint(Constraint* c) { _constraints.push_back(c); }
private:
    vector<Constraint*> _constraints;
};

/// CLIENT CODE

vector<Constraint*> cst = ConstraintsFilter(ents)();

The sequence of calls is very elegant:

1. When particular constraint object (e.g., object of Distance class) accepts the derived visitor (ConstraintsFilter), VisitDistance() function is called
2. Since this function is not implemented in ConstraintsFilter, its implementations from the base class (Visitor) is called
3. Due to the implementation we showed above, Visitor::VisitDistance looks like this:

   virtual void VisitDistance(Distance* d) { VisitConstraint(d); }
   

4. In turn, VisitConstraint is a virtual function, which does have overload in the ConstraintFilter; thus this overloaded function is called and so the entity is added to _constraints array
5. Non-constraints fall into Visitor::VisitEntity() with empty implementations

Conclusion

Using the Visitor pattern in projects that have some kind of main hierarchy is a major architecture improvement that we like a lot and currently apply to many of our projects. It allows us to separate algorithms from objects, providing algorithm access to the subclass API to which the object really belongs. A typical project might have several dozen visitors, sometimes implementing just one-to-two functions for certain parts of the hierarchy.

Read more:
Fast Debug in Visual C++
How to Hack C++ with Templates and Friends
On C++ code bloat
Which Missing C++ Features Are Needed Most?

 

 

© 2020 LEDAS Ltd. All rights reserved. Reprinted with permission from https://ledas.com/post/864-why-we-use-visitor-pattern-in-c-cad-projects/

 

Design Master's Revit Survey 2019

Declining use

 

Design Master Software each year surveys MEP [mechanical, electrical, plumbing] designers about their use of BIM [building information modeling] software, which in this survey means Revit -- although "bim" was not defined so that respondents could apply their own definition. Since the survey began back in 2010, the annual results are now able to show a decadal trend.

The decadal trend reported by Design Master is this: that the use of BIM has not changed greatly over the last ten years, and respondents appear to be using it less for some purposes, contrary to predictions that BIM usage would, in general, increase.

The survey does not examine why Revit use is declining. Could it be due to firms discovering alternatives as Revit development stagnates and the cost of using it increases?

Now, be forewarned that the survey sample size is just 85 and respondents are only from USA and Canada, which is small against a number like the 118 firms worldwide that signed the "Rage against Revit" letter. The size of the surveyed firms does, however, cover a wide range, from single-person firms to ones with over 200 employees.

Here is a summary of results from Design Master:

BIM is being used less in 2019 than had been predicted by respondents in 2016.

The most popular use is generating construction documents.

In second places are BIM being used for 3D collision detection (somewhat less use over the years), Revit-format deliverables (falling steadily), and automated design/calculations (up over the years).

AutoCAD and Excel are used a lot to supplement BIM software, although they were the only two alternatives quizzed about.

Most firms do not charge more when required to use BIM; the exceptions are when they are required to use 3D collision detection or deliver work in Revit format.

For the full details and charts, see designmaster.biz/blog/2019/12/mep-bim-2019-survey-results

 

Addressing the problems of digital twins

Marketing loving it

 

Guest editorial by David Levin, isicad

 

Entities should not be multiplied without necessity.
     - William of Occam

Everything should be made as simple as possible, but not simpler.
     - Albert Einstein

- - -

It is difficult to get past the article entitled “8 Myths About Digital Twins Exposed — Here’s the Reality” by authoritative author Joe Walsh. Digital Twins (DT) is a fashionable topic today, actively marketed by lots of vendors. So it is a professional duty of industry experts to help the market understand what it really means.

 

What Digital Twin is Not

The first section of Joe's article lists and exposes eight myths about the technology. Some of the myths listed are

• There is a Single DT
• A DT Needs to Cover the Entire Lifecycle of the Physical Twin
• DTs Are Used Only by Engineering.

These I do not dispute. Others, however, need clarification or, within the whole set of anti-myths, seem superfluous.

I agree with Joe that the myths and uncertainties surrounding DT are beneficial to certain vendors who exploit the DT hype to sell traditional products just by adding innovative-sounding labels. In my opinion also, the hype around DT provides additional food for experts and media.

 

Do “Virtual Representation” and “Surrogate” Clarify Digital Twins?

Exposing the myths is helpful, because it explains what digital twins are not. The market, however, still wants to know what a DT is, and so the second half of Joe’s article explains it by giving a “usable standard definition” that came as a surprised to me:

CIMdata definition:

A digital twin is a virtual representation of a physical asset or collection of physical assets (physical twin) that exploits information flow to/from the associated physical asset(s). 

NAFEMS SMSWG (Systems Modeling and Simulation Working Group) definition:

The digital twin is a digital surrogate that is a description of a physical asset, such as products, processes, systems, people and devices, that can be used for various purposes. The digital twin makes use of data and information from the real-world asset and provides feedback to this real-world asset.

These definitions seemed to surprise Oleg Shilovitsky even more than me. Oleg clearly explained this in his must-read blog, Digital Twin Hype. Here are twoparagraphs from him:

Both definitions use vague words explaining that information can be used to get feedback about real objects’ behavior. The most interesting part is that the approach to use the information to analyze physical object behavior used in engineering disciplines probably as long as these disciplines existed.

Digital Twin is a cool name. I hope you agree. And I like this name.

Unfortunately, marketing did their job well and created a glorified definition and campaigns about Digital Twin that very confusing. In most of these presentations, the words Digital Twin can be easily replaced by something that is more thoughtful and pragmatic such as model, information, simulation, etc. Unfortunately, it didn’t happen and marketing keeps creating even more variations of digital twin marketing. I found these processes really damaging since as a result, we have Digital Hype and not Digital Twins.

 

Why Not Define Digital Twin as 'Advanced Modeling'?

I almost agree with Oleg completely. Almost – because I suggest replacing his words “Digital Twin can be easily replaced by something that is more thoughtful and pragmatic such as model, information, simulation, etc.” with “Digital Twin can be replaced by a model which can effectively communicate with the associated physical object.”

To be short, I use “object” to denote systems, assets, processes - everything which can be modeled.

Those who consider “model” as insufficiently concrete as compared with, say, “surrogate” may be thinking of an everyday concept in which a model is something that only superficially resembles an object in the real world. Yes, cloth dolls and plastic airplanes can in everyday life be called models of people and aircraft, but our industry understands models as defined by science and technology. In these domains, a model is always intended and built to accurately reflect the aspects of physical objects needed to study the object, as well as to control and optimize its behavior. The counterpart is constructed with as much precision as needed for particular applications and studies.

A constructive understanding of what a digital model is assumes that it involves a system that consists of the following aspects:

• Virtual objects that are associated with components of the physical object,
• Functions defined over the virtual objects that adequately reflect the properties of the physical object,
• Relations defined between subsets of virtual objects and adequately reflect relations between components in the a physical object.

In other words, a model is not just a virtual (digital) representation of a real object, but it also is by definition a virtual representation, which within is sufficiently isomorphic to an associated real object. Perhaps this interpretation of the model and its isomorphism may seem to some to restrict the idea of a digital twin. In reality, however, the definition is needed for meaningful communication, and communicating entities must have some shared compatibly interpreted subject domain (knowledge base).

I do not find it useful to imagine a digital twin as a black box, about which it is only known that it miraculously supports effective communication with the object in reality. If we were to have in mind such an understanding of a model, it allows us to conclude that if a digital twin is not a model it hardly can be useful anywhere.

A model-based approach to DT is of course not something that was just invented, even if the word “model” is not used explicitly. For example, see my favorite passage from Michael Park's article “Digital Twins Offer Unmatched Insights For Design Engineers”:

The basic notion is that, for every physical product, there is a virtual counterpart that can perfectly mimic the physical attributes and dynamic performance of its physical twin. The virtual twin exists in a simulated environment that can be controlled in very exact ways that cannot be easily duplicated in the real world, such as speeding up time so that years of use can be simulated in a fraction of the time.

These hyper-accurate models and simulations offer engineers and product designers unmatched insights across the entire product development cycle. Still, digital twins are more than just an evolution of digital models, although their goal is similar: Higher quality products and better product support at less cost and less effort. 

I like this clear and pragmatic explanation and do not consider “DT are more than just evolution of digital models” contradicts my emphasis of a model-based interpretation of a DT: it is not just evolution of modeling, it is the next higher level of modeling.

I believe that a digital twin need not a “hyper-accurate" model necessarily, as its usefulness does not directly depends on the number of parameters involved in modeling. I agree though that the hyper-accurate DT of an aircraft is hyper-valuable.

Is DT actually something new? A characteristic feature of DT is its capability to support regular bi-directional communications with associated physical objects. Note that such communication could be implemented by a human who shuttles between a model and the object being researched/controlled with the help of the model. A more pragmatic case is the communication between two people: the operator of a model and the operator of associated physical object. Perhaps such a process can be called a digital twin when, for example, it is the simulation of an (emergency) situation on a spacecraft carried out by the flight control center.

In fact, the fundamental novelty of the digital twin lies in the new level of efficient communications with physical objects (typically through Internet of things as some people believe). The key word is “efficiency” as it reflects the capabilities of today’s technologies that enable online, real-time communications between many objects of real world and their complex models – communications that can be implemented with practically any required level of performance, density, and reliability.

At the end of his article, Joe notes that, based on the clear definitions from CIMdata and the NAFEMS SMSWG, various forms of digital twins and their definitions can now be considered. He concludes:

There are multiple forms of digital twins for a wide variety of purposes. Each form of a digital twin has specific characteristics to meet its intended goals and should have a more detailed definition outlining the specific capability, functionality or implementation associated with that form of digital twin. The ASSESS Initiative has established a key theme and working group around Engineering Simulation Digital Twins and has provided the following definition of an Engineering Simulation Digital Twin:

"An engineering simulation digital twin is a physics-based virtual representation of a physical twin (physical asset or a meaningful aggregation of physical assets) that exploits information flow to/from the associated physical twin."

I do not consider the two basic definitions of DT to be intelligible. I completely agree that each form of DT should have a more detailed definition, and I think that if in the definition of Engineering Simulation Digital Twin we replace “virtual representation” with “model,” everything will be OK.

 

“Digital Twin” As a New, Useful Notion

So, in my point of view Digital Twins is a new advanced level of model.

Why would those involved in marketing DT avoid characterizing it as a model? The reason is clear: effective marketing requires new exciting words, and “model” is something too old, too familiar, and too boring.

Is it useful to denote new form of modeling by a new notion? New terminology is harmful if one considers the orthodoxy in the Occam's Principle quoted by this article's starting epigraph: "One should not multiply things unnecessarily." If, however, marketing honestly explains to the market the real and potential capabilities of new modeling tools, then the new notion can be considered useful.

The concept of "digital twin" is useful, and it will be successful when it stimulates the market. If we do not admit that something essentially new is behind a largely speculative concept, then we probably oversimplify the state of affairs and so do not listen to Einstein’s "Everything should be made as simple as possible, but not simpler" (Princeton books). In effect, when we want to follow Occam's principle, Einstein warns we should not throw out the baby with bathwater -- in other words, we should not go too far in our simplification.

Left: Occam; right: Einstein

A similar hype can be observed around "artificial intelligence." It is impossible to define AI constructively; therefore, we observe monstrous journalistic and marketing speculations abusing it. At the same time, however, useful AI solutions are gradually emerging in a fragmented way. Some of them even demonstrate useful approximations to what human intelligence can recognize as intelligence not produced by humans.

No amount of misleading hype can prevent the market from creating really new solutions and truly useful products that in time gradually will justify names as brassy as artificial intelligence and digital twin.

- - -

[This article is reprinted from isicad.net/articles.php?article_num=21408 with permission.]

Google, Stalker

Cyborgs vs. humans

 

When someone, who you don't want, follows you around, it's called stalking. The sole reason Google does anything these days is to stalk us. From killing software, to merging software, to offering new services, all have just one theme: to wrench more data out of us.

The reason behind killing useful products like Picasa? Google couldn't use Picasa to collect data on us, so it had to be replaced by online Google Photos, where Google could stalk us in real-time.

Google reads the metadata of each photo we store with it online. Metadata is information stored in each picture file, and it includes the obvious (date and time) and the less obvious (location and camera model). From that, its computers "learn" what locations look like, and when you were where. Take pictures of having fun at a restaurant and Google learns more about your travels and how busy the restaurant than it does by everyday tracking through your phone.

Location and unique ID metadata stored in a photograph

Instagram does the same when it urges you to write in a location: when you type in the location information, you are doing the work of fine-tuning a location that Facebook may have already gathered from the camera's geographic metadata.

Instagram asking me to tell Facebook where I was

 

(For a time, Instagram thought I was posting photos from Brazil. I wasn't, but I sure wish it would continue thinking so. OTOH, I am pretty sure that data stalkers like Facebook pose wrong answers to trick you into enter data. For a time, Facebook repeatedly asked me if I had gone to university in Lyon, France. That tactic was all it took for me to no longer fire up Facebook.)

Facial recognition, first launched in Picasa, links disparate photos together, as Google learns what it can from groupings of people. In Picasa, it was touted as a way to quickly find all photos of one person, but Google also had you doing learning work for it (for free) when it asked you, "Is this a picture of Jane? Is this another picture of Jane? Is this also a picture of Jane?"

Picasa sill asking for people's names after facial recognition is turned off

Evil

Google stated it wants to be the world's foremost information provider, but in order to do so it first must be the world's foremost information collector.

Marketing in the company's early years positioned the company as altruistic. "Do no evil" was a clever phrase designed to disarm the population from thinking too hard about what its software was doing behind the scenes.

I first realized Google wasn't being just the best search engine during the Google Books fiasco. Google offered authors and publishers a chance to host our books, and in exchange would pay us revenues from accompanying books sales. I liked the idea and was, in fact, a beta tester for Google Books, posting many of my ebooks even before it went official.

Then a serpent invaded the garden. Google announced that a shocking 30% of each book would be available free to the world. A page or two free, sure, but 30%? It got worse. By searching just four times, someone could read the entire book free. Then, it got worser. There never was any revenue from Google.

My HTML reference on Google Books

Eventually, we writers realized the purpose of Books was to read all the information in them to feed Google's voracious search engine. We see the same tactic occurring today when Google sees no value in paying newspapers to carry their content. Eventually, I pulled my books from Books (except for my HTML references book, for which I have received $0); I wonder if Google keeps copies to peruse at its leisure. When you erase something from the cloud, you can never know for sure whether it's actually been erased from the cloud.

That incident soured me on Google's initial idealism.

For me, the final straw came about with my experience using Google's voice input. Typing text on a phone is annoying, especially with the number of mistakes I make. So I tried voice input. At first, it was pretty bad. But I had read it takes a while for the google to learn your voice. So I gave it a chance, and then I was shocked.

Within two weeks, Google was transcribing my voice perfectly. Far from being pleased with the increased efficiency, I felt horror at the intimate intrusion of "me," as expressed externally by my words. The monster behind the multi-colored logo had gotten to know me too well, and I turned off voice input for good.

 

Resignation

So while I am resigned to using Android, I do all I can to frustrate Google's omniscient data collection. I turn off as many data trackers as I can in Android, being fully aware that Google remotely turns them back on from time to time and through dark UI practices "hides" options (figure below) and keeps settings turned on by duplicating them.

Google, dissatisfied with all it knows about me, wants to know more

 

I use Bing. I use Opera. I use VPN. I don't link devices and accounts. I minimize my use of GMail, Google Drive, and Docs. I don't use their other cloud-based offerings at all, such as Google Photos.

Should it come to it, I've bought a spare pair of non-Android phones that also act as long-range walkie-talkies.

Cascading

I suspect that the two founders of Google never intended to become Stalkers of the World. But, really, they had no choice. Consider the cascade of steps involved:

i. To provide all information, they needed to set up systems that could collect all information.

ii. To ensure the information was pure (unbiased), they had to set up systems that collected information surreptitiously.

iii. To maximize the use of their systems, they had to make their data collection systems pretty much free (Android, Chrome, Search) and then tout benefits while obfuscating drawbacks. As well, free meant they could attain a market share in data collection as close to 100% as possible.

Stalking is illegal. In Silicon Valley's twisted view, however, stalking is the highest good. Like victims who are stalked but receive no outside protection, all we can do is minimize our exposure to the stalker.

 

Revenge

I close with that curious incident which occurred shortly after Google got its first grown-up CEO. He was to have an interview with a publication, and so naturally the reporter did the right thing by researching his interview subject and learning intimate details using Google's own search engine. When the CEO learned of this "invasion of privacy," he boycotted the publication.

At the time, we scoffed at the elderly CEO's nativity about life in the Brave New World we were championing, but we could not know that the day would come when we would begin to feel like him. I wonder: was his final revenge on us having his company learn all about our intimate details?

 

 

ZwSoft Cuts Prices and Raises Prices

Targeting Autodesk

 

ZwSoft is offering free upgrades to network licenses. In doing this, it is aiming directly at Autodesk's discontinuance of our industry's normal approach to network licensing. (Autodesk now only sells a license per person.) The Chinese software company has software for DWG editing, machine design, some verticals, and for portable devices. It offers permanent licenses, maintenance subscriptions, and rent-to-own licenses.

 

How Network Licenses Work

Network licenses allow anyone at a firm to run as much CAD software as they need. Some might need CAD for just a few minutes a day, others use it all day. With network licensing, people who don't need it very much are not penalized by paying a full price, as Autodesk has now imposed.

A network license typically specifies the maximum number of instances of software that can run at the same time. If the limit is 10, then ten people can operate the CAD program at the same time. Network licenses are particularly useful for firms that employ shift work: ten users during the day, ten more during the evening shift, and ten during the graveyard shift. 

Because many more people can use the software than can with stand-alone licenses, network licenses tend to cost 30-40% more than stand-alone ones. Under Autodesk's new scheme, the firm would pay 200% more by having to purchase 30 licenses.

To track of the number of copies of software being used, firms deploy network licensing software on a central server. At times, there might only be one or zero people making use of the ten licenses. Maybe ten is too many -- or too few. Network analysis software logs the demand for software so that you can adjust the number of licenses appropriately.

Companies like Graebert Gmbh check your license use at the end of each month (of Kudo, in their case), and then accordingly adjust the amount you pay. In their scenario, you don't pay for too many licenses or work with too few.

Knowing the Unknowns

The ZwSoft offer, which runs until the end of the year, offers network licenses at no extra cost. If you license 20 or more copies, then they throw in a Network License Analysis Tool, normally $500 extra.

The fine print, however, notes that "The license is time-limited,"

[Sept 2, 2020: ZwSoft wrote me with some additions and corrections.]

so we don't know how long the network licenses run for free. At some point, ZwSoft might send you a bill.

On its Web site, ZwSoft publishes no network license prices, so we have no idea what the savings are. We know, however, that stand-alone prices are going up. because...

"On our Network License offer, it is a free trial through 12/31/20. At that point, users will have the option to purchase. We will not issue any charges, unless they explicitly purchase. The price to upgrade to network licensing for STD is $225 and $50."

Prices Up

A few days before announcing free network licenses, the company announced price increases with the release of ZwCAD 2021 on September 1. In general, prices go up $200:

Perpetual licenses

• ZWCAD STD from $799 to $999 $899
• ZWCAD PRO from $999 to $1199

Subscribe-to-Own (after 4 months)

• ZWCAD STD $200/month to $250/mo $225/mo
• ZWCAD PRO $250/mo to $300/mo

The company says it has 900,000 users.

 

The Target

With Autodesk making stumbles like emphasizing named-licensing, failing to port all its software to the cloud, and de-emphasizing development of legacy software like Revit, competitors are lovin' it. Earlier this year, Bricsys, for example, released a video educating users on the drawbacks to named licensing. During a media event last month, Siemens emphasized that design software does not belong on the cloud. Over the summer, nearly a hundred architectural design firms worldwide signed a letter publicizing the problems they face using Revit in 2020.

Being closer to Wall Street than to Main Street is not the way to keep customers content.

 

My First Software Manual -- 1981

Job Control Language

 

Cleaning out my cupboards last week, I came across something unexpected. Software documentation that apparently I wrote in 1981. I have no recollection of it, nor do I know why I wrote it. All I recognized was the name of the co-author, Linda, a classmate of mine during that, the last of my seven years at the University of British Columbia.

The document is historical not only for it being the first software documentation I ever wrote, but also in how it was produced.

1976

My first direct experience with computers was UBC's mainframe, an Amdahl that was plug-compatible with the then-standard IBM/360. In a huge linoleum-floored, fluorescent-lit, noisy cardpunch machine-filled room, we undergrads wrote our brief programs into punchcards, one line of code per card. A deck represented the entire program. We ran the deck through a card reader, and then waited on the result. With dozens (hundreds?) of undergrads running programs on that single shared computer, the wait tended to be longish.

The results of our programs came from an enormous line printer that commanded the center of the room. It was called a "line printer," because it printed an entire line of text at a time -- 132 characters at once on tractor-fed green-white stripped paper. It clattered noisily but was pretty fast. It commanded the room, because we gathered about it as we hoped our programs would not generate results that contained the words of dismay, *WARNING* or *ERROR*.

Whenever the printer encountered a problem, it slowly and magnificently raised its hood at us. Foolish undergrads who, while waiting for their printout, placed their card deck atop the printer saw the cards sailing through the air like a game of 52-pickup. The rest of us waiting for our results erupted in loud cheers at the sight.

1980

There was no interactivity; this was batch computing at its coarsest level. Or, as we called it at the time, "jobs." Grads, however, accessed the mainframe through interactive terminals. I still recall the feeling of awe from the first time I entered the terminal room. It was bathed in very subdued lighting, had carpeting on the floor and individual cubicles housed green-screen terminals with padded office chairs. Hushed, with only the quiet clicking of keyboards. It felt like the engineering deck of an UFO.

Having access to a terminal also meant we could store files; no more card decks flying through the air! Although the first year or so, I had no concept of the difference between data files, programs, the operating system, eh?. I did love the commands I now could deploy: CREATE EARTH (create a file named 'earth'), then KILL EARTH (erase the file). The power!

At first the terminals were limited to line editors. To edit text with this kind of text editor, you would enter the number of a line, use control keys to move the cursor along the line, and then make the change. Pressing Enter committed the change to the file. (Early versions of MS-DOS were no different: the text editor Microsoft wrote was called EdLin, and it also edited text just one line at time.) Clumsy, frustrating, and only slightly better than using punch cards.

1981

During my last year, the University of British Columbia Computing Department experimented with a full-screen editor. This was an amazing advance: now we could move the cursor anywhere on the screen to make an edit. For me, however, as a touch typist, this was a multi-million-dollar computer finally catching up to my $400 typewriter; the difference, of course, being that I no longer needed to retype pages.

So while programs were now stored as files instead of punchcards, the output was done in exactly the same way. We had to wait for a printer to spit out results. Less conveniently, the printer was in the basement of the computing center, while our lush terminal room was two stories up. At least we got the exercise of running up and down the stairs.

The printer was one of the first laser printers in the world. Made by Xerox, the 9700 was as long as an automobile. It offered one font, Courier, and printed at 300dpi. However, it was blazingly fast: two pages a second. As we waited for our output to be pigeon-holed by the computing center staff, we could hear it quietly making that tick-tick sound, twice a second, for each page being printed. When done printing a job, it added a cover sheet identifying the job as ours, and then stapled the pages together.

The computing center developed the full-screen editor further, adding features like bold (*B*) and italics (*I*) codes that we embedded into the text and different fonts. I never did figure out how to specify a different font; Courier was good enough.

And so we come to this piece of documentation, my first. I have no idea why Linda and I were tasked with writing it for the GVRD, the Greater Vancouver Regional District (now Metro Vancouver). At the time I was taking classes in the faculty of Community and Regional Planning, and my engineering specialization was transportation, so perhaps a prof had us do it as a class assignment.

No matter; I loved to write and the full screen editor was the breakthrough I'd been waiting for since I learned to touchtype a decade earlier in Typing 9. Editing without retyping!

The manual described the JCL (job control language) syntax for running a program that simulated land use and traffic flows. Running the program cost 37 cents a second. Running the program from a terminal added a surcharge of 40%. Data was stored on tapes that cost $1 to mount and then 30 cents a minute while mounted. Printouts of the result cost 3 cents a page of paper plus 4.8 cents for 120 lines (a page of text). A typical run cost about $20 (about $50 today, with inflation). Today's cloud computing regresses to those bad old days.

1983

When two years later I got my first computer, a Victor 9000, it came with no software other than what MS-DOS v1.x included -- the EdLin line editor, with which I wrote. A brilliant friend who camped in my apartment for a couple of months while waiting for his job to begin wrote me a full-screen editor in MS-BASIC. (That was all I asked from him in terms of rent.) To make it fast, he wrote it as a single, large array that held all the text. This approach limited files to about ten pages, max, but that was all I needed to be productive. Thanks, Norbert! I added function key definitions that added formatting and so on.

The true brilliance of the personal computer was that it no longer cost each time I needed to run a program. Sure, the computer (and printer and cables and diskettes) came to $6,000 (about $15,000 in today's money), but after that it was free to use.

1985

Little did I realized that four years after I left UBC I'd leave my position as a professional engineer -- forever -- to become a professional technical writer in September, 1985.

I was there to watch the progression from line editor to text editor to word processor to desktop publishing.

 

 

VM on Linux in ChomeOS -- too slow for me

It's not Elementary

 

Linux running in ChromeOS gets a bit more functional with each release of the browser-based operating system. It still starts, however, in terminal mode, although Web sites will tell you how to install a GUI (graphical user interface) so that you don't need to type endlessly-long command-option strings at the prompt, such as this one:

sudo apt install qemu-kvm libvirt-clients libvirt-daemon-system bridge-utils virtinst libvirt-daemon virt-manager -y

Now in 2020 it is possible to install VM (virtual machine) software on ChromeOS's Linux subsystem, and then run multiple Linux GUIs. ChromeUnboxed, for instance, shows how to do this with one Linux package at chromeunboxed.com/forget-windows-i-just-installed-elementary-os-on-my-chromebook-and-its-awesome/. I recommend you read the comments to the article to learn about steps the author forgets to detail.

You do need a Chromebook with a powerful CPU, significant RAM, and more than the usual storage space, as a VM typically wants 20-40GB for itself. My Acer runs an i7 CPU with 8GM RAM and 128GB of storage -- about as powerful as it gets these days.

The writer says, "I want to point out that the Linux operating system runs like a champ inside the virtual machine." I found it didn't. Any click I made took Elementary a minimum of three seconds to respond; sometimes the wait for me was ten seconds. After playing with it for a half-hour, I stopped the virtual machine, and then uninstalled it entirely.

I suspect running Windows on Parallels on ChromeOS will be just as painful. There's just too many layers of code at work.

 

 

 

German station furnishings for AllPlan

DB + BIM

 

If you like trains as much as I do, then you might be excited to learn that Germany's Deutsche Bahn rail operator has released all of its station furniture as BIM files, free. That's 3D models of guard rails, shelters, sign posts, light standards, and so on. The package includes IFC exchange profiles and planning documents.

S-Bahn station in Berlin (photo by me)

 

There numerous catches in the offer from DB Station & Service AG (the arm of Deutsche Bahn that operates the train stations in Germany) and Allplan:

• The registration page, download site, and software install are all in German
• The download is an EXE installer file that searches for AllPlan
• The installer stops when it cannot find AllPlan

Otherwise, cool.

Some stats about the Germany passenger rail system:

• 5,400 stations
• 800 station buildings
• 3,300 tenants, like stores, in 700 of the stations
• 1 million m² (ten million square feet) floor space
• 20 million passengers/day
• Using BIM since 2017 to manage it all

To access the library: info.allplan.com/de/dbahnsteigplanung-in-allplan-db-station-service-ag-projektvorlage

https://www.allplan.com/en/

 

Nanosoft ships 3D DWG editor nanoCAD Pro 20

At about half the price of AutoCAD LT

 

Last week we heard of this year's release of parametric MCAD from TOP Systems in Russia. This week, it is Nanosoft's turn.

Nanosoft has two CAD systems, the lower-priced 2D-mostly DWG editor named nanoCAD Plus; version 20 shipped last month. The other is the higher-priced 2D/3D DWG editor named nanoCAD Pro; version 20 shipped this week.

I am biased towards it, because I've creating tutorial videos for the company, and so I know the software rather well. It offers a remarkable price-performance ration: for about half the price of AutoCAD LT, you get:

• Parametric 3D modeler with history
• Direct modeler and editor
• 2D and 3D constraints
• Import and display 3D point clouds and IFC files
• Import PDF files as underlays or as entities
• Uses DWG as its native file format

This for US$865, which includes three years maintenance. nanoCAD uses DWG technology from the Open Design Alliance, and the 3D modeling/parametrics kernel from C3D Labs.

For this year's release, here are some of the new and improved functions in nanoCAD Pro 20:

New:

3D constraints -- creates assemblies from parts

Direct modeling -- pushes and pulls faces to interactively alter models

Dynamic UCS -- automatically reorients the UCS for drawing on 3D faces

Drawing comparison -- shows differences between similar-looking drawings

Bounding prism -- clips 3D models for seeing inside buildings and mechanical designs

Script editor -- indents and color coding for editing and running LISP, VBA/ActiveX, DCL (dialog boxes), and JavaScript routines

Improved:

Dynamic input -- enters command options right at the cursor

Undo/Redo -- previews changes made by the Undo and Redo commands

For an illustrated list of new and changed features, see the What’s New page at nanocad.com/products/pro/updates/. 

Download a 30-day trial version from nanocad.com/products/pro/download/

 

 

Report: Autodesk ignored Revit concerns in 2014

Australia, New Zealand

 

Last week's list of Revit complaints by an international group of architectural firms reads much the same as ones listed already back in 2014. As reported by Iain Godwin of Godwin Consulting, "In 2014, a group of 12 large Australian and New Zealand Practices sent a letter to Autodesk’s Sales Director, Autodesk Asia Pacific, stating,"

We feel that the value for the money that we have been spending on the software subscriptions has been diminishing steadily, most noticeably in the last 2 or 3 years.

We also feel that the annual enhancements to the software are not being sufficiently driven by existing user requirements.

It appears that marketing driven changes are much more dominant.

According to Mr Godwin, "The net response from Autodesk was, no letter, no email, no phone call. Nothing." 

 

In and Since 2014

Tim Waldock, Revit consultant at RevitCat in Sydney, Australia writes on Linked-In (linkedin.com/pulse/autodesk-letter-tim-waldock/) regarding the "Rage against Revit" open letter to CEO AndreW Anagnost, noting Autodesk's lack of action in 2014, and then goes on to list the good and the bad changes to Revit since 2014. He concludes:

It will be interesting to see how Autodesk actually substantiate their claim: "Engaging, listening to and addressing the concerns of our customers is a top priority for Autodesk."

The Linked-In post includes the 2014 letter in its entirety.

ITC releases IntelliCAD 10.0 to members

by Randall Newton, CONSILIA VEKTOR

 

The IntelliCAD Technology Consortium (ITC) announced the release of IntelliCAD 10.0, which it says is a “major update” with many new features. 

The ITC creates a core CAD product that other vendors use to create custom drafting software. ITC products support the DWG file format popularized by Autodesk AutoCAD. As a member of the Open Design Alliance, ITC uses ODA code libraries to assemble parts of its software.

David Lorenzo, ITC President, stated, “IntelliCAD 10 is a huge structural update with new core libraries from the ODA, a new geometry library, updated graphics, and new APIs. Yes, there are several interesting new features for users too, but the structural changes provide a much stronger foundation on which ITC members can build even more complex and diverse applications.”

New In Ten Point Oh

The OpenGL ES graphics device is now supported for enhanced display quality and performance, which also includes new visual styles. A new materials library contains materials that can be assigned to entities and layers and then displayed with visual styles; spot and point lights can also now display in-program with visual styles. The redesigned View Manager has more options available and allows users to make selections dynamically for the view’s background, perspective, lens length, etc. 

New dynamic input incorporates command prompts and measurement guides at the cursor.

Printing with .pc3 customization files is enhanced with the ability to set margins, page size, .pmp files, and settings that vary according to the output file type.

New import file formats include .obj and .stl.

Many new properties are available for various entity types in the Properties pane, including the ability to view properties of custom entities.

IntelliCAD 10 also includes the ability to migrate user interface customizations from previous versions.

 

Tweaks Here & There

Smaller features that will have a big efficiency boost for end-users are

• the ability to re-order and sort layer filters
• combine paragraphs and clear formatting of multiline text
• determine which user interface items are hidden when cleaning the screen
• use new videos and online resources from the Start page
• convert closed entities to solids
• specify a layer state for each published sheet
• a redesigned status bar
• enhancements for Section 508 usability
• better 4K display support
• an initial Hungarian translation

 

IntelliCAD for BIM

For versions of IntelliCAD that work with BIM files, draw roofs and beams, create mitered joints for beams, explode attached BIM underlays into polyface meshes and polylines that can be edited while retaining underlay functionality, and use new options for section lines and elevation lines.

 

IntelliCAD for MicrosStation Users

For versions of IntelliCAD that open, save, and edit .dgn files in their native format, the supported command set now includes Multiline Text, Chamfer, and Dimension Styles.

For advanced users, IntelliCAD 10 incorporates ODA SDKs version 2020 Update 2 and enhanced .NET and IRX functionality for increased API capabilities. Other improvements and fixes are found in performance, working with files, editing and selecting entities, text, printing, and more.

 

More Goodies

An overview video of IntelliCAD 10.0 features is on YouTube at youtu.be/FmyaEugUMio.

IntelliCAD 10.0 is supported on Windows 10 through 7, 64-bit versions only.

IntelliCAD Mobile Viewer versions are available for Windows desktop, Google® Android, Apple® macOS® and iOS.

For more information about IntelliCAD and the ITC, including case studies, please visit www.intellicad.org/.

[This article reprinted with permission from https://www.consiliavektor.com/2020/07/31/structural-updates-highlight-intellicad-10-0/]

Expect Creo-on-the-cloud in a few years

The shoulders of Atlas grow longer

 

When PTC purchased Onshape, it wasn't just to help Onshape get rid of its huge debt to early investors. That was just one reason.

As PTC ceo James Hepplemann put it last week, "If the Onshape acquisition seemed expensive, I mean, it was." It was, after all, not just the $470 million that's been talked about in public; PTC also paid off the remaining debt on top of that, perhaps as much as a further $169 million. The $470 million was just the net purchase price.

Onshape boosts PTC's efforts in boosting recurring revenue, sweet talk for more subscriptions from more customers. As Mr Hepplemann explains, SaaS [software as a service] "is a long-term monetization effort that’s significant, because while we’ve brought our customers from perpetual to subscription, there’s another and potentially bigger monetization associated with bringing them from on-prem [software running on customers premises] into SaaS [software instead running on servers rented by PTC]."

More SaaS = more revenue for PTC = more cost to customers.

Onshape boosts PTC efforts to do more SaaS. The technology on which Onshape runs becomes the technology on which PTC's other software will run. PTC has named this technology "Atlas," the Greek's mythical god whose punishment was to shoulder the entire firmament for eternity. He was one unhappy camper. (Image source allposters.com.)

"We’re proceeding full speed ahead on the Atlas program, which aims to generalize the underlying Onshape SaaS architecture and put it to work more broadly across the entire PTC product portfolio," explained Mr Hepplemann.

PTC says its Vuforia AR software already runs on Atlas; no surprise, as that was an easy port. As does Onshape, of course.

 

Creo of the Clouds

Mr Hepplemann calls Atlas "a breakthrough CAD platform that will allow Creo [MCAD] and Windchill [PLM] to get into that SaaS world years earlier than they would have independently, and on a consistent platform. Everything’s knitted together on a common platform. But you know, I want to be clear: it’s not a short-term strategy."

The interesting claim that PTC plans to port Creo to Atlas is interesting because it is pretty much now a given, in 2020, that CAD belongs on the desktop. Nevertheless, Mr Hepplemann is giving his company several years to pull cloudCreo out of the hat.

Don't expect it this year or next or the next. "Let me be clear," repeated Mr Hepplemann. "It’s kind of a mid- to long-term thing, because we’re really looking at doing kind of a major redevelopment of those properties onto this platform."

Here is what he is promising customers: "The key thing for us would be to optimize [cloudCreo] for compatibility and continuity" with desktop Creo. Also:

• A product that looks a lot like Creo
• Runs in the cloud
• Is multi-tenant
• You open up the same files
• You work with the same user interface

 

Creo vs Onshape

The question then becomes, How does MCAD package Creo compete with MCAD package Onshape, when there is no differentiation with both running on the cloud? From earlier comments by PTC, it appears that Onshape will always have fewer capabilities than Creo, be cheaper than Creo, and be targeted at smaller firms than Creo. The little step-brother.

Mr Hepplemann employs a Google-Microsoft analogy, in which Onshape is Google Docs and Creo is Microsoft Office:

I have an analogy I’ve shared internally many times. If you think of Google Docs, it’s a completely fresh thought, fresh look at an office productivity suite. Meanwhile, you had Microsoft Office, which was on-prem [desktop].

But Microsoft came out with Office 365, which was SaaS, [because] companies like PTC might have been thinking about whether we should go to Google Docs. Many do, and particularly new companies, but companies who have been using Office forever really do prioritize compatibility of data and user experience, but we like to [also] have SaaS.

So you could imagine we could build a product that looks a lot like Creo. But it runs in the cloud and is multi-tenant, but you open up your same old files and you go right back to work with the same old user interface, much like you did with Office 365.

Meanwhile, Onshape over here is more like Google Docs, unbridled, unconstrained innovation, no legacy, trying to invent the next generation of application. So I think Onshape fights the fight against competitors, and Atlas allows Creo and Windchill to bring their customer base [to the cloud].

Future of Onshape

Onshape is not compatible with Creo, although Atlas is supposed to make sure of that. So, I wonder if Onshape has a future at PTC? In my version of alternative history, once PTC gets Creo to a 'good enough' level on the cloud, the lower-revenue-producing Onshape might be, I wonder, seen as a drain on sales and marketing resources, and so dumped from the line-up. 

 

[Quotations with some editing for clarity and brevity sourced from https://seekingalpha.com/article/4362125-ptc-inc-ptc-ceo-jim-heppelmann-on-q3-2020-results-earnings-call-transcript]

 

 

 

 

 

 

 

 

 

Letter to Anagnost Gains Country Representation

17+18+10=45

 

One of the complaints directed at the group who posted this week's open letter to Autodesk CEO Andrew Anagnost was that the list of 17 architectural firms were primarily British. It could be positioned as a regional complaint. The complaint involves an up-to-70% increase in subscription fees (over five years) for Revit, insufficiently developing the software to handle today's architectural projects, and other issues.

With the publicity of the letter, more architectural firms learned of the so-called "Revolt against Revit" and so signed up to also support the list of complaints against Autodesk. The following countries are represented by architectural firms:

• USA
• South Africa
• France
• Canada
• Netherlands
• Norway
• Israel
• Australia
• Great Britain

The original letter was hosted by 17 firms; 18 more signed the letter this week as a result of the attendant publicity; ten firms agree with the letter's content but say they fear retribution from Autodesk if their names were to be made public.

The letter has been posted online as a downloadable PDF file: https://letters-to-autodesk.com/

To learn more about why 45 firms are expressing their discontent with Autodesk publicly, be sure to read Martyn Day's 4,000-word report on the conditions leading up to this week's event at https://www.aecmag.com/comment-mainmenu-36/2046-autodesk-aec-customers-demand-better-value.

 

Europeans Examine Non-European BIM Vendors' Sales Practices

Autodesk having its own 2020?

 

The European Construction Industry Federation (ECIF) is a go-between organization of construction firms and 32 countries in Europe. It is calling on the European Commission to investigate the non-competitive nature of BIM software in Europe.

Specifically, the organization is calling out software companies involved with BIM that

• Are non-European
• Offer software only by increasingly-expensive subscriptions
• Limit software use to only in the country of the software's licensing
• Sell software with poor backward compatibility
• Have little actual experience with construction

When we take these criteria into account, I am of the opinion that it seems that the ECIF is referencing just software vendor specifically (despite the plural) that I think might match the criteria: Autodesk. It could be that there are others, as well, but Autodesk would be included if there were a group coming under the spotlight.

Here is what ECIF wants, and it is something we all would want:

It should be for the market to decide, and this is why the construction industry needs open, competitive, and fair markets for software and related services.

The FIEC's position paper is not new; it came out in February. Still, it seems that Autodesk might be having its own version of 2020, as architects revolt publicly against the limitations of Revit, and the EC  being called to investigate BIM vendors that aren't European. 

ECIF makes more points, which go against globalization (of which I am no fan, and so the Balkanization is interesting to observe). ECIF wants that

• EU companies should be able to have their data hosted on EU territory, by EU servers, under EU legislation
• Creation of a secure European cloud
• Non-EU software services should be required to meet EU standards for interoperability and open access
• European Commission should promote open standards for data, protocols, and file formats in public procurement
• Legal protection of BIM data to protect intellectual property

I dislike government getting involved in our personal lives and company practices. But as we see with the likes of Google and Facebook, the network effect creates authoritarianism of a corporate kind, and that must be fought against. 

You can download the position paper from https://www.fiec-ar.eu/images/pdf/WG4.0-2020-02February-D-FIEC%20position%20paper%20on%20Software%20companies.pdf

 

Top Systems updates T-Flex CAD for 2020

T-FLEX CAD 17

 

Top Systems makes one of the advanced MCAD design system that originate in Russia, and so tends to get little attention outside of the country.

T-FLEX CAD was one of the earliest to adopt parametric design, uses Parasolid as its kernel, and now release 17 adds the following functions:

• Advanced surface and curve modeling to make surfaces of any complexity
• Accelerated complex assembly design to load the aircraft model 8x faster
• New solutions for simulation, such as Inertial Relief 
• Advanced electrical design tools
• Enhanced markup functions
• Import Revit and FBX files

On top of the base MCAD software, Top Systems offers the following add-ons:

• T-FLEX Analysis
• T-FLEX Dynamics
• T-FLEX CAM
• T-FLEX Electrical
• T-FLEX VR (see below)
• T-FLEX Nesting
• T-FLEX DOCs for PLM

The software runs on Windows, and is available in English and other languages. A 122-page PDF tells you what's new in this release: tflex.com/resources/whatsnew/. Unlike less flexible CAD vendors, you can license the software standalone, networked, student, or with annual maintenance.

Details here: www.tflex.com

 

What Statistics Can Tell Us About SARS-CoV-2 Test Results

by Nikolay Snytnikov

 

To better estimate the situation with СOVID-19 within our company LEDAS, we decided to make antibody testing available to our employees, all of whom had been working  remotely since March. Fifty-three of our 70+ employees were interested, and so we organized out-of-lab testing thanks to Invitro’s laboratory service. Both IgM (early antibodies) and IgG (late antibodies) were examined, and the results were simple: all had zero positives for IgM, and one employee was positive for IgG.

We were able to congratulate ourselves for the zero result in early antibodies, meaning we are quite safe. But now we needed to focus on the late antibodies, as they provide more interesting information. Since we at LEDAS are now involved in more medical software projects, we considered this an opportunity to apply statistics to our medical data.

 

Test Accuracy

It is important to keep in mind that the accuracy of SARS-CoV-2 antibody (ELISA) tests is not very high: the sensitivity (true positive rate) of our tests was ~95% and the specificity (true negative rate) was ~98%. These are due to the lack of a perfect verification procedure, because double-checking through PCR (polymerase chain reaction) testing is not precise either. The specificity could be increased more easily by using old blood samples collected before the coronavirus era, such as from 2019, which could be considered non-infected.

Statistics are more accurate when working with big numbers, and so results for groups are more meaningful. By contrast, individual results are not particularly indicative; for individuals, they could be even counter-intuitive. I’ll look at both cases.

 

Individual Results

Let’s assume that the general level of infection in the population is L=5%. This corresponds to results from a nationwide study in Spain published recently in the Lancet journal. Spain is one of the highly infected countries.

When someone gets a positive result, there are two possible reasons that are mutually exclusive:

• TP – there is an infection, and the test is a true positive (accurate)
• FP – there is no infection, but the test is a false positive (inaccurate)

The probabilities P(TP) and P(FP) are calculated in this way:

P(TP) = level of infection * sensitivity = 0.05 * 0.95 = 0.0475
P(FP) = (1 – level of infection) * (1 – specificity) = 0.95 * 0.02 = 0.019

The probability of getting a positive test P (Positive) is the sum of the two probabilities:

P(Positive) = P (TP) + P (FP) = 0.0475 + 0.019 = 0.0665

This means that if you are in Spain (or in another country with the same level of infection), and you applied for a test of this type, then you have a 6.65% chance of getting a positive result.

What can we conclude from this? That we should apply the conditional probability formula to measure your chances:

P(TP / Positive) = P(TP ∩ Positive) / P(Positive) = P(TP) / P(Positive)

The probability that you are actually infected in the case where you received a positive test will be approximately

P(TP / Positive) = 0.0475 / 0.0665 = 0.714…

So, before taking a test in Spain, you have a 5% probability of having been infected; after testing, despite getting a positive result, you still have only a ~71.4% probability of being actually infected. Your chance of being not infected after a positive result is ~28.6% – not so small!

So what is the benefit of testing for the virus? To understand this, we should consider how the probability of being infected changes when the result is negative. Once again, there are two possible reasons for testing negative:

• FN – a patient is infected, but the test was false negative
• TN – a patient is not infected, and the test was true negative

The probabilities are:

P(FN) = level of infection * (1 – sensitivity) = 0.05 * 0.05 = 0.0025
P(TN) = (1 – level of infection) * specificity = 0.95 * 0.98 = 0.931

The probability of getting a negative test is the sum of the two:

P(Negative) = 0.0025 + 0.931 = 0.9335

This conforms with the 0.0665 probability of getting a positive test result, as P (Positive) + P (Negative) = 1.

The probability that you are actually infected when you test negative is

P(FN / Negative) = P(FN ∩ Negative) / P(Negative) = P(FN) / P(Negative) = 0.0025 / 0.9335 = 0.0026…

So, while before test you had 5% of probability of having been infected, after getting the results you have either

• 71.4% of probability of being infected, if the result is positive, or
• 0.26% of probability of being infected, if the result is negative

In the one case, you increase the probability by an order of magnitude; in the other one you decrease it by an order of magnitude. The difference is significant!

It is easy to see that if the specificity of the test somehow decreases to less than 95%, then even after getting a positive result you will have less than a 50% chance of being truly infected, which is rather counter-intuitive.

 

Group Results
The results for our test group can be described using a binomial distribution. Let’s input our parameters P (Positive) and N=53 and see what WolframAlpha tells about this:

What is the probability that there were no infected employees in our company, given one positive? For this to be true, 53 test conditions should be satisfied simultaneously and independently:

• One condition (the only positive result) is actually a false positive; the probability of this is P (FP / Positive)
• 52 conditions (the negative results) of which each is actually a true negative; the probability of this is P (TN / Negative)

The product of these 53 Bayesian probabilities is

So we have a not-so-small 25% chance that no one was infected.

What is the probability that many employees were infected? This is not as easy to calculate, but it is easy to make an upper-bound estimate. To have more than N-infected employees, we should have at least N false negative tests, based the one unit of difference between them provided by the single positive result in all our antibody testing.

The probability of having N false negative tests is not more than

If N=2, it is already less than 1%, so it is highly unlikely that we have more than two infected employees. Using this formula, the probability of having exactly two infected employees is less than 14.2%.

Therefore, the highest probability is that there is only one infected employee at LEDAS, as we have a 60+% chance for this. This implies that there was no transmission of the virus inside our company.

 

Some Notes About Assumptions
I did the computations with these assumptions:

• The statistical selection was done independently
• The percentage of people in the population that contracted coronavirus is 5%

The first assumption is, of course, not fully correct, because our employees had been working from home for a long time, and so have a low probability of being exposed to the virus. So, the selection was not independent.

The second assumption of 5% infection does not correspond to the official data for Novosibirsk region, in which our staff is located. As of mid-July, there were seven thousand cases among 2.8 million people, for an infection rate of about 0.25%. On the other hand, it is well-known that official testing data don’t include asymptomatic and false negative cases; this is true for all countries, and so Russia and Novosibirsk are not exceptions here.

We can adjust the infection rate without doing extensive antibody testing, but instead using estimates from the infection fatality rate (IFR). Some studies suggest that it should be within the range of 0.5-1%. The official number of coronavirus-caused deaths in the Novosibirsk region is 142 (as of July 12). We can calculate the number of all COVID-19 cases in the range of 14-28 thousand.

Unfortunately, these numbers look underestimated, as the official number of death cases might not be correct. For example, some deadly pneumonia cases are “false negatives” or are not considered to have been caused by COVID-19 as the primary cause of death.

Better estimates of lethal COVID-19 cases can be calculated by comparing the mortality of this year with that of the previous year, as was done by the Financial Times for certain countries and regions. The raw data is available on Github.

For the Novosibirsk region, the data (available elsewhere) suggests there were an additional 400 deaths in June 2020 (when compared with the monthly average for 2019). Of course, not all deaths this year can be attributed to COVID-19, but very probably it is the primary reason of the increase. Assuming that 300-400 deaths were due to COVID-19, then the number of all cases can be roughly estimated as 30-80 thousand per 2.8 million of people. This is in the range 1%-3%, and much higher than official data of 0.25%.

 

Estimates from Dunbar's Number

The numbers can be double-checked with a very different consideration: sociology and anthropology. The so-called Dunbar’s Number proposes that people can comfortably maintain about 150 relationships with other people.

Dunbar’s Number can be useful in understanding the level of disease spread in the population: if you know of no one among your friends or relatives who contracted the disease, then the likely number of cases is less than 1%. But if there is at least one person you know personally, then the rate is higher than 1%.

In our case, it looks like the 1-3% estimate is correct, as for many of us we know of two to three COVID-19 cases among friends and relatives. Very probably during the next few weeks and months, some of our employees will contract the disease as well, due to the increasing number of infected people in the general population.

Below you can see how the probabilities of different cases for one person change if we decrease the parameter “infection level” from 5% to 2% (midpoint of the 1-3% interval). It is interesting that for the positive result you have nearly 50:50% chances of true positive and false positive:

Conclusion

We believe that there were no transmissions inside our company, because we implemented remote work in March, well before there were any cases reported in our city. Restrictions from authorities began more than ten days later. And we are taking care to not contribute to transmission of the virus in the future.

Stay healthy, safe, and take care!

- - -

Nikolay Snytnikov is the chief operating officer at LEDAS. He supervises projects in the areas of 3D cloud applications, medical software, CAD, and BIM, and the development of the LEDAS Cloud Platform. http://ledas.com/en/