CCX 2.13

Hengre · December 2017

@kwip

I tried your last Version of ccx_2.13_MT from guthub
and it worked fine (even on my old i7 860 / model size app. 370.000 nodes ), results were same.

3rav · December 2017

Hi kwip,

How did you use openblas to compile ccx?

Regrads

kwip · December 2017

Yes, I did.

@edit I did not read properly. I'm using msys2 to compile ccx, here you can install openblas as precompiled binary. arpack-ng properly configures. When compiling ccx one points to spooles, arpack-ng and the system openblas.
quite straightforward.

regards

disla · December 2017

Just comment that old multithreading limitation of stiffness matrix assembly in ccx (CCX_NPROC_STIFFNESS=1) now works with all my 8 threads for me.
If anyone still have the system variable set to =1, I suggest to try all available threads.

Hengre · December 2017

Hi all,

when I run a nonlinear static Analysis 3D (contact) out of Mecway I get the result at the end of calculation (time step 1.)
How can I get and Show step Output in between 0 and 1.

Regards

Victor · December 2017

Is this just with kwip's one or in general? Normally, it should do that if you turn on Quasi-static in Analysis settings and specify the time step information.

Hengre · December 2017

hi Victor
thank you for answering. It was more in general.

I attached a sample file. If I run it 3D nonlinear with Quasi Static unchecked it produces reasonable values ( with Mecways ccx and kwip's one).

Switching to Quasi static (time step information 1s , 0.1s ) leads to very large stress values...

Victor · December 2017

Short answer: Ramp the X displacement by changing it from "-10" to "-10*t". Otherwise it tries to jam it into the full 10 mm displacement on the first time step and leave it there, but it somehow has trouble with that.

Long answer: This is a case where Mecway and CCX are organized differently so I'll make a big explanation for clarity.

Quasi-static off:

No concept of time in the Mecway UI - you cannot specify time dependence in loads, and there's none in the solution. Since CCX doesn't have such a mode, it's quietly run as time dependent with time period = 1 s, automatic incrementation, and some loads and constraints getting ramped from zero at t=0 to their full value at t=1 s which helps convergence (and apparently in this case, also helps find the correct solution). These details about time are hidden from the Mecway UI though.

Quasi-static on:

Time appears explicitly in the Mecway UI - you should specify loads as time dependent and the solution has time steps. CCX more directly does what you say regarding time. In particular, if you specify a constant load, it's made constant in CCX too. That's the opposite of CCX's default behavior of ramping loads automatically so it can be confusing if you're expecting that.

Hengre · December 2017

Thank you,
that worked well

Sergio · January 2018

Hi, I have tested other comercials solvers on the same machine (Intel i7-3632QM @2.2Ghz / 8GB RAM), with the same model/bc, and found that while was unnable to solve with CalculiX, even with half of the resources (cores and memory) the other ones solve easily, this is normal?

Problem had 313465 elements / 475968 nodes

On the other side, is possible to limit the memory that CCX will use it on a Windows 10 machine?

Regards

Andrea · January 2018

If the spooles solver requires a lot of memory try

SOLVER=ITERATIVE SCALING

It is slower than spooles (which is the default solver)

Sergio · January 2018

The iterative scaling option doesn't work. Have tested with 2.11 and 2.13.

Andrea · January 2018

Maybe depends from the CCX compiled version for Windows.
I use the versions contained on CalculiX Launcher and both iterative solvers are selectable.
Iterative Cholesky is generally faster than Iterative Scaling.

Hengre · February 2018

one more question on CCX

can anyone give the max number of nodes and/or elements that can be handeled with the ccx Versions.

Tryed to solve a model with approx.491000 elements and ccx failed (crashed)
Reduced model with around 390000 elements (coarse mesh) was solved...

thanks

Andrea · February 2018

See CCX manual about spooles solver. I think that depends from your RAM.
If I'm rigth you must consider the number of equations and not number of elements

Regards

Hengre · February 2018

Thank you,

you are right, it is the number of nodes and the degree of freedom of each node.
Unfortunately I don't find a clear statement in the ccx Manual

Has anyone experience with the max number of nodes/equations.

I am using 12 GB in my PC

Regards

Andrea · February 2018

If you are performing static analysis you can try iterative solver. See precedent post.

From CCX Manual:

SPOOLES is also very fast, but has no
out-of-core capability: the size of systems you can solve is limited by your
RAM memory. With 2GB of RAM you can solve up to 250,000 equations.

Hengre · February 2018

yes, from that i should be able to solve up to say 5 times of 250000 ?
(2 GB kept for OS and others)

Victor · February 2018

I'm not sure about CCX specifically but for most FEA solvers, memory use isn't proportional to the number of equations. It goes up a bit faster than that since the equations are stored in a 2D matrix not a 1D list of values. But it's a sparse matrix so it's not as bad as n^2. It's also strongly dependent on the mesh topology where less connectivity between nodes typically means less memory use.

I tried a 1,000,000 node (300,000 equations) model with CCX and 16 GB RAM and it used approximately all the RAM then suddenly exited after solving for a while with no solution. That was a plate 1 element thick which is a fairly low-memory type of shape. For something more solid, expect it to be worse.

Andrea · February 2018

See this Blog about direct and iterative solver

https://www.comsol.com/blogs/much-memory-needed-solve-large-comsol-models/

Mecway

Forum

CCX 2.13

Comments

Howdy, Stranger!