Underlying mechanism of "solve time"

Hello everyone
I find some weird things that the “solve time 2.0” is not equal to “solve time 1.0” + solve time 1.0" in some cases even though I use the fix timestep and ‘cycle’ to control. The following are my test results about plate load on particle assemble(r=0.05m) where the linear contact model is adopted and the F-z(force-displacement) is used to reflect the results. the schematic figure is shown as
I set different load strategies including “solve time 5.0”, “solve time 2.5” + “solve time 2.5”, and “solve time 2.0” + “solve time 2.0” + “solve time 1.0”. and the following are the results.
as you can see, the results are not completely coincident. Even though I used fixed timestep and cycle number, there’s still some difference, as shown below:
so, what’s the reason? maybe this is not ordinary for an explicit calculation process. is this related to the chaotic and instability?
In addition, when I use the cubic assemble to do the same test, this phenomena will disappear. All the test script is available.

Hello @LJYpyu,

My initial guess is that the initial assembly of balls is different for each test. This can happen if the model random seed is not the same for each run or if determinism is switched off. If that is not the case, I would need to see your model to see if there are any inconsistencies.

Thank you very much for the discussion! Actually, I have noticed the issues mentioned by you, so the model random seed has been given and the determinism was on. additionally, all the loads start from the same state. that’s exactly why I’m confused. I put my script file in the attachment(the “.sav” is not an available file format here). thanks again!
script.dat (2.8 KB)

Thanks @LJYpyu, I will take a look at your data files.

@LJYpyu , could you please confirm which version of PFC you are using.

PFC6.0version13 sir, thank you! and I can’t see any fix about this issue on the website.by the way, Is it working properly on your computer?

Excuse me sir, is there any approach to solve this problem? or any potential explanation

Hello @LJYpyu, I am still looking into this issue. I hope to have an explanation shortly. Thank you for your patience.

Hello @LJYpyu. I tired to run your model, however I was unable to solve to the ‘consolidation-1.sav’ state. If I add in damping and set the time step to scale (which is recommend when creating the initial assembly), I could quickly reach the initial state. After that the model ran fine and without any discrepancy between solves.

How many cycles did it take you to reach the initial save state? I was over 4e6 cycles.

Thanks for the reply, I add local damp 0.7 to reach the initial state without timestep scale while it takes 4e5 cycles.

Are the plots above in the original question with damping. Also, it looks like with damping it only take 4e5 cycles?

I’m sorry it takes 4e5 cycles , yes i add the local damp to reach the initial state and then i remove it in the loading process. i have tried your approach and it takes 2e5 to reach the initial state. the discrepancy still exist…

so, is it still consistent?

Hello @LJYpyu, here is what I found, when you stop/start cycling there is automatically a contact detection event that occurs. When continuing to cycle, though, contact detection happens on an as-needed basis. So it may be the case that some contacts are deleted/created when you stop/start cycling that would be created/deleted at a slightly different time if you just continue to cycle. Even one different contact will change the results of the computation in a multithreaded environment especially. Both results are equally viable from a computational POV, just different.

Thank you very much! That’s the answer I exactly want, which is clearly about underlying reason. so kind to you to pay attention and patience to my question, thanks again! it’s my pleasure to discuss with you. BTW, this effect seems like more observable when the bonded granular sample undergoes the bond breakage .