4

Debugging

4.1

Fixing Hashfixed is full.

LSU3shell is compiled with a static amount of memory available to store certain values. The number of these that it will store is in /lsu3shell-code/libraries/SU3ME/global_definitions.cpp.
For later reference, mine currently looks like:
/****************************************************************
global_definitions.cpp
Last modified 3/5/11.
****************************************************************/
#include <SU3ME/global_definitions.h>
#include <cstdio>
#include <cstdlib>
const char *su3shell_data_directory = getenv("SU3SHELL_DATA");
const unsigned nspsmax = 256;//sizeof(unsigned long)*8;
const unsigned nmax = 35;
namespace storage_limits
{
#ifdef SU3_9LM_HASHFIXED
size_t number_9lm_coeffs = 45000;
#else
size_t number_9lm_coeffs = 165001;
#endif
size_t number_freq_9lm_coeffs = 10001;
size_t number_u6lm_coeffs = 30000001;
size_t number_z6lm_coeffs = 7000001;
//
//
//
//

number_su3su3_coeffs:
Maximal number of SU(3) irreps (wf, wi) that can be connected by a tensor
w0 L0. Its value depend on model space and interaction used.
LSU3shell_analytics can be used to estimate its value.
size_t number_su3su3_coeffs = 7003;

}
The values number_9lm_coeffs, number_freq_9lm_coeffs, number_u6lm_coeffs, number_z6lm_
coeffs, and number_su3su3_coeffs (hereafter collectively referred to as coeffs) are all considered part of Hashfixed meaning that if the calculation you want requires even one more of any
of these values, the whole calculation will stop and youll get an error saying HashFixed is full.
This is yet another reason why running analytics is important.

Now, with the Hashfixed numbers shown above, if I tried to run a calculation for a 0+ state of
8 Be in a h4i model space, analytics quickly tells me (leaving out all of the leading information)
Process 0 starts calculation of me
HashFixed is full. size is 45000. empty is 45000.
and then exits the run. The important part is this last number: it tells you which coeffs value
has been exceeded. Comparing this back to the global_definitions.cpp file above, then we can
see we need more memory to store the number_9lm_coeffs than was allocated. Increasing this
number to 4, 500, 000 (and recompiling) yields a successful run. More importantly though, it tells
you how many coeffs were actually needed to do the calculation. For instance, that same run as
before now says
Process 0 starts calculation of me
Resulting time: 1.2102 seconds
#nnz:897935
Size of matrix in memory:4.75619 MB.
Size of frequent U9: 0.268623 MB.
Size of U9: 157.316 MB.
Size of U6: 802.961 MB.
Size of Z6: 187.107 MB.
Total size of memory:1152.41 MB.
Number of tensors with different values of w0 LL0:121
max size of HashFixed:105
#z6 stored :15567
#u6 stored :74471
#frequent 9lm :300
#other 9lm :275635
size of frequent u9
generated: 0.00150681 MB.
allocated for has data structures: 0.267117 MB.
size of other u9
generated: 2.82059 MB.
allocated for has data structures: 154.495 MB.
size of u6
generated: 1.87417 MB.
allocated for hash data structures: 801.087 MB.
size of z6
generated: 0.186829 MB.
allocated for hash data structures: 186.92 MB.
Simulation is done
Note that the order of reporting the coeffs (and what theyre called) has changed:
number_9lm_coeffs =
number_freq_9lm_coeffs =

#other 9lm
#frequent 9lm

number_u6lm_coeffs =

#u6 stored

number_z6lm_coeffs =

#z6 stored

and number_su3su3_coeffs is currently not directly reported by analytics (regardless of what the
global_definitions.cpp file says). Note this run only required 275, 635 of the 9lm_coeffs even
though LSU3shell allocated space for 4, 500, 000 of them. (Important side note: if you run analytics
on a diagonal block, you should multiply these coeffs values by 2.5 as you usually would
for Resulting time and Total size of memory for diagonal blocks since the above was for a
diagonal block, I should more accurately say that analytics predicts 687, 500 of the 9lm_coeffs
will be needed.)
The important thing here is that allocating large values of coeffs will require more memory.
So, if youre short on memory for a specific run and analytics is saying you arent using a large
portion of one of the coeffs, then you can feasibly reduce that one coeffs value and see if you
can get Total size of memory into an acceptable range. The downside to this approach though
is that youll have only one specific instance of the code, i.e. since youve tailored the number of
coeffs to work for this one hypothetical run, theres no longer a guarantee that itll immediately
work for a different run (unless all of your coeffs values are large which, as a trade-off, require
large amounts of memory).