Yes, a typical workflow is that user makes a hull model in SW, then sets up a study to get analytical data, possibly in multiple conditions. For example, rotating the hull from 0 to 180° every 1° to get a stability curves and a whole bunch of other hydrostatic data. That is 180 scenarios. In each of them, on a fresh model, say it takes 5-15 iterations to converge on correct draft (waterline height) if that is the only variable that is being optimized. If, for example, another variable is added, such as optimizing trim angle (pitch up/down) based on difference between center of mass and center of buoyancy, then optimization becomes much harder, and now it’s 15-30 iterations, sometimes as much as 50. With a relatively complex model, each iteration might take 2-3 seconds to solve because of SW’s inherent speed of making these cuts. So say 180 x 15 x 2 = 5400s, that is 1.5 hours.
And then after seeing the results, user might want to make some changes to the model, and test again… Ok, if the changes are relatively small, convergence will be faster because of previously saved data points, but at least 3 cuts still needs to be made (relative best-case scenario), so 180 x 3 x 2 = 1080s or 18 minutes, big improvement, but still not very fast.
Aside from manual changes to the geometry, user might want to set up a design study to automate them, but still, you can that it takes a very long time. If it were possible to delegate running each scenario and it’s optimization on a separate thread, then it could be at least 8 times faster (assuming 8 threads). Since each scenario is independent from another, with data interrogation needed only at the end of study run, this would be very easy to achieve and would give massive performance boost.
Hey all, I got a response about that document I was looking for. So apparently it is a webpage that is still in the webarchive, here: Internet Archive: Scheduled Maintenance (currently webarchive is down, but hopefully it will get back up). There was also a sample project, attaching it to my message. Not exactly what I was hoping for, but maybe someone will find it useful.
To multi-thread calculation, the calculation need to be not depending on other calculation.
ie you can do 10 calculation in one step and then combine their results in next.
If calculation need to wait for other calculation’s result, multi-thread will slow down.
I used multi-tread to get info from website.
Start with single tread. Problem was website connection is not 100%, sometime it need reload. I added 30sec time out to reload. That’s 30s of doing nothing and I can get all the result within a day.
So I switch to 5 thread. While some thread got stuck reloading, other keep running. I got what I need in a few hours.
You need to look at your math code and see if it can be split.
I get that it’s theoretical and from a layperson so for the sake of conversation only: I like using various bodies when modeling complex things. Not multiple parts; I’m talking about tool bodies that are union, added, or subtracted downstream. They are not dependent on each other and can be reordered in the feature tree. This makes a very robust model that is easy to modify and maintain. Because the bodies are each stand alone, until the Boolean operation, they should be able to be built asynchronously.
That’s also part of master sketch/SSP. Everything dependent on one parent. Not a web of parents. Changes are predictable, not a lottery of how many random parts get modified.
Thanks for the advice; thing is, in my case the math I wrote is very fast, all done in a few milliseconds, while the API calls (specifically, body operations in SW) take minutes… And apparently that can’t be multi-threaded
I think the most straightforward way to do it is determine which bodies are related to which features (simple dependency tree check, should be super fast), and then dedicate solving each body feature sets on separate threads. However, that kind of thing can only be changed in geometric kernel… And as we know, SW runs leased Siemens kernel, I’m pretty sure SW devs don’t have access or legal rights to the source code of that kernel, which probably means not much hope for native multi-threading on SW.
