Thanks for your comment. Of course you can now use 9.2 which is just a little faster still than 9.1.

You mention that the implicit time step tends to go unstable when have rapid changes, impulses, high frequency responses etc. Such systems do generally need shorter time steps and as far as I am aware there is no getting around that. Variable time step schemes can help by using longer time steps when possible.

It sounds like you have an interesting model and if you would like us to take a look at it we’d be more than happy to try to speed it up either by making modelling changes or try possible changes to the software.

Good luck for all the Orcina team, hope new year would bring good staff to users.

Your options b) and c) will run at roughly the same speed. If anything I would expect c) to be slightly faster. You are right that option a) will be around twice as slow as the others.

Option b) does multi-thread in both windows so there will be 4 threads competing for resources on your dual core machine. This is why option c) is a little more efficient.

The best way to handle multiple load cases now is:

1. Upgrade to version 9.2 (9.2b is better than 9.2a).
2. Make your batch script use the “SaveData” command rather than “Run” so that it simply generates a .dat file for each load case.
3. Add each .dat file to the batch window and run.

Of course if you can get a quad core, or even a dual quad core (=8 cores) then your load cases will be processed even faster.

Hope this is all clear.

a) a batch script with all 20 cases, running one at a time, multi threading,
b) open two orcaflex windows, each running 10 cases at a time,
c) one orcaflex window, running two at a time in parallel (cores set to 2).

I understood b) and c) to be as fast as each other, but from the recent user group meeting think case a) is slower.

Does option b) multi thread in both windows or use one core for each?

Which (if any) of these cases are equivalent?

That’s a very interesting suggestion.

Within the post-processing spreadsheet’s context of a VBA macro multi-threading is impossible (VBA doesn’t support it). Potentially we could multi-thread the results extraction in our DLL but I’m sure that would not offer significant or scalable benefits.

The right approach is as you suggest to process each simulation file in a separate thread (perhaps even distributed across several workstations).

We’ll have to think about this one because there is no easy solution to offer you.

In the meantime I would be interested in looking at your spreadsheet (and of course a typical dat file to run it with) to see if there’s any obvious way we can optimise what we currently have.

Cheers, David.

WSS has a single tolerance value that applies to all DOFs (nodes, buoys etc.) So if it reports “statics complete”, then as I understand it all DOFs will have met the tolerance. Is it possible that the problem was caused by not all buoy DOFs being included in statics? Anyway, if you can still find the problem file then I’d appreciate it if you could e-mail it to us so that we can investigate.

Cheers, David.

Caspar Heyl