Comments

• Victor

  February 2022

  You're right that they should behave the same if you scale time.
  
  Since the error message refers to the minimum increment (time step) size, I'd look at that. The default minimum is supposed to scale with time period but maybe Mecway overrode it incorrectly like that other bug you found. Can you show the *STATIC card that Mecway generated?
  
  Another possibility is that it was close to failing anyway and small numerical differences push it in one direction or the other. In that case, it wouldn't really be a bug but a sign to make the model more stable somehow.
  
  
• mmartin

  February 2022

  Dear DISLA:
  
  You are absolutely right. I had a lot of convergence troubles last week. I almost struggled and drop my nee.
  
  It is odd to me to be forced to consider 100 seconds as a "total time". I wanted to use 1 seconds (of course).
  I am aware about under restrained conditions but in this case, all three degrees of freedom are clamped , or at least this is what I think.
  This is definitely a large deflection problem with non linear material definition which is 100% non linear but I never imagined to have such a divergence troubles during calculation. I am considering to avoid non linear materials in order to get the form.
  
  I also considered to suggest CALCULIX to code an arc-length method to solve non linear equation systems. Even I am willing to pay for that(only if I can afford it).
  
  About quasi-static analysis, it is almost the same than a dynamic analysis but without accelerations, for that reason the time period of 100seconds make sense. Time matters!!
  
  Thank you for your comments
  
  MANUEL
  
• mmartin

  February 2022

  Dear VICTOR
  Thank for you replay.
  I do not think that the fabric is about to collapse because in this kind of structures all elements work in tension(zero compression allows==wrinkles ) .Let's see
• disla

  February 2022

  @Victor.
  
  Time Period=100s / Time Step=0.1s
  
  *WARNING reading *STATIC:
  the minimum increment 0.0000000000000000
  is smaller then 1.e-6 times the
  step time;
  the minimum increment is changed
  to 9.9999999999999991E-005
  which is the minimum of the initial
  increment time and 1.e-6 times the step time
  
  ** Generated by Mecway 14.0
  *STATIC
  0.1,100,0,0
  
  For Time Period=1s / Time Step=0.001s
  
  *WARNING reading *STATIC:
  the minimum increment 0.0000000000000000
  is smaller then 1.e-6 times the
  step time;
  the minimum increment is changed
  to 9.9999999999999995E-007
  which is the minimum of the initial
  increment time and 1.e-6 times the step time
  
  ** Generated by Mecway 14.0
  *STATIC
  0.001,1,0,0
  
  This morning the original file was unexpectedly failing too.
  I have downloaded the file again directly from the forum, run it, and it failed.
  I have erased all the previous files related to this example, clean the temporary folder, download the file again and let MECWAY to manage automatically the ccx working directory and then , magically, it converges again.
  
  Possible causes if it helps or could give some idea:
  
  -The graph for the displacement and g force is not updated when I change from 100s to 1s. (See picture). Maybe they are not correctly updated or ccx override to default.
  -Maybe there is some common configuration filename from previous runs that is interfering. Ccx generates some files with common names *.nam in the working directory.
  -Some values remains in memory and are taken by default.
  
  Meanwhile I will change my default Time Period to 100s just in case.
  
  
  

  screenshot.2.jpg 429.4K

  screenshot.1.jpg 444.6K
• mmartin

  February 2022

  DISLA, I am going to switch to CCX 2.17 solver (for example) to check it out. I will tell you
• Victor

  February 2022 edited February 2022

  Thanks for those details, @disla
  
  The graph keeps the maximum time range of the modeler and solution, so it's stuck at 100 s after you solve because the solution has that. This is intentional for consistency when you switch between the two.
  
  Regarding old temporary files. Mecway deletes any existing input (.inp) and output (.frd) file but ignores the others (.nam, etc). I don't think CCX reads any of these so I hope it's OK to leave them behind.
  
  My findings with @mmartin's original model:
  CCX 2.17 included with Mecway 14: Stops at 89.33 s
  CCX 2.17 compiled with MKL: Stops at 0.0007813 s
  CCX 2.19 ccx_static.exe from dhondt.de: Stops at 88.1 s, 0.00039 s, and 100 s on three successive runs. So 2.19 seems to be inconsistent between runs and that's perhaps what you were seeing. It might be caused by PASTIX.
  
  I think the real problem is that the model is a bit unstable. My guess is that failure at the start could be because there is very low bending stiffness against gravity before it's tensioned, so it might not find an initial stable shape. Failure near the end may be wrinkling which could involve some of the snap-through type buckling which CCX can't solve reliably.
  
  
• mmartin

  February 2022

  Good morning COMMUNITY, DISLA, VICTOR:
  
  [Thank you very much for your help.]
  
  I have being think about it. You are are right, and I am going to mention some important aspects from your comments:

  1. The model needs more stiffness,. The fact is, we are simulation fabric so some prestress is required needed according to the papers I am reading. I will create perimetral cables to tensile.
     
  2. In some cases, CCX solver produces different outputs but in general cases, the solver is stable, fast and perfectly suitable for our mechanical calculations.
     
  3. The form-finding process must be done slowly, not just as I did (to jump from 0 to 3metres top in one step").
     

  During the weekend I read papers about form-finding on tensile structures.
  I made up my mind, my approach is wrong and right now, I'm trying out a hand-made-multistep calculation in order to get the minimum constant tension surface. I am absolutely convinced that the form -finding shape can be performed using MW. MW+CCX has it all.
  
  To do that, I am planning to perform an incremental calculation consisting in :

  • STEP 1: Lift the boundaries a little bit(for example 20% of the height), then transfer the displacements to the model. The model is stable when applying smaller boundary displacements.
    
  • STEP 2: Lift the boundaries again another 20% of the height and after successfully solved, transfer the displacements to the model. This produce relaxation into a new fabric mesh(which is wider).
    
  • STEP N. Solve it again. Repeat this process until all boundaries are placed in the right place. I think that the final surface is the minimum constant stress surface so the form-finding process is done.
    

  
  
  MANUEL
• Victor

  February 2022

  Thanks for the update. I'm surprised that relaxing the stress as it goes is correct but it sounds like you understand it better than me.
• mmartin

  February 2022

  Thank you VICTOR , but I am trying out. I will let you know.
  MANUEL
• kennethfugate

  February 2022

  I've noticed that CCX seems to have less convergence problems with time and steps increased, i.e. 100s and 1s versus 1s and 0.01s, of course with BC equations adjusted accordingly. It shouldn't make a difference but it appears to as they have the same ratio. It may have to do with minimum time step size but that is scaled as well in relation to the time and step sizes.
  
  I'm using CCX 2.18 with Pastix and Pardiso and now 2.19 Pastix (default solver).
  
  Ken
• mmartin

  February 2022

  Good afternoon KENNEtHFUGATE:
  You are right but I do not know why.
  I realized that as soon as I increased the time period I got better convergence.
  In this case, I began calculations imposing 0-1 seconds range but I end up in 0-1000seconds.
  MANUEL
• prop_design

  February 2022 edited February 2022

  you might want to check your displacement conditions. i can think of an example where time step could affect convergence.
  
  imagine; max disp of 1mm ramped linearly to 1 sec., compared to max disp of 1mm ramped linearly to 100sec. the second case is not accelerating as fast. therefore, the force at each time step is less. causing the displacement at each time step to be less. which would make it more likely to converge. at least in reality. not sure if ccx computes inertial loads.
  
  i don't know if that is what you have going on or not. but maybe something to consider.
• kennethfugate

  February 2022

  The nonlinear static 3D analysis in CCX, including quasi-static, doesn't calculate inertia forces because material density is not a required input. Density is a required input in dynamic analysis because it does calculate inertia loads including wave motion.
  
  When I was an Abaqus user, mass scaling by changing density was a trick to make a dynamic run behave in a quasi-static manner.
• MikeMcMullen

  February 2022

  I believe the Calculix manual describes this in 6.9.7 of the CCX_2.19 manual. I think this is only in Explicit analysis. And yes there needs to be mass to use mass scaling. I have not gotten into explicit analysis in calculix yet as I am still running from mecway, but ran across it in the manual and may eventually use it for the sorts of problem I do.
• kennethfugate

  February 2022

  MikeMcMullen, thansk. I didn't notice the section in the CCX manual. I knew about mass scaling from previous Abaqus work.
  
  I posted a model of a ball denting a metal plate in this thread:
  
  https://mecway.com/forum/discussion/comment/5529/#Comment_5529
  
  It is a dynamic analysis with contact and plastic material definition.