SW-Equivalent CAD that Uses Multiple Cores?

[Marshall Wilson]

As I wait forever while SW rebuilds my perforated part, I might as well ask the dumb question:

I know SW and Inventor are pretty much constrained by single-thread speed, but Is anyone aware of a SolidWorks competitor that takes advantage of multi-core processors?

Thanks!

m

[mike miller]

As I wait forever while SW rebuilds my perforated part, I might as well ask the dumb question:

I know SW and Inventor are pretty much constrained by single-thread speed, but Is anyone aware of a SolidWorks competitor that takes advantage of multi-core processors?

Thanks!

m

Solid Edge with Synchronous Tech. No history needed, no long rebuilds. We're experimenting with it right now.

[bnemec]

Not Solid Edge either. At least not the building of the model. There are things that can be asynchronous, often GUI and file/data moving.

The only way to get faster rebuild is clock cycles dedicated to the solid kernel thread and the pipeline to and from it; RAM, buss speeds, SSD speed, and maybe processor cache.

Maybe there's a new solid model kernel/solver out there that can asynchronously solve; I don't know, I haven't researched it. I'm guessing there isn't because if there were a good one with a reasonable GUI built around it that would take off because threads are cheaper than clock cycles and have been for over a decade.

edit after @mike miller post: Well, ok, Sync might be faster it's hard to say we were not able to incorporate it into our usage. It does feel much faster than rebuilding the feature tree but I don't know that it's a different solver under the hood that can actually use multiple cores to great benefit.

[Marshall Wilson]

Interesting @mike miller ; SE does sound like a different beast with it's treatment of the feature tree.... I'll see if I can work with a trial of SE.

I was kind of asking because many of the rival packages seem to be roughly equivalent but if any gave an edge in processing strategy, that' could be a real differentiator. Like @bnemec said, If there is a better way to asynchronously solve geometry, it could dominate the market. Not that I know a darn thing about it, but this seems like the kind of problem a very clever fella might be able to overcome.

Until then, I'm a slave to da clock.

[Jaylin Hochstetler]

edit after @mike miller post: Well, ok, Sync might be faster it's hard to say we were not able to incorporate it into our usage. It does feel much faster than rebuilding the feature tree but I don't know that it's a different solver under the hood that can actually use multiple cores to great benefit.

Just curious, why weren't you able to incorporate sync?

[MJuric]

As I wait forever while SW rebuilds my perforated part, I might as well ask the dumb question:

I know SW and Inventor are pretty much constrained by single-thread speed, but Is anyone aware of a SolidWorks competitor that takes advantage of multi-core processors?

Thanks!

m

Onshape runs on no cores Just started playing with it recently but from what I've read the majority of the work is done by the GPU not the CPU. Computations on line are run parallel on multiple machines. I suppose the limitation will be how many people are using the software at the same time and how much Onshape is willing to pay Amazon for more computing power.

[Marshall Wilson]

Onshape runs on no cores Just started playing with it recently but from what I've read the majority of the work is done by the GPU not the CPU. Computations on line are run parallel on multiple machines. I suppose the limitation will be how many people are using the software at the same time and how much Onshape is willing to pay Amazon for more computing power.

Good point @MJuric ... I've been meaning to give OnShape another try (it's been a few years since I played with it). the Cloud platforms do certainly seem to promise some real advantages, though as you mention I wonder how they will scale with complexity + many more users...

m

[bnemec]

edit after @mike miller post: Well, ok, Sync might be faster it's hard to say we were not able to incorporate it into our usage. It does feel much faster than rebuilding the feature tree but I don't know that it's a different solver under the hood that can actually use multiple cores to great benefit.

Just curious, why weren't you able to incorporate sync?

That could be a long discussion. We tried it a couple times, I think at ST4 (that was during my "Sabbatical" from this company) then I looked at it hard at ST9 and had a few demos from our SE VAR. I think I could summarize it into a couple points.

- training hurdle: many users touching these files over the next 10 - 20 years they would all need to agree on and understand the modeling methods used or the results may be unexpected or very inefficient.
- pushing and dragging appears to cause geometry to come and go and we couldn't nail down that would do to the hundreds of where used of these files that can have several relationships/mates to the geometries that may have disappeared when dragging stuff.
- risk management: We didn't have PDM or version control of any kind since there are no fully defined sketches controlling all the features, and the "Design Intent rules" don't stay with the file or the feature so there was no way to guarantee a revision only changed what was supposed to change and not some other area of the part.

The risk of bad data was perceived to be greater than the risk of missing out on the benefits. I'm not saying these are reasons or just excuses. Maybe @matt can rebuke my points.

[Arthur NY]

Just more as FYI the parasolid kernal that Solidworks runs on is made by Siemens which run Solidedge and NX. Not that it makes it necessarily any more multithreaded because there are different versions of the kernal that runs the software and Solidedge is running the latest kernal and Solidworks/DDS isn't interested in paying more $$$ to Siemens for the updated kernal. Hence why Solidworks, in about 5 - 10 years, will be gone and basically replaced with the 3DXP platform.

That said you might try using the freezebar so that only what's below it will rebuild rather than the whole tree.

[HerrTick]

It seems most (all so far) CAD rebuild processes do not lend themselves to multithreading. The same is true for FEA solvers.

[jcapriotti]

SolidWorks is multithreaded in some areas like drawing view rebuilds and opening files. I think some features may have some multi threaded rebuild capability but which ones escape me. Some simulation stuff is multithreaded.

Big problem in any history based 3d system is each feature is dependent on previous features and thus the linear rebuild requirement. Solid Edge has the Sync Tech thing so no features, no rebuilds. But I wonder how it performs with a large perforated pattern like you mentioned. Channeling @matt @Ry-guy

[matt]

.... But I wonder how it performs with a large perforated pattern like you mentioned. Channeling @matt @Ry-guy

Patterns of holes can be recognized a couple of ways in synchronous. One way is just as a bunch of dumb holes, so no special recognition. Second way is synchronous can recognize the collection of holes as a pattern, and actually treat them as a feature, but only for editing. It doesn't have to rebuild features after every new feature added, and there is no such thing as a parent or child feature.

I haven't tested it, but theoretically big patterns should be fast. I don't have a copy of the software currently. but I need to work on getting one.

[jcapriotti]

@matt I have the 2021 community edition. I tried to create a large perforated pattern but I had the part set as Ordered instead of Synchronous. It was locking up on large patterns that SolidWorks handled easily.....like a hole patterned in both directions 100 x 100. Maybe Sync mode would be better?

[Jaylin Hochstetler]

.... But I wonder how it performs with a large perforated pattern like you mentioned. Channeling @matt @Ry-guy

Patterns of holes can be recognized a couple of ways in synchronous. One way is just as a bunch of dumb holes, so no special recognition. Second way is synchronous can recognize the collection of holes as a pattern, and actually treat them as a feature, but only for editing. It doesn't have to rebuild features after every new feature added, and there is no such thing as a parent or child feature.

I haven't tested it, but theoretically big patterns should be fast. I don't have a copy of the software currently. but I need to work on getting one.

I tested this in a free trial of SE by making a 200 x 200" square, then I made a "fill pattern" of 1" holes 2" apart then I changed the width of the square to 2.1", and it froze.... It's been frozen for the last half hour now.

[Jaylin Hochstetler]

.... But I wonder how it performs with a large perforated pattern like you mentioned. Channeling @matt @Ry-guy

Patterns of holes can be recognized a couple of ways in synchronous. One way is just as a bunch of dumb holes, so no special recognition. Second way is synchronous can recognize the collection of holes as a pattern, and actually treat them as a feature, but only for editing. It doesn't have to rebuild features after every new feature added, and there is no such thing as a parent or child feature.

I haven't tested it, but theoretically big patterns should be fast. I don't have a copy of the software currently. but I need to work on getting one.

I tested this in a free trial of SE by making a 200 x 200" square, then I made a "fill pattern" of 1" holes 2" apart then I changed the width of the square to 2.1", and it froze.... It's been frozen for the last half hour now.

I tested the exact same thing in SW and it took approx a minute to rebuild. @matt did I do something forbidden in SE or is it simply that slow?

[matt]

I tested the exact same thing in SW and it took approx a minute to rebuild. @matt did I do something forbidden in SE or is it simply that slow?

I tested patterns, but it was a long time ago. I need to see about getting access to the software again.

[Ry-guy]

I tested the exact same thing in SW and it took approx a minute to rebuild. @matt did I do something forbidden in SE or is it simply that slow?

Your results are not going to be any faster or slower between the two. They are both using the Parsolid Kernel and the same solver. You may see a huge difference because SW, by default, has the full rebuild process turned off!

I'm a bit curious on your issue with SE rebuild time, too. That just doesn't sound right.

People have to keep in mind that synchronous technology was introduced as sepearte modeling practice. Today most companies are using ST in a hybrid method which is really what you need. Control what you need for model history and let the system manage the other procedural features.

I'm not sure if patterning is the same in NX and Solid Edge but I will say that NX has the ability for the user to define which method to use to calculate a pattern and how each pattern affects the faces it touches. There is Simple pattern, pattern face and pattern geometry. All these use different methods to significantly increase performance. I wouldn't be at all surprised if the code behind these feature options are not used in Solid Edge too!

[Ry-guy]

I tested the exact same thing in SW and it took approx a minute to rebuild. @matt did I do something forbidden in SE or is it simply that slow?

Your results are not going to be any faster or slower between the two. They are both using the Parsolid Kernel and the same solver. You may see a huge difference because SW, by default, has the full rebuild process turned off!

I'm a bit curious on your issue with SE rebuild time, too. That just doesn't sound right.

People have to keep in mind that synchronous technology was introduced as sepearte modeling practice. Today most companies are using ST in a hybrid method which is really what you need. Control what you need for model history and let the system manage the other procedural features.

I'm not sure if patterning is the same in NX and Solid Edge but I will say that NX has the ability for the user to define which method to use to calculate a pattern and how each pattern affects the faces it touches. There is Simple pattern, pattern face and pattern geometry. All these use different methods to significantly increase performance. I wouldn't be at all surprised if the code behind these feature options are not used in Solid Edge too!

OK, yes, it is not good forum etiquite to reply to your own post! But I did confirm that Solid Edge does have the Fast Pattern option which does not check how the geometry ineracts with other features on the model. Then there is the Smart Pattern which does do the checking. Either way a 100x100 pattern should not take long in SE.