I am facing with the following situation:
I have two identical shell models (I am using *RIGID BODY to connect some 1D elements). The only difference between the models is length units. In one I have used meters and in the other millimeters.
I am using ccx v2.17 in an Arch Linux based distribution.
When I run the models I got exactly the same results once converted to a common units. However, the time to obtain those results is so different: using meters I got them in less than 10 seconds; but using millimeters I got them in almost 7 minutes.
Does someone knows the explanation for this behavior?
Time using meters:
Time using millimeters:
did you check the .sta files? Are these nonlinear calculations? How may iterations did each of them need?
Hi Guido, thanks to answer to me.
.sta file are exactly the same in both models:
SUMMARY OF JOB INFORMATION
STEP INC ATT ITRS TOT TIME STEP TIME INC TIME
1 1 1 1 0.100000E+01 0.100000E+01 0.100000E+01
It is just one iteration because I am using the following for both models:
I fact, I can share you the input deck of the models and the models itself created using cgx:
Models are not absolute intentical, also I cannot because they have many external file, but you do not access to them.
Hi konstantin, thanks to check the models.
Node 16227 is a rotational node, so loads are moments. The differences in values are only the influence of length units.
The rest of the files can be automatically created if you execute .fbd files with cgx. As I am using the same names of .msh and .nam files for both models, it is recommended to create each model in different directories.
thanks, I will try to have a look at it.
Do you mind uploading all the .inp files? I don’t use CGX so I can’t easily regenerate them but would like to have a look at this too. It’s surprising since it’s not even nonlinear. All the unit conversions seem correct to me, except the Y coordinate of node 16228 but if that’s only a ROT NODE, it shouldn’t matter.
You could also try isolating the cause by removing features like the loads, rigid body, etc.
yes, i can confirm Spooles solver seem took too long to finish but i solved your millimetre units case for about 37sec using PaStiX solver. contrary behavior, it took near two times slowest for metre units case on my pc. just didn’t know why?
Could you clarify - results are same?
yes, it yield the same results for both models using consistent unit system. as can be seen in picture attached.
@xyont, Thank you for clarification.
As I understood, 2 models have same result (dependency of unit) but not same amounts of iterations. So, nonlinear solver algorithm is unit dependent, but not unit independent.
Unit mm - 418 sec.
Unit meter - 7.9 sec.
So, if we use kilometres, so calculation time will be less 8 sec. I will check.
it may happen for Spooles solver, but for PaStiX solver has shown contrary.
as i previously attached from the solver output logs:
- millimetre units ~37sec (12 iterations)
- metre units ~65sec (21 iterations)
this iteration may comes due to existence of connecting system between end beams & edge shell element using rigid body keywords.
*edited, i try to remove iteration in step keywords for now the calculation times near closed to millimetre units case.
Could you clarify, is RAM is enough for calculation that 2 models, or in mm model used linux swap partition for calculation?
Hi Victor, thanks for have a look at the models.
You are right, Y coordinate of node 16228 is not converted in mm model, I forgot to change that; but, as you mention, it does not matter because it is a rotational node.
For your convenience, I have uploaded mesh files in the shared folder of Models.
Given these models, the natural guilty of the differences is Rigid Body (RB). If I remove RBs and connect parts directly, the resultant model is a simple static linear problem, in that case both models are solved fast.
Hi Konstantin, thanks for your continued interest in the problem.
Both models use only RAM, no swap memory are needed. However, RAM used during ccx execution of millimeter model twice RAM used during ccx execution of meter model.
I found no problem with the MKL PARDISO version of CCX, only SPOOLES was slow on mm. Here are my results:
SPOOLES m: 6 s
SPOOLES mm: 228 s
PARDISO m: 6 s
PARDISO mm: 6 s