I am reviewing the use of Calculix but haven’t yet decided whether to install it.
I think I have read that it doesn’t have a bandwidth reduction algorithm Is this a problem?
I use Cubit to do mesh generation and it throws up some random node numbers which would lead to a huge bandwidth which isn’t a problem if ther solver has a bandwidth reduction scheme. I don’t know if this would work with Calculix.
Any advice would be appreciated. Thanks.
Hi Bill,
i am also using Cubit for my preprocessing. I haven’t encountered issues with the bandwidth so far, maybe my models are too small.
I recently pushed a component for cubit on github Cubit-CalculiX, to get the preprocessing done for calculix. Would be glad if you try it, any feedback is appreciated.
The manual states as one of the “golden rules” that you should avoid large gaps in node and element numbering to reduce memory requirements. Which would imply that general renumbering is not done. Recent manuals only mention renumbering for fluid elements in the context of three-dimensional Navier-Stokes calculations.
Writing e.g. a Python script to do node and element renumbering would be algorithmically trivial. A mapping (dictionary in Python terms) of old → new numbers would do the trick. After creating a mapping for nodes and elements one would have to rewrite all the node and element sets.
I too have read the “golden rules” and came to the same conclusion hence my question.
A simple renumbering scheme which merely removes the blanks in the node numbering would indeed be simple, however a true skyline reduction scheme which looks at all of the element connectivities is a much more complicated affair. There used to be Fortran libraries of numerical routines like this but I don’t know if I could find them now and I wouldn’t have a clue how to link them in to Calculix.
If my understanding is correct, the gaps in node/element numbering can impact memory usage, depending on the solver. E.g. with spooles and maybe also pastix. I don’t think the “skyline”/“bandwidth” would matter much in this case since the matrix is sparse anyway.
The iterative solver uses a lot less memory in my experience but can be slow if the mesh is long and slender. Which is why I tend to stick with spooles and tune my models to fit in memory.
PrePoMax have a feature node and element to renumber, but i’m rare in use and did not know how is work and affects the solver.
another solver named OpenSees have this feature internally by keyword commands, default numberer is RCM from references.
I just did a quick test by renumbering node 30 to 10000030 in a 19000 node model and it increased solve time by 5-10%.
First time is with node 30, second is with 10000030:
Pastix: 5.6 seconds, 6.2 seconds
Spooles: 14.7 seconds, 15.7 seconds
So it doesn’t look like something to worry about. I know Pardiso does its own bandwidth optimization and the others probably do too. My guess is the difference may be caused by the extra 10 million “non-zeros” on the diagonal or just something internal to CCX allocating space for all those non-existant nodes.
What was the effect on the memory usage?
I renumbered node 20 to 100020 in a 692 node model, using spooles.
The time went from 0.03 s to 0.06 seconds, but the resident set size went from 20076 kB to 56900 kB.
So yeah, you want to have contiguous node numbers at least when using spooles as the solver.
Not sure how to measure memory use.
You might need a bigger model to see a more realistic effect. I don’t think non-existent nodes appear in the matrix but CCX does allocate space for some data about them. So as model size increases, I would expect the relative difference in memory use to shrink.
On UNIX-like system, running a command via time -l
, e.g. time -l ccx -i job
will print the time it took and a whole lot of extra info.
Including the resident set size.
On ms-windows, you can find the used memory in the task manager as long as the program is running.
From the ccx
manual:
The memory needed to run a problem depends on the largest node and element numbers
To me, that sounds like the highest numbers are used to allocate space for the matrix.
There isn’t really time to be sure Task manager is up to date for these small fast problems.
CCX output from my 19000 nodes example -
With node 30:
number of equations
53856
number of nonzero lower triangular matrix elements
4234590
With node 10000030:
number of equations
53859
number of nonzero lower triangular matrix elements
4234863
It’s basically the same.
EDIT: I’d forgotten to update a boundary condition for the renumbering. Now they both show exactly the same numbers of equations and nonzeros. Run times are still ~5% different with Spooles.