Kernel Confusion and Legacy Models

Evan Yares left a comment on my earlier post (“Inventor Fusion and SolidWorks Confusion“), attempting to explain why SolidWorks could not switch to the Dassault V6 modeling kernel. This is what he had to say:

“There are very good reasons. I don’t think they’re beyond your comprehension — but they may be beyond your experience. Talk to someone who has done kernel-level interoperability work, and ask them how easy it is to replicate the weirdnessess of one kernel in another. The issues of surface parameterization and modeling tolerance alone are enough to make most developers run away screaming. Dassault owns both the ACIS and CATIA modeling kernels. Either one could be ‘bolted in’. Neither one would provide support for legacy SolidWorks models.”

When someone like Evan says something, I listen. He comes with a lot of experience in the CAD software industry. However, on this particular point, I would beg to differ.

IronCAD offers its users a choice between two modeling kernels – ACIS and Parasolid. Their software works perfectly with both kernels. IronCAD does not maintain two file formats, one for each modeling kernel. This is because the job of a modeling kernel is end up with a valid waterright solid model, basically trimmed NURBS surfaces stitched together. A modeling kernel has very little to do with the presence or absence of parameters or history that makes up the recipe which cooks up that solid body, if any at all. Tomorrow morning the developers at IronCAD could very well add a history tree to their software and still continue to use both modeling kernels.

IronCAD is a perfect example of how a solid model created by the ACIS modeling kernel can be converted into an exact same solid model as defined by the Parasolid modeling kernel, and vice versa. IronCAD users are even known to switch between modeling kernels, because one does blends better than the other. In fact, I believe that IronCAD is the best way of transfering data from modeling systems that use ACIS and Parasolid, as compared to using neutral file formats like IGES and STEP. Their programmers have figured out a way to map data perfectly between ACIS and Parasolid.

I may not have a lot of experience in modeling kernels, but I do happen to have some experience in file formats and the issues that surround them. But in this case, a little bit of common sense was more than enough to figure this out. I believe that the programmers at SolidWorks are at least as competent as those at IronCAD. This SolidWorks-Dassault kernel discussion is a business issue, not a technical one.

And talking about SolidWorks wanting to support legacy files is a joke. They don’t even save to earlier versions of their own software. The excuse given is that they add new features in every new version that cannot be broken down into older features. Anyone with half a brain and a little knowledge of the SolidWorks feature tree will be able to see how much water that argument really holds.

For argument sake, lets accept the SolidWorks argument at face value. I have another question. Why cannot SolidWorks save to an older version as a dumb solid? There can certainly be no reason for not doing so. If a SolidWorks 2009 user wants to send a model to a SolidWorks 2008 user, he needs to export to a neutral format which can then be imported into the older version. This introduces huge problems of missing geometry, gaps and what not. Instead of putting their customers though this, doesn’t it make sense for SolidWorks to spit out an older version file with the model as a dumb solid. At least the user of the older version will not have to worry about the integrity of the data that he has received from another SolidWorks user.

And this is true for all parametric modeling systems, not just SolidWorks. We all know why these CAD vendors do this. They actually shove their “valued” customers down a path of great risk in the hope that they will upgrade to the latest version or buy a subscription.

Trust me, you don’t want to get me started on this.

  • R. Paul Waddington

    “This SolidWorks-Dassault kernel discussion is a business issue, not a technical one.”Right on Deelip; and the same argument is true for other vendors as well!”We all know why these CAD vendors do this. They actually shove their “valued” customers down a path of great risk in the hope that they will upgrade to the latest version or buy a subscription.”That’s it; as I have previously said we customers/users are letting the marketeers decide on what ‘features’ we get to use because we – as a group – won’t admit that your arguments are true and that we are too lazy to put in the effort to get what we really want!”Trust me, you don’t want to get me started on this.”Unload Deelip; it’s about time some reality was injected into what can and cannot be done.

  • R. Paul Waddington

    “This SolidWorks-Dassault kernel discussion is a business issue, not a technical one.”

    Right on Deelip; and the same argument is true for other vendors as well!

    “We all know why these CAD vendors do this. They actually shove their “valued” customers down a path of great risk in the hope that they will upgrade to the latest version or buy a subscription.”

    That’s it; as I have previously said we customers/users are letting the marketeers decide on what ‘features’ we get to use because we – as a group – won’t admit that your arguments are true and that we are too lazy to put in the effort to get what we really want!

    “Trust me, you don’t want to get me started on this.”

    Unload Deelip; it’s about time some reality was injected into what can and cannot be done.

  • Deelip Menezes

    Paul,Just so that you and others know, I have put the question about saving to previous versions as dumb solids to quite a few vendors of parametric modeling systems. Not one has been able to give me a satisfactory answer. Heck, some didn’t bother to reply at all. If any of you manage to get a reply from any CAD vendor, however ridiculous it may be, I would like to hear it..As a software vendor myself, I firmly believe that customers will upgrade if we give them enough reason to do so. I also believe that balancing a one year release cycle with adding substantial new functionality is almost impossible.

  • Deelip Menezes

    Paul,

    Just so that you and others know, I have put the question about saving to previous versions as dumb solids to quite a few vendors of parametric modeling systems. Not one has been able to give me a satisfactory answer. Heck, some didn’t bother to reply at all. If any of you manage to get a reply from any CAD vendor, however ridiculous it may be, I would like to hear it..

    As a software vendor myself, I firmly believe that customers will upgrade if we give them enough reason to do so. I also believe that balancing a one year release cycle with adding substantial new functionality is almost impossible.

  • Anonymous
  • Anonymous
  • Deelip Menezes

    Anonymous,Asa Trainer from PTC told me about GCRI when I was at the PTC HQ at Needham recently. I believe this solution is the only one of its kind in the industry and I commend PTC for taking the initiative on this front. I intend to write about GCRI when I get the time.I also appreciate the fact that this is a free plug-in, even though it is available to maintenance customers only.

  • Deelip Menezes

    Anonymous,

    Asa Trainer from PTC told me about GCRI when I was at the PTC HQ at Needham recently. I believe this solution is the only one of its kind in the industry and I commend PTC for taking the initiative on this front. I intend to write about GCRI when I get the time.

    I also appreciate the fact that this is a free plug-in, even though it is available to maintenance customers only.

  • Evan Yares

    You give the IronCAD programmers a bit too much credit. They have not “figured out a way to map data perfectly between ACIS and Parasolid.” All they’ve done is figured out a way to use two kernels in a CAD program at the same time.It’s analogous to learning to speak two languages: It doesn’t imply that you can translate perfectly between those two languages.I recognize that it’s tempting to dismiss the technical difficulties in modeling kernel migration, especially when you don’t have much experience with kernels. But it might be worth the effort to do a little more research before jumping to the conclusion that “this SolidWorks-Dassault kernel discussion is a business issue, not a technical one.”

  • Anonymous

    Iron Cad is written on two kernels whereas Solidworks is written on PS. Do you think DS will pay for PS if porting the kernel of a huge application like SW is a simple (or even possible) task?Think before you type …

  • Evan Yares

    You give the IronCAD programmers a bit too much credit.

    They have not “figured out a way to map data perfectly between ACIS and Parasolid.” All they’ve done is figured out a way to use two kernels in a CAD program at the same time.

    It’s analogous to learning to speak two languages: It doesn’t imply that you can translate perfectly between those two languages.

    I recognize that it’s tempting to dismiss the technical difficulties in modeling kernel migration, especially when you don’t have much experience with kernels. But it might be worth the effort to do a little more research before jumping to the conclusion that “this SolidWorks-Dassault kernel discussion is a business issue, not a technical one.”

  • Anonymous

    Iron Cad is written on two kernels whereas Solidworks is written on PS. Do you think DS will pay for PS if porting the kernel of a huge application like SW is a simple (or even possible) task?

    Think before you type …

  • Anonymous

    Evan, Deelip’s conclusions are far better than yours. Wasn’t it you who jumped to the conclusion that synchronous technology was due to Geolus, when it had absolutely nothing to do with it. Deelip took the trouble and analyzed ST, figured it out and explained it on his blog in a way that even someone like you could understand.Before you put your so called “experience” before someone else’s rational thinking, please learn to be humble.

  • Anonymous

    Evan, Deelip’s conclusions are far better than yours. Wasn’t it you who jumped to the conclusion that synchronous technology was due to Geolus, when it had absolutely nothing to do with it. Deelip took the trouble and analyzed ST, figured it out and explained it on his blog in a way that even someone like you could understand.

    Before you put your so called “experience” before someone else’s rational thinking, please learn to be humble.

  • Deelip Menezes

    Anonymous/Evan,OK, before this gets personal and out of hand, I would like say that Evan and I and expressing our opinions. Neither of us (at least I don’t) have inside information about what goes on in SolidWorks.I don’t believe that there is anything wrong in jumping to conclusions, irrespective of whether they are right or wrong. If bloggers were to only write things that they are absolutely certain about, then blogs would be rather boring and would not spark off any interesting discussions.As regards Evan’s choice of words, that comes with the package. I suggest you get used to it. I have.

  • Deelip Menezes

    Anonymous/Evan,

    OK, before this gets personal and out of hand, I would like say that Evan and I and expressing our opinions. Neither of us (at least I don’t) have inside information about what goes on in SolidWorks.

    I don’t believe that there is anything wrong in jumping to conclusions, irrespective of whether they are right or wrong. If bloggers were to only write things that they are absolutely certain about, then blogs would be rather boring and would not spark off any interesting discussions.

    As regards Evan’s choice of words, that comes with the package. I suggest you get used to it. I have.

  • R. Paul Waddington

    I find the argument surrounding ‘CADD interoperability’ a very interesting one. There are, of course, some very real technical challenges to be overcome; but what seems to be the larger challenge is the limitations many commentating contributors place on the possibility based on ‘their’ belief of what can and cannot be done.The users of CADD software are designers and by definition that entails, at some point, creating NEW products; sometime ones that ‘some people’ said, at one point, ‘were impossible’. History shows actively looking into why something may be impossible often reveals a solution, in that respect Deelip is right on the mark!. All too often it is more convenient (marketing) to ‘say why it cannot be done’ than to actually do it and, I believe that is the case in this area. Just looking at what is done is a huge clue as to what could be done. I distinctly remember being in a room of people who said it would be impossible for people to use CADD for design work. Those statements were made over 38 years ago whilst I was seeing, and playing with, for the first time, the ‘first CADD’ system installed here in Oz. They were wrong and I believe most people who wish to argue the merits of 3D over 2D and promote the difficulties of ‘translating’ from one system to another and or one kernel to another etc., are also incorrect.If it is as important as it appears: what needs to happen is for people to understand interoperability between CADD systems may be difficult but it is far from impossible. As a user, it is not necessarily relevant how the sharing/translating of data is ‘done’: what is important is that it is done. For that to happen all that is needed is for users of CADD system to stop aligning themselves with the marketeers arguments, start thinking for themselves and begin leaning unmercifully on their vendors to MAKE it happen.

  • R. Paul Waddington

    I find the argument surrounding ‘CADD interoperability’ a very interesting one. There are, of course, some very real technical challenges to be overcome; but what seems to be the larger challenge is the limitations many commentating contributors place on the possibility based on ‘their’ belief of what can and cannot be done.

    The users of CADD software are designers and by definition that entails, at some point, creating NEW products; sometime ones that ‘some people’ said, at one point, ‘were impossible’. History shows actively looking into why something may be impossible often reveals a solution, in that respect Deelip is right on the mark!. All too often it is more convenient (marketing) to ‘say why it cannot be done’ than to actually do it and, I believe that is the case in this area. Just looking at what is done is a huge clue as to what could be done.

    I distinctly remember being in a room of people who said it would be impossible for people to use CADD for design work. Those statements were made over 38 years ago whilst I was seeing, and playing with, for the first time, the ‘first CADD’ system installed here in Oz. They were wrong and I believe most people who wish to argue the merits of 3D over 2D and promote the difficulties of ‘translating’ from one system to another and or one kernel to another etc., are also incorrect.

    If it is as important as it appears: what needs to happen is for people to understand interoperability between CADD systems may be difficult but it is far from impossible. As a user, it is not necessarily relevant how the sharing/translating of data is ‘done’: what is important is that it is done. For that to happen all that is needed is for users of CADD system to stop aligning themselves with the marketeers arguments, start thinking for themselves and begin leaning unmercifully on their vendors to MAKE it happen.

  • Deelip Menezes

    Paul, I find that you and I are beginning to agree on quite a few things. This is worrying. I thought we had initially agreed to differ. 😉

  • Deelip Menezes

    Paul, I find that you and I are beginning to agree on quite a few things. This is worrying. I thought we had initially agreed to differ. 😉

  • Anonymous

    Just to follow-up on the comments on IRONCAD. IRONCAD is a dual-modeling system that is able to support, in a single environment, both the ACIS and Parasolid kernels on both history based (feature base) and non-history models (direct editing) “Note here: IRONCAD supports both modeling environments where it can contain a history-based environment and support direct editing on the geometry whether it is history-based or imported b-rep – another note here – IRONCAD’s direct editing is mixed within the history-based model where it maintains the history and modifies only the necessary items to make direct edits (this capability has a patent and other systems including ST do not support this. Others systems primarily have a pure direct modeling environment (ST, CoCreate, etc) and others may add a direct edit as another feature in the history (SW, ST (SE traditional mode) – which we can support in our next version as well). However, the direct editing performed in IRONCAD is similar to CoCreate’s in that we handle more topological changes)”. The use for dual-kernels is used for multiple reasons. 1. Import/Export – Having both kernels allows IRONCAD a greater chance of interoperability since we can accept native ACIS and Parasolid formats. It also allows the ability to import standard formats (STEP, IGES, etc) using either native format which can greatly improve the chance of importing files successfully where as it may not be possible in a single modeling kernel. 2. Modeling – Users can design their models using a specified modeling kernel. This provides them the ability to work in the most common kernel that they may end up exporting to downstream in the design (helping to eliminate translation issues). However, IRONCAD has technology to “Kernel Collaborate” which is nearly invisible to the user. Kernel Collaboration means that IRONCAD can use both kernels to build the underlining solid model. For example: Say the user was working in ACIS to build their model. They add a blend to the model that ACIS cannot support for some reason. IRONCAD will automatically pass the operation to Parasolid to attempt the modeling operation. If successful, it will build the blend and maintain the model in ACIS. At this point, you might think I mistyped that…no I did not….The model is still in ACIS. However, the results of the body are made up of both Kernels. If the user exports to ACIS at this point, the result would still be the same since it is just the final b-rep body. IRONCAD does not have many issues in translating back and forth between ACIS and Parasolid once the model is inside of IRONCAD. We maintain a common tolerance which reduces many issues found in direct translations. In most modeling cases, you can take an ACIS model and change its type to Parasolid and visa-versa without any issues. Of course there may be the rare exceptions to this but IRONCAD performs regular testing on this capability. Most cases where issues would occur would be in non-manifold conditions where ACIS can support and Parasolid does not, but this is not normally a common modeling case. I didn’t read the initial thread about SW, but in IRONCAD’s case, there is not an issue handling the History-based models in either kernel. The main issue that they may face is that one kernel may support some new functionality that the other does not. In this event, the power of a dual environment has its advantage as well since IRONCAD can take advantage of either Kernels new functionality.

  • Anonymous

    Just to follow-up on the comments on IRONCAD. IRONCAD is a dual-modeling system that is able to support, in a single environment, both the ACIS and Parasolid kernels on both history based (feature base) and non-history models (direct editing) “Note here: IRONCAD supports both modeling environments where it can contain a history-based environment and support direct editing on the geometry whether it is history-based or imported b-rep – another note here – IRONCAD’s direct editing is mixed within the history-based model where it maintains the history and modifies only the necessary items to make direct edits (this capability has a patent and other systems including ST do not support this. Others systems primarily have a pure direct modeling environment (ST, CoCreate, etc) and others may add a direct edit as another feature in the history (SW, ST (SE traditional mode) – which we can support in our next version as well). However, the direct editing performed in IRONCAD is similar to CoCreate’s in that we handle more topological changes)”. The use for dual-kernels is used for multiple reasons.

    1. Import/Export – Having both kernels allows IRONCAD a greater chance of interoperability since we can accept native ACIS and Parasolid formats. It also allows the ability to import standard formats (STEP, IGES, etc) using either native format which can greatly improve the chance of importing files successfully where as it may not be possible in a single modeling kernel.

    2. Modeling – Users can design their models using a specified modeling kernel. This provides them the ability to work in the most common kernel that they may end up exporting to downstream in the design (helping to eliminate translation issues). However, IRONCAD has technology to “Kernel Collaborate” which is nearly invisible to the user. Kernel Collaboration means that IRONCAD can use both kernels to build the underlining solid model. For example: Say the user was working in ACIS to build their model. They add a blend to the model that ACIS cannot support for some reason. IRONCAD will automatically pass the operation to Parasolid to attempt the modeling operation. If successful, it will build the blend and maintain the model in ACIS. At this point, you might think I mistyped that…no I did not….The model is still in ACIS. However, the results of the body are made up of both Kernels. If the user exports to ACIS at this point, the result would still be the same since it is just the final b-rep body.

    IRONCAD does not have many issues in translating back and forth between ACIS and Parasolid once the model is inside of IRONCAD. We maintain a common tolerance which reduces many issues found in direct translations. In most modeling cases, you can take an ACIS model and change its type to Parasolid and visa-versa without any issues. Of course there may be the rare exceptions to this but IRONCAD performs regular testing on this capability. Most cases where issues would occur would be in non-manifold conditions where ACIS can support and Parasolid does not, but this is not normally a common modeling case.

    I didn’t read the initial thread about SW, but in IRONCAD’s case, there is not an issue handling the History-based models in either kernel. The main issue that they may face is that one kernel may support some new functionality that the other does not. In this event, the power of a dual environment has its advantage as well since IRONCAD can take advantage of either Kernels new functionality.

  • Anonymous

    About multi-kernel,I’ve some comments coming from my experience with kernel and with data translation.”IRONCAD does not have many issues in translating back and forth between ACIS and Parasolid once the model is inside of IRONCAD. We maintain a common tolerance which reduces many issues found in direct translations. In most modeling cases, you can take an ACIS model and change its type to Parasolid and visa-versa without any issues. “So, if you start with a Parasolid model having local tolerances, how do you translate it into an ACIS model having a single common tolerance? You will need to increase or decrease some tolerances, with the result that some points will become coincident and some other ones will become disconnected.And this is just one of the problems. Because yes, it is true that at the end of the history the model is made of a collection of surfaces stitched together.But any kernel has its own set of surface types, not just NURBS. So you will need to convert the ones that does not have a matching one, and introduce approximations.Even NURBS surfaces can be different. Some kernel has different limits in the definition of NURBS. Maybe a different maximum degree, or allowed continuity between patches, etc etc, and you will be forced to convert and approximate even NURBS surfaces!Alberto Savelli (think3)

  • Anonymous

    About multi-kernel,
    I’ve some comments coming from my experience with kernel and with data translation.

    “IRONCAD does not have many issues in translating back and forth between ACIS and Parasolid once the model is inside of IRONCAD. We maintain a common tolerance which reduces many issues found in direct translations. In most modeling cases, you can take an ACIS model and change its type to Parasolid and visa-versa without any issues. “

    So, if you start with a Parasolid model having local tolerances, how do you translate it into an ACIS model having a single common tolerance? You will need to increase or decrease some tolerances, with the result that some points will become coincident and some other ones will become disconnected.

    And this is just one of the problems. Because yes, it is true that at the end of the history the model is made of a collection of surfaces stitched together.
    But any kernel has its own set of surface types, not just NURBS. So you will need to convert the ones that does not have a matching one, and introduce approximations.
    Even NURBS surfaces can be different. Some kernel has different limits in the definition of NURBS. Maybe a different maximum degree, or allowed continuity between patches, etc etc, and you will be forced to convert and approximate even NURBS surfaces!

    Alberto Savelli (think3)

  • soliddna

    we could launch a big debate but from the strict point of view of exchanging data….NX and Solid Edge can dialogue and understand each other.Both can be operate inside the same environment and exchange data.Solid DNA

  • soliddna

    we could launch a big debate but from the strict point of view of exchanging data….

    NX and Solid Edge can dialogue and understand each other.
    Both can be operate inside the same environment and exchange data.

    Solid DNA

  • Dan

    Ok Deelip, I understand what you're saying about the integrity of the generic dumb models vs a SolidWorks native file. One would expect the SW native file to have absolutely no 'holes' in it. Perhaps my experience is limited, but I have done many complex models (for plastic molding) that I exported as Parasolid and brought back into various versions of SW with no issues. I would purposely do this to create a 'dumb' SW native file to send out for mold quotes & mfg. I can't say the same for IGES, STEP, or others, but Parasolid seems to work very well for me. It would be nice to have this feature built-in, I'm sure I'm not the only one doing it. Cheers!

  • Dan

    Ok Deelip, I understand what you're saying about the integrity of the generic dumb models vs a SolidWorks native file. One would expect the SW native file to have absolutely no 'holes' in it. Perhaps my experience is limited, but I have done many complex models (for plastic molding) that I exported as Parasolid and brought back into various versions of SW with no issues. I would purposely do this to create a 'dumb' SW native file to send out for mold quotes & mfg. I can't say the same for IGES, STEP, or others, but Parasolid seems to work very well for me. It would be nice to have this feature built-in, I'm sure I'm not the only one doing it. Cheers!