CCX 2.13

kwipkwip
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.

https://github.com/ddfem/ccx_mingw64

regards
«1

Comments

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

    Regards
  • SergioSergio
    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

    Regards
  • kwipkwip
    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
  • SergioSergio
    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.
  • kwipkwip
    thanks mate, no problem, maybe I got caught on the wrong foot a bit :)

    regards
  • disladisla
    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.
  • kwipkwip
    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.

    regards
  • disladisla
    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.
  • kwipkwip
    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.

    regards
  • AndreaAndrea
    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
  • kwipkwip
    edited December 2017
    So we have to dig into arpack. Anyway, first I'll figure out how and why the environment can change the result of CCX
  • disladisla
    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.
  • AndreaAndrea
    edited December 2017
    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)
  • kwipkwip
    edited December 2017
    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.

    @edit:typo
  • VictorVictor
    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.
  • kwipkwip
    edited December 2017
    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.

    regards

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

    I downloaded ccx_2.13_MT.exe from https://github.com/ddfem/ccx_mingw64, 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.
    regards
  • VictorVictor
    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.
  • HengreHengre
    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 https://github.com/ddfem/ccx_mingw64
    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


    regards

  • disladisla
    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)
    CCX_NPROC_STIFFNESS =1

    Be sure to stablish CCX_NPROC_STIFFNESS =1. If not ccx will fail.At least it fails with me.
  • kwipkwip
    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?

    regards
  • HengreHengre
    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:
    Windows 7 64 bit

    system variables:
    CCX_NPROC_STIFFNESS=1
    NUMBER_OF_PROCESSORS=8
    OMP_NUM_THREADS=6

    the following remain from older ccx-Versions from others
    CCX NPROC EQUATION SOLVER=6
    NUMBER OF CPUS=6

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

    regards
  • kwipkwip
    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 ...
  • HengreHengre
    thx, please Keep me updated
  • kwipkwip
    @Hengre give it a try with: ccx_2.13_MT_apng_gen.exe

    regards
  • HengreHengre
    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

    regards
  • kwipkwip
    edited December 2017
    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

    @edit:typo
  • HengreHengre
    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!

  • kwipkwip
    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.
  • kwipkwip
    edited December 2017
    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.

    regards
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!

Sign In Register