(DISCLOSURE: While an employee of Crisp Ideas AS, Oslo, Norway and adviser in the areas of business development and strategy to technology companies, I have and have had engagements with Ceetron AS, the owner of the VTFx data exchange format.)
The VTFx data exchange format has a long history in the CAE community, with the original specification dating back to 2006-2007. Today between 5 000 and 10 000 engineers use the format on a regular basis to share simulation results, and major players in the CAE community provides export to VTFx format as part of their FEA or CFD offerings, including Transvalor (material forming), Autodesk (general CFD), Dassault Systemès (structural optimization), and DNV GL (modelling of marine structures). Files in the VTFx format can be viewed in Ceetron’s free viewers, which are available for download from Ceetron’s web site.
Before we dig into the key theme for today’s blog post, the case for data exchange format standardization on VTFx in the FEA and CFD community, it is of interest to explore alternatives to VTFx and the background for establishing the VTFx format in the first place. Or, let us start with the case for 3D visualization and data exchange based on open formats in the CAE community in general: “3D is the most effective way to communicate and solve product and process issues,” said Pascal Daloz, vice president, Strategy, Dassault Systèmes. in a press release back in 2005 about Open 3D XML “[this product based on 3D XML] is an example of how to extend 3D beyond traditional Product Lifecycle Management applications and deliver more value by leveraging this critical information across a broad base of users.”
Then about the establishment of the VTFx format: Before establishing VTFx format, Ceetron investigated a number of alternative candidate formats for transportation of CAE data, including IGES, STEP, MPGS, VRML, JT (later JT Open) and U3D (later 3D PDF). Most of the investigated formats supported tessellated surfaces and could be extended or adapted to carry simulation data, but two particularly strong candidates emerged: JT (see previous comment) from Siemens PLM, and U3D / 3D PDF by the 3D Industrial Forum. Both are today open standards, at least in a broad sense, JT Open was officially published as ISO 14306:2012 in December 2012, and U3D was published as ECMA-363 in August 2005.
Despite some of these formats’ attractiveness as open standards and / or backing by major commercial interests, real-life testing revealed that there were to varying degree performance penalties in terms of file size or read/write speed, and technical when wanting to add custom data types. Furthermore, the investigated formats had little or no support for describing simulation data in a compact way and such that all engineering information and metadata were preserved (e.g., FEA- or CFD-specific data types). At a more technical level, some of the formats lacked support for commonly used element types or user-defined element types. Others again did not have support for specific data types like scalars, vectors, or transient data, or could not represent (partially) adaptive meshes efficiently.
The above insights led Ceetron to create VTFx as a published specification in 2006-2007, and the rest is history. Regarding competing formats, JT Open is today primarily seen as a solution for CAD / PLM data, and with main impetus from Siemens PLM; U3D/3D PDF is primarily seen as useful for embedding 3D information in pdf documents and having limited support for time-variable information; and 3D XML is a proprietary data format for Dassault Systèmes. That said, all four of JT Open, U3D, 3D XML, and VTFx have been fundamentally designed for creating, reviewing, and collaborating about engineering information with a fundamentally three-dimensional nature and having (tessellated) surfaces and volumes.
Having done my stint in sales in Microsoft and closely followed the battle between OOXML and ODF, and having done course work in technology prediction at MIT, Boston, I thought it could be interesting to explore possible end game structures for data exchange formats in CAD/CAE space.
A possible hypothesis could of course be that we will simply see the same picture in CAD/CAE as when pdf developed into the in practice single portable format for text document distribution, viewing, reviewing, and sharing independently of application software, hardware and operating systems, and was published as standard ISO 32000-1:2008 in July 2008. Based on analogies with other categories, discussions with peers in the industry, and research on the particularities of CAE space, my guess is no, and here is what I predict will happen:
- Consolidation on formats from the large vendors, like JT Open from Siemens PLM, 3D PDF from the 3D Industry Forum / Adobe, and 3D XML from Dassault. Some of these will be proprietary (say 3D XML), some of them will be based on more or less open standards* (say JT Open)
- Transformation of 1-3 such formats into true engineering collaboration platforms with free viewers that work across geographies, organizational boundaries, devices, disciplines, and CAE tools (much the same way as pdf has over the years developed into the lingua franca for text document sharing). These collaboration platforms will especially for smaller companies replace earlier attempts to create single-vendor platforms
- Slow emergence of open formats and open standards, but the major players will drag feet and add proprietary extensions, just like Adobe did with pdf and just like Microsoft did with OOXML
- In CAE, emergence of highly efficient formats for CFD-type and FEA-type type result files, feasible for FEA and CFD models with hundreds or thousands of time steps and millions of nodes. VTFx is one candidate for such data exchange format, but there could be others**
- Introduction of 3D web technologies, typically based on WebGL, that enable data sharing without explicit file transfer (but still one needs a format)
*) Even those that claim to be ‘open’, say JT Open, 3D PDF, and 3D XML (which used to be called Open 3D XML, if I remember correctly), and even those that claim to be standardized by recognized standardization organizations like ISO or ECMA, are to varying degrees closed, if using a strict definition of open file format / open standard.
**) It could also be argued that VTFx is not an open format and that this will hinder end user adoption. In fact, VTFx has a publicly available specification (see https://ceetron.wpengine.com/media/products/express-writer/vtfx-reference-guide.pdf) and can be viewed royalty-free, but it cannot be written royalty-free. This is similar to Adobe’s pdf format, before opening up the standard in 2008 and publicizing its Public Patent License (of most, but not all stuff in the original pdf format). It appears also to be similar to the case for JT Open and 3D PDF, though the commercial arrangements here are slightly unclear.
I also thought it could be interesting to discuss the future of VTFx with Fredrik Viken, CTO in Ceetron. He said: “We have seen a good pick-up of the VTFx format in the market, to some extent also amongst non-Ceetron writer-side developers like SINTEF and DNV GL. We foresee that VTFx will short- and medium-term live side by side with other offerings, ranging from fairly proprietary to fairly open standards, and Ceetron will continue to invest in VTFx as a major collaboration platform for CAE professionals, with focus on the FEA and CFD communities. For the time being we do not consider ECMA standardization or ISO standardization to be important for the VTFx community, but we would welcome discussions about an Open VTFx standard with writer-side or reader-side providers on this issue.”
I furthermore discussed the situation about Ceetron’s Export Component with Fredrik. This component can be used to create VTFx files from any CFD or FEA simulator, stand-alone or together with Ceetron 3D Components. Fredrik was happy to confirm that a beta version of Export Component was released 16.09.2015 and that (a pretty firm) release date is 15.10.2015. So, while the longer-term road map for VTFx may not be written in stone, your investment in functionality for VTFx format should be well protected whatever Ceetron decides to do with the VTFx format. (And, according to Fredrik, for a user of the 3D Components SDK it takes 7 lines of copy-and-paste code to add VTFx export to your CFD or FEA simulator, see https://ceetron.wpengine.com/docs/Documentation/exp_vtfx_page.html. If you are a FEA or CFD developer: Beat that with homebrew code.)
Leave A Comment
You must be logged in to post a comment.