Compile error for statdose

[gwu-reflexionmedical]

The compile took a lot of resources (Hard drive space and memory) when I use a large maxvoxel value, such as 300x300x400. And failed. (Even I have 50 GB space and 8 GB memory). Is it a bug or some architecture limitation?

Here is the error message: /usr/lib/gcc/x86_64-linux-gnu/5/crtbegin.o: In function deregister_tm_clones': crtstuff.c:(.text+0x1): relocation truncated to fit: R_X86_64_32 against symbol __TMC_END__' defined in .data section in /home/gwu/EGSnrc/HEN_HOUSE/bin/linux/statdose crtstuff.c:(.text+0x8): relocation truncated to fit: R_X86_64_32S against .tm_clone_table' crtstuff.c:(.text+0x21): relocation truncated to fit: R_X86_64_32 against .tm_clone_table' /usr/lib/gcc/x86_64-linux-gnu/5/crtbegin.o: In function register_tm_clones': crtstuff.c:(.text+0x41): relocation truncated to fit: R_X86_64_32 against symbol __TMC_END__' defined in .data section in /home/gwu/EGSnrc/HEN_HOUSE/bin/linux/statdose crtstuff.c:(.text+0x49): relocation truncated to fit: R_X86_64_32S against .tm_clone_table' crtstuff.c:(.text+0x6f): relocation truncated to fit: R_X86_64_32 against .tm_clone_table' /usr/lib/gcc/x86_64-linux-gnu/5/crtbegin.o: In function _do_global_dtors_aux': crtstuff.c:(.text+0x82): relocation truncated to fit: R_X86_64_PC32 against .bss' crtstuff.c:(.text+0x95): relocation truncated to fit: R_X86_64_PC32 against .bss' /tmp/ccb3Oayp.o: In function lettercount_': statdose_linux.f:(.text+0x1f0): relocation truncated to fit: R_X86_64_PC32 against .bss' statdose_linux.f:(.text+0x218): relocation truncated to fit: R_X86_64_PC32 against .bss' /tmp/ccb3Oayp.o: In function save': statdose_linux.f:(.text+0x26b): additional relocation overflows omitted from the output collect2: error: ld returned 1 exit status Makefile:39: recipe for target '/home/gwu/EGSnrc/HEN_HOUSE/bin/linux/statdose' failed make: *** [/home/gwu/EGSnrc/HEN_HOUSE/bin/linux/statdose] Error 1`

[ftessier]

This is most likely related to the gcc limitation in addressing. The default memory model is "small", with a limit of 2 GB for local static objects. If you have gcc 4.6 or newer on a x86-64 processor, you can try linking with the option -mcmodel=large to see if that fixes your problem.

[gwu-reflexionmedical]

Thanks! I did add this option -mcmodel=large in the Makefile, unfortunately, the make process still took a lot of resource, and it failed if I use a big matrix.

[gwu-reflexionmedical]

Another compile error on Ubuntu 16.04:

statdose_ubuntu64.f:3522:18:

      * OUTkmaxFILE
                  1
Error: Symbol ‘outkmaxfile’ at (1) has no IMPLICIT type
Makefile:39: recipe for target '/home/gwu/EGSnrc/HEN_HOUSE/bin/ubuntu64/statdose' failed

[ftessier]

Can you specify what compiler versions you have installed? @blakewalters can you take a look at this?

[gwu-reflexionmedical]

I used: gcc (Ubuntu 5.4.0-6ubuntu1~16.04.1) 5.4.0 20160609 g++ (Ubuntu 5.4.0-6ubuntu1~16.04.1) 5.4.0 20160609 GNU Fortran (Ubuntu 5.4.0-6ubuntu1~16.04.1) 5.4.0 20160609 GNU Make 4.1 Built for x86_64-pc-linux-gnu

[crcrewso]

Wow, I ran across this problem years ago and wrote my own dedicated code to get the stat I needed. I'll dig up some of those old 3ddose files and test the proposed fixes.

[ftessier]

@crcrewso any work around you can propose or test will certainly prove useful. Thank you!

[crcrewso]

Sorry @ftessier I missed your comment from a month ago. I don't think it would.

For interest: I wrote something on my old mac that loaded in the dose file and did the statistics I needed directly but it did not plot them (or have anything approaching correct orientation registration as all I needed was concentric centered cubes for determining homogeneity)

The applicable solution: For profiles we ended up creating dedicated high resolution runs for each axis of interest and simulating them one at a time.

[blakewalters]

In the short(er) term, try decreasing $NDIST1_MAX (the no. of data sets that can be stored internally at one time). Unless you're comparing dose from two different .3ddose files, you can even set this to 1. This should give you some more leeway on $MAXVOXX, $MAXVOXY and $MAXVOXZ.

[ojalaj]

The workaround from @blakewalters seemed to help in this.