My personal rule, for the last year, as to how I use my core hours wisely, has been:
Start at 8 cores and increase incrementally until no error is obtained.
But I now have ‘Simulation Run’ data that blows that rule away:
WOW, using 64 cores took even longer in real time than 32 cores
Now my NEW rule has to become :
Take your ‘best guess’ at the number of Cores to use, then, if you are running many ‘similar’ setups that use core hours, make bracketed runs, on the number of Cores that you use, until you find the sweet spot
In light of my new data, does anyone else have a better way
I think this rule follows for meshing operations too but with the blazing speed of the’New mesh preview’ meshing algorithm (which I call TETforCFD ), meshing times are so very low anyway
EDIT: STOP READING NOW IF YOUR INTEREST IS ONLY THE ‘RULE’ but I have discovered that a VERY STRANGE CORE HOUR CHANGE IS REPORTED IN A COPY OF THE PROJECT FROM WHICH I EXTRACTED DATA FROM…
This EDIT section will be removed when the apparent BUG has been reported/fixed
Here is the chart of the data from a COPY of the original project:
I suspect that this is a BUG of incorrect reporting of ‘core hours used’ in copies of the project where runs are originally made… @jousefm what needs to be done to report this?
Here is my current account, which shows the original ‘core hours used’ as being what is reported in the original project but the copied project stills shows incorrectly (incorrect as in the chart directly above here)…
AND, here in the COPIED project where you can see one of the runs with the INCORRECT value of ‘284.8 core hrs used’: