CCX 2.13

hello fellow crunchers .. I've built ccx 2.13 ... fully MT, completely single file static ... use at your own risk.
I don't take any liability for the results obtained.



  • OK...
    For Mecway user: definition of spring elements is not compatible with CCX from version 2.12.

  • Somebody has seen a warning from the antivirus? In my case Windows defender says that the file is infected with Trojan:Win32/Azden.A!cl

  • kind of strange ... I recompiled it with different settings. I previously forced the compiler to include libwinthread, maybe here Windows Defender got upset ... thanks for testing and some positive feedback ... maybe a PM would serve the same purpose next time ... regards
  • Sorry if I use the wrong channel or words, was not my intention. I really appreciate your contributions, in fact I'm using your versions since years.
  • thanks mate, no problem, maybe I got caught on the wrong foot a bit :)

  • Be careful.
    With ccx_2.13_MT.exe use Buckling analysis carefully.
    Seems that for this new version solution with ccx_2.13_MT.exe could be right but with much higher number of elements than internal solver.
    On previous versions solution was not even symmetric for this particular case.
    Spurious modes are still appearing.
    CCX13 MT x1.png
    1308 x 1009 - 249K
    CCX13 MT x1 x2.png
    1334 x 1003 - 239K
    1359 x 1004 - 235K
    1174 x 855 - 157K
    EN 1993-1-6 EUROCODE 3 Strength and Stability of Shell Structures .pdf
  • unfortunately this is a known issue. I did not investigate it in depth, but it might be indruduced by CCX expanding shells to solids. Could you please provide the liml file so I can check if ccx on Windows behaves the same a ccx on Linux? Chrismas is coming, so there might be some time to solve or at least explain this issue.

  • Of course Kwip.
    It is no more than a validation file to check software reliability.
    If you are able to solve it, that would be a beautiful Christmas present.
    Good luck.
    I found the same issue with second triangles.
    Refining introduces even more spurious modes.
    By other way, new compilation of ccx 13MT seems really fast to me.
    Buckling Cylinder BC2BC2.liml
  • I could not wait and I have found a strange issue. Try to save the job as inp and run the ccx_2.13_MT.exe directly at the input-deck. then check the dat file ...
    Now capture the mecway ccx run by a simple wrapper in as ccx.bat file to be used instead of ccx
    @echo off
    start cmd /K "c:\path\to\ccx\ccx_2.13_MT.exe -i %1"

    which leaves you with a shell you can check the dat file again, you can run ccx again, always getting wrong and random results.
    There has to be something wrong with the environment ccx is started in from mecway.

  • The error found on buckling factor is not due to CCX version. Same error you will find using CCX under linux.
    Spurious mode were present also on previous version of CCX by MT

    Try with reduced integration elements
    1920 x 1052 - 724K
  • edited December 7
    So we have to dig into arpack. Anyway, first I'll figure out how and why the environment can change the result of CCX
  • kwip could be right when says "There has to be something with the environment ccx is started". Same file and same solver with MEC 7 and MEC 8 show an improvement in solution as I said on my previous post (now we have Symmetry). Andrea I remember you posting some similar problem that was not with the linux version.
    I can't find reduced integration for ccx in the new version so both images are computed without it.
    Victor , I would like to remark that having internal solver and ccx solver in MACWAY is really nice. I think it is a very clever way to provide versatility. No complains on Mecway. For me it is being a pleasure to be introduced to FEM with your software.
    MECWAY 8.png
    1371 x 1007 - 163K
    MECWAY 7.png
    1445 x 1003 - 175K
  • edited December 7
    disla: Andrea I remember you posting some similar problem that was not with the linux version...

    the problem was different because runing the solver the solution was completely wrong (wrong eigenvalue and wrong deformed shape). This case is different because there is a correct deformed shape but exagerated buckling factor. With more elements the solutions converges but the problem is the high initial discrepance. With shell elements I often found a similar problem and is necessary to perform convergence study.

    With RIE the solution converges more quickly. On my previous post the solution is obtained with 1710 elements (same model attached on your post)
  • edited December 8
    I did some research finding other projects having issues with ARPack which is kind of EOL. ocatve, scilab were forking their own implementation. There is some effort of consolidation, namely arpack-ng. I'll try to build CCX against this arpack version. Maybe we are lucky. I'll report back when I've put the required dependencies together.

  • These asymmetric solutions look very much like what you get with the internal solver if the shift point is too low. Eg 1e-7 gave the attached picture. It also changes each time you solve, like what CCX is doing.

    I think CCX uses ARPACK the same as the internal solver. I couldn't find a way to not have to specify a shift point so I wonder if it's perhaps hard coded or estimated in CCX and this makes it numerically unstable so that a different compiler makes it go wrong. That's just speculation though.

    disla - thanks for the feedback. Also, you can set reduced integration in v8 by entering the element type name in CCX element type under Loads & Constraints. I know it's not obvious sorry.
    low shift point.png
    886 x 604 - 63K
  • edited December 8
    I was comparing apples and oranges ... no env impact ... a ran an input deck with abaqus for reference ... here, I had to use S8R anyway. So I accidentally replicated Andrea's results :)
    I successfully compiled CCX with arpack-ng, no improvement. So I'm back to ccx itself.


    @edit: typo
    @add: ccx build with arpack-ng is available from github as well
  • Hello all

    I downloaded ccx_2.13_MT.exe from, saved it and tried to run it from inside Mecway, but the solver did not produce any Output.
    Any Idea what is wrong? Is something more required to make it run?
    Sorry for that stupid question.
  • Does the CCX Output button in the solver panel show anything? The text there is all generated by CCX.

    To check if CCX is producing any files:

    Turn on Tools -> Options -> CalculiX -> Same as the .liml file

    and solve again and see if any files appear.
  • That is the solver Output:


    CalculiX Version 2.13, Copyright(C) 1998-2017 Guido Dhondt
    CalculiX comes with ABSOLUTELY NO WARRANTY. This is free
    software, and you are welcome to redistribute it under
    certain conditions, see gpl.htm


    You are using an executable made on Di, 5. Dez 2017 11:57:33

    I turned on Tools -> Options -> CalculiX -> Same as the .liml file
    only the following files are there, when using ccx_2.13_MT.exe

    *.inp (seems ok)
    *.dat (empty)
    *.sta (empty)
    *.cfg (empty)

    I also tried other ccx_MT from
    ccx_2.12_MT.exe is not running at all - no solver message
    ccx_2.11_MT.exe Windows message, not running

    are there any DLL's required


  • What processor do you have in your computer?
    You need to add the system variables:

    NUMBER_OF_PROCESSORS="Max number of cores in your computer" (Should alrready be defined. I have 8)
    OMP_NUM_THREADS = "Max number of cores you want ccx to use" (I have 8)

    Be sure to stablish CCX_NPROC_STIFFNESS =1. If not ccx will fail.At least it fails with me.
  • the builds are fully static, no external libs are required. They are 64bit only.
    Did you try to save your model as inp to run it via windows-cmd?

  • Hello,

    I run the inp-file from windows-cmd and got the same result. Program starts but produces not more than the Output shown in Picture error1.jpg.
    (Macway's ccx solves the inp-file)

    CPU i use:
    i7 CPU 860@2.8 GHz ( 8 cores)

    Windows 7 64 bit

    system variables:

    the following remain from older ccx-Versions from others

    Can the problem be caused by the System variables?
    What are the right settings for ccx and ccx_MT?

    736 x 663 - 68K
  • I'll create a binary without a CPU specific tune to test asap. Maybe the mtune and march flags introduce an issue. Otherwise I have no idea ...
  • thx, please Keep me updated
  • @Hengre give it a try with: ccx_2.13_MT_apng_gen.exe

  • thx, I tried ccx_2.13_MT_apng_gen.exe and it is running.

    Kindly can you tell me what are the required settings of the System variables

  • edited December 13
    great to hear. The environment was not the problem. My Laptop is sporting a i7-6820HK from 2015. Your i7 860 is from 2009. I compiled my binary with the most recent gcc/gfortran using "-mtune=native" which uses "all" available optimization and instructions my i7 is able to handle. Thus, your i7 was not able to cope with this binary due to missing instructions etc. Now I've built the binary with the compiler flag "-mtune=generic" which uses "easy" instructions only.
    citing the gcc doc:
    "generic: Produce code optimized for the most common IA32/AMD64/EM64T processors."

    hope this helps

  • Thank's a lot for people like you beeing so deep in programming and doing all that work for the community (and for free!)

    I express my appreciation to you!

  • thx mate, thx for kind words. I'm happy you got a working binary. To find a solution for a problem is as rewarding as winning in sports or on the race track.
  • edited December 17
    I've rebuilt ccx from scratch with a generic tune ... in parallel I cleaned up github.
    The binary uses arpack-ng and openblas. I hope it runs well and on all 64bit cpus.

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!