I'm now stuck trying to calculate the time-rate-of-change of pebble overlap, d(deltan)/dt, in order to create a kind of 'viscous damping' term in a contact model.
I've looked through lammps developer guide and there are walkthroughs on how to grow an array to grant access per/atom properties from previous timesteps (i.e. position, velocity, etc.). But contact information is a little more difficult because I have to use something similar to the tangential_model_history where there's a flag for contact, so I can't just create some generic array that maintains all overlap values.
There may be more I can take from studying the tangential history model more, but at the moment it seems like shears are incremented without needing to access any data from prior timesteps. Can anyone tell me if I'm wrong in this assumption?
I know that the SurfacesInstersectData structure holds deltan as well as the contact flag, but I'm not clear on how I can transfer the data into future timesteps/from past ones.
Jon
ckloss | Mon, 11/21/2016 - 20:37
Hi Jon,
Hi Jon,
to access the contact data from last time-step, your contact model must store it. You can do this very similar to the way "tangential history" is storing the tangential overlap and using the last timestep's value in the current one
Best wishes
Christoph
jtvanlew | Mon, 01/30/2017 - 04:18
inconsistent results
Hi Christoph,
Thanks for the tip.
I was working on this again last week and ran into an issue I can't figure out. I created another variable in the SurfacesIntersectData data structure for storing the overlap from the previous timestep. Then in my normal contact model i have something like
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
deltan_tm1 = sidata.deltan_tm1 // overlap @ step "t minus 1"
deltan_t = sidata.deltan // overlap @ step "t"
fprintf(screen,"\n current overlap: %e", deltan_t);
fprintf(screen,"\n last timestep overlap (beginning of code): %e", deltan_tm1);
[ do stuff with code ]
// assign current overlap into "t minus 1" for the next timestep access
sidata.deltan_tm1 = deltan_t // overlap @ step t --> overlap of "t minus 1" for the next timestep
fprintf(screen,"\n last timestep overlap (end of code): %e", sidata.deltan_tm1);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I'm doing a simple test case of a single particle pressed between two meshes (one mesh moves in a prescribed fashion along one axis).
now the issue is that every other time step, when i pull the value of sidata.deltan_tm1 (in the beginning of code), i get a value of something like 1e-318; but every other time step it is the correct value of the previous timesteps overlap. as best i can tell, the final command assigning deltan_t into sidata.deltan_tm1 is simply not being preserved into the next timestep. the "print" command for "end of code" value is always correct. but then the value pulled at the beginning of the code is wrong at the next timestep.
i can't figure this out at all and it's driving me crazy. i can't seem to figure out why anything would be different from 1 timestep to the next. anyone have any ideas?
Daniel Queteschiner | Tue, 01/31/2017 - 09:42
SurfacesIntersectData
Contact data is typically only valid during one timestep. That's why there is the contact history mechanism to preserve data over time. Do as Christoph has suggested and use this mechanism. Look for example at tangential_model_history.h to see how this works.
jtvanlew | Thu, 02/02/2017 - 07:45
THANK YOU!
Daniel, thank you for pointing me to the exact line of code! I thought I had heeded Christoph's suggestion but I didn't realize I was mimicking the wrong part of the code. I did a pretty direct copy and have something like this now in my contact model:
history_overlap = hsetup->add_history_value("deltan_tm1", "1");
[other code]
double * const deltan_tm1 = &sidata.contact_history[history_overlap];
[other code]
deltan_tm1[0] = sidata.deltan
and it is working out for me so far!