Doubling the cores on a crash model rarely halves the run time. An engineering lead needs to know where the lost time goes. The next question is whether the extra license core hours pay off.
This post reads three recorded run profiles. Set A is one 8 core LS-DYNA run. Set B pairs that run with a 16 core LS-DYNA run. Set D compares OpenRadioss at 8 and 16 domains on a public Camry model.
Start with the phase split
Total wall clock hides the cause. The solver logs split each run into phases, and each phase scales differently.
In Set A, LS-DYNA R13.1.1 ran for 6,867 s on 8 cores. That is 15.26 license core hours. Element calculation took 4,961 s, or 72.2 percent. Contact took 1,638 s, or 23.9 percent. MPI wait and sync took 78.44 s, or 1.1 percent.
The profile reads these figures from the d3hsp and glstat files. Only text timing and energy files are used, with no 3D model data.
LS-DYNA from 8 to 16 cores
In Set B, the 16 core run took 4,159 s. That is a 1.65x speedup and 82.6 percent parallel efficiency. Each run saves 45 minutes of wall clock. License use rose from 15.26 to 18.48 core hours.
The phases show where the 17.4 percent scaling loss came from. Element time fell from 4,961 s to 2,695 s, a 1.84x gain. That phase scaled almost perfectly.
Contact fell from 1,638 s to 1,173 s, only a 1.40x gain. Its share of the run grew from 23.9 to 28.2 percent.
MPI wait and sync rose from 78.44 s to 160.9 s. Its share grew from 1.1 to 3.9 percent.
So the stall sits in two places. Contact search does not split cleanly across more ranks, and the ranks spend more time waiting on each other.
OpenRadioss from 8 to 16 domains
Set D shows a sharper stall. The run used an ARM Linux platform with GFortran and OpenMPI, with one thread per domain.
Wall clock fell from 1,475 s to 1,116 s. That is a 1.32x speedup and 66.1 percent parallel efficiency. License use rose from 3.28 to 4.96 core hours, which is 51 percent more.
Element time fell from 862.9 s to 578.7 s, a 1.49x gain. Contact fell from 246.5 s to 189.3 s, a 1.30x gain. MPI wait rose from 66.61 s to 84.42 s, and its share grew from 4.5 to 7.6 percent.
Here even the element phase scaled below 1.5x, and contact again scaled worst. With 66.1 percent efficiency, the profile gate reads below a 75 percent floor. Its stated options are to keep the 8 core baseline or repartition contact.
Speed only counts once the answer holds
A faster run is useless if the physics moved. Each profile checks energy before it reports speed.
In Set A, the energy ratio was 1.011 across 121 glstat output steps. In Set B, end of run glstat energy drift stayed within 0.0142 percent across 121 output steps. That passes a 0.05 percent ceiling.
In Set D, the 8 and 16 domain runs were compared at cycle 7100. Internal, kinetic and external energies matched to 4 printed digits.
Energy totals can still hide differences in single curves. The profiles say so plainly. They ask for curve output such as nodout from both runs, for a channel by channel check.
A method for your own scaling study
Run the model at two core counts on the same machine. Parse the phase times from the solver logs, not from the job scheduler.
Compute the speedup and parallel efficiency for each phase. A phase that scales near 2x is healthy. A phase that scales near 1.3x is the stall.
Watch the MPI wait share. When it grows, ranks are idle while others finish, which often points to load imbalance in contact.
Check energy drift or a printed energy match at a fixed cycle before you accept the faster run. Then weigh the wall clock saved against the extra license core hours.
The three sample profiles are open to read without an account at computelab.co/r.
Run your workload
Bring the kernel or solver run that costs you the most time. Run a workload with Computelab.co.