Hello, My calculix install only build a cgx executable. I did not get a ccx executable. I would like to run the airfoil test case. Will the ccx executable be generated by the call to cgx -b send_penta.fbl?
Is it possible to build ccx directly, without the GUI interface?
What instructions are you using to build calculix? You can try this prebuilt executable for linux here:
Thanks so much for the reply. I am following the INSTALL instructions that come with the download from this URL http://www.dhondt.de/.
A pre-build executable is of no use, as we need to port the code to other systems and we need to optimize compiler flags etc for each architecture. If you could point me to instructions on how to build ccx that would be of tremendous help.
Have you tried the ccx install instructions? http://www.dhondt.de/ccx_2.20.README.INSTALL. I always go to the “If you like a slower pace, here some more information:” section.
My installation script should automate the whole ccx build. It’s the same one I linked to earlier when you asked about the MPI calculix.
I am doubtful there will be any noticeable speedup when playing with compiler flags. If you do notice anything, do share!
This is valuable information. Thanks so much. I had in the meantime build ccx 2.18 downloaded from here: git clone GitHub - ISCPC/CalculiX-Builder.
I have not tested it yet, but at least I got it build using the Intel compiler and MKL. I built with make NPROCS=40, hoping this will utilize 40 cores on our skylake nodes.
I read through the 2.20 ccx instruction and see no mention of how to select a compiler or how to specify that MKL should be used. I will report back once I get it done.
Dear All,
I’m new, so in advance apologize for eventual mistakes in using that forum - hope to learn and adopt.
I try to compile the ccx_2.17 and ccx_2.20 with Spooles and Arpack in sequential mode.
I’ve followed the instructions: get the file spooles.a , libarpack_linux.a and stared to compile ccx_2.17 and ccx_2.20.
The compilation is starting and running but at the end I get the message
collect2: error: ld returned 1 exit status
make: *** [Makefile:29: ccx_2.17] Error 1
and the executable ccx_2.17 or ccx_2.20 is nowhere to find.
On the Internet could read that apparently this can be some problem with the linker and I think also the line 29 in ccx Makefile starts the linking process.
But have no idea how to solve that problem so any help is highly appreciated and I do thank in advance. Thank you.
We need more information from the screen output to understand what is missing. Usually, make gives some hints about the files or where it returns these errors. Please post that and let’s see what we get…
Hello,
I do apologize for some delay in answering, but really did not hope to get support so fast and get away from the computer.
I linked the make command to log.out and get ca. 2400 lines but the last one are:
a - writenewmesh.o
./date.pl; cc -Wall -O2 -I …/…/…/SPOOLES.2.2 -DARCH=“Linux” -DSPOOLES -DARPACK -DMATRIXSTORAGE -DNETWORKOUT -c ccx_2.17.c; gfortran -Wall -O2 -o ccx_2.17 ccx_2.17.o ccx_2.17.a …/…/…/SPOOLES.2.2/spooles.a …/…/…/ARPACK/ARPACK/libarpack_linux.a -lpthread -lm -lc
~
on the screen the last message I can see are:
/usr/bin/ld: dsapps.f:(.text+0xec9): undefined reference to dvout_' /usr/bin/ld: dsapps.f:(.text+0xf02): undefined reference to dvout_
/usr/bin/ld: dsapps.f:(.text+0xf40): undefined reference to `dvout_’
collect2: error: ld returned 1 exit status
make: *** [Makefile:29: ccx_2.17] Error 1
I’ve also noticed that the messages I can see on the screen are different then those I get with
make < log.out
which is also a surprise for me, because I thought that they will be the same.
Actually in the log.out file a can not find any typical error messages: only 2 object files: errorestimator.o and inputerror.o. (when I search for word error)
Only the screen output shows some error message - I thought that maybe the binary file could not be written to the target directory ?
I’m sorry, of course to command was make > log.out
…
a - stos.o
a - strcmp1.o
a - strcmp2.o
a - strcpy1.o
a - stress_sen_2ndorder.o
a - stress_sen_dv.o
a - stress_sen_dx.o
a - stressmain.o
a - strsplt.o
a - tau.o
a - thicknessmain.o
a - tiedcontact.o
a - trafontmortar2.o
a - trafontspcmpc.o
a - transformspcsmpcs_quad.o
a - transitionmain.o
a - transpose.o
a - u_calloc.o
a - u_free.o
a - u_malloc.o
a - u_realloc.o
a - utempread.o
a - v_betrag.o
a - v_prod.o
a - v_result.o
a - worparll.o
a - writeheading.o
a - writenewmesh.o
./date.pl; cc -Wall -O2 -I …/…/…/SPOOLES.2.2 -DARCH=“Linux” -DSPOOLES -DARPACK -DMATRIXSTORAGE -DNETWORKOUT -c ccx_2.17.c; gfortran -Wall -O2 -o ccx_2.17 ccx_2.17.o ccx_2.17.a …/…/…/SPOOLES.2.2/spooles.a …/…/…/ARPACK/ARPACK/libarpack_linux.a -lpthread -lm -lc
It seems like an ARPACK problem… I would start by checking the Arpack executable and all the warning messages there.
Thanks a lot. I will do it once more.
But actually I recompiled the ARPACK several times on ccx_2.17 and ccx_2.20: each time rm the binary and the object files, just to start from scratch.
I also checked the
In ARPACK/UTIL/second.f change: EXTERNAL ETIME to *EXTERNAL ETIM
I’ve been following the instruction:
and during ARPACK compilation and recompilation I did not get any errors.
1 Like
Yeah, check again. Make sure you do clean the whole directory from older object files (make clean I think…).
Actually I get 1 error message but I think it’s not relevant for compilation:
second.f:24:7:
24 | *EXTERNAL ETIME
| 1
Error: Invalid character in name at (1)
make[1]: *** [Makefile:47: second.o] Error 1
Makefile:50: warning: overriding recipe for target ‘.f.o’
…/ARmake.inc:95: warning: ignoring old recipe for target ‘.f.o’
The last make lib > log.out prints are:
ranlib /home/maciej/CalculiX217/ARPACK/ARPACK/libarpack_linux.a
make[1]: Leaving directory ‘/home/maciej/CalculiX217/ARPACK/ARPACK/SRC’
ranlib /home/maciej/CalculiX217/ARPACK/ARPACK/libarpack_linux.a
If it is an error, I believe it won’t compile fully… Change that first character on line 24.
I cancelled the * in line 24
rm, clean and compiled ARPACK once more,
then ccx:
/usr/bin/ld: /home/maciej/CalculiXSPOOLESOrig/ARPACK/ARPACK/libarpack_linux.a(second.o): in function second.f:(.text+0xe): undefined reference to etime_’
collect2: error: ld returned 1 exit status
make: *** [Makefile:29: ccx_2.20] Error 1
Try the different comment-out characters “c” or “!”, only on the 1st column…
Sorry, but unfortunately I do not have any experience with Fortran code.
You mean something like:
c EXTERNAL ETIME
I compiled the code following your advice - depicted above.
It compiled without errors, last print out from make > log.out is:
r - writeoldmesh.o
./date.pl; cc -Wall -O2 -I …/…/…/SPOOLES -DARCH=“Linux” -DSPOOLES -DARPACK -DMATRIXSTORAGE -DNETWORKOUT -c ccx_2.20.c; gfortran -Wall -O2 -o ccx_2.20 ccx_2.20.o ccx_2.20.a /home/maciej/CalculiXSPOOLESOrig/SPOOLES/spooles.a /home/maciej/CalculiXSPOOLESOrig/ARPACK/ARPACK/libarpack_linux.a -lpthread -lm -lc -fopenmp
also no Waring on the screen - sorry did not make a print screen.
Get a ccx_2.20 file and changed the permission with chmod a+rx ccx_2.20 (I think this step was not necessary)
I get:
maciej@maciej-T7500:~/ARPACK-ng$ ./ccx_2.20
Usage: CalculiX.exe -i jobname
maciej@maciej-T7500:~/ARPACK-ng$ ./ccx_2.20 -version
This is Version 2.20
maciej@maciej-T7500:~/ARPACK-ng$
So for me this is a huge progress and I do thank you very much for the support and guiding me - I would never thought that the problem is with ARPACK and I would look somewhere else.
But the question is how will the code behave after this change - in each instruction I’ve found on the Internet was stated clearly:
In ARPACK/UTIL/second.f change: EXTERNAL ETIME to *EXTERNAL ETIM
As you see I have downloaded the ARPACK-ng library and will try to try this way.
But as said really thank you very much for the great help and support I have received from you 
1 Like
Hello once more,
I think I’ve misunderstood the meaning of the * sign in the instruction.
Originally I thought that it is some kind of pointer.
But it seems that the right understanding should be: comment it out.
When I put the * in the first column, the the compilation runs without errors - i.e. just as previously with sign c.
So once more thank you very much for the support, and correctly identifying my problem especially as I would look into other direction and by that loose only time and maybe patience.