the GPU module and the multicore module

[yibing Yan]

hello there,

I am tring to perform a simulation which I want to put an object like a spoon and scoop the sand(granular objects) to see the force in the process.

I find that demo_GPU_mixer.cpp demo can be referenced, but I am not sure whether I need to add a container holding those sand and give the granular objects gravity. If this is so, should I use CreateCylindricalContainerFromBoxes to add container and use cohesion_ratio  in the .json to add the gravity? Also, I am sad that I have a poor GPU so that it really take a long long time to run the gpu module.

Then I find that there are also some granular objects demos in the multicore module, I find some demos about a container with granular material. And I can run those demos faster.

Now I am confused about what thing to do next is much better.

Any help will be appreciated, thank you so much in advance.

[Ruochun Zhang]

Hi,

The GPU module does benefit a lot from more recent hardware. If your test case does not feature a huge number of bodies, say some 10k, then multicore can be a good choice. It probably requires less learning from you too.

It should be noted that Chrono::GPU is not "Chrono on GPU". Most Chrono core classes and methods cannot be used in Chrono::GPU. For all purposes, Chrono::GPU can be seen as a standalone DEM solver for monodisperse spherical particles, implemented on GPU. It should be used to simulate granular materials, and it can interact with Chrono (core) so that it becomes possible to bring a small number of more complex objects (such as your spoon) into the simulation as well. So if you would like to use Chrono::GPU, you have to start from its demos, to learn how to use its own methods to instantiate and manage granular particles. Chrono::GPU's main advantage is being fast. If your simulation has to involve millions of granular particles, then multicore will not do and GPU is the choice.

More specifically, CreateCylindricalContainerFromBoxes  is not a Chrono::GPU thing at all. cohesion_ratio is about the cohesion between Chrono::GPU particles, and it has nothing to do with gravity, which is set by SetGravitationalAcceleration in Chrono::GPU.

On a different note, Chrono's DEM/granular support on GPU is moving towards a new direction. The support for complex granular particle shapes will be added and it will become a duo-GPU solver. It will be based on SBEL's new DEM Engine. Apart from being more general and having higher efficiency, the usage of it is similar to Chrono::GPU, as a standalone helper to Chrono core which manages the granular part of the simulation, or work on its own as a dedicated DEM solver. If from the previous conversation you believe Chrono::GPU is for you, then likely this package will be of interest. More documentations and user guides are being added to it. But again, it does benefit from recent GPUs though. 

Thank you,

Ruochun

[yibing Yan]

Hi, thank you very much for your help!

After last mail, I choosed to use the multicore, the simulation took 2 hours every time now,  because I was constantly adding requests and features and the number of bodies comes to 10k. Meanwhile, I bought a 3080 and a new computer. I am considering using the reinforcement learning afterwards, so it is important to improve the simulation speed.

I have studied your response several times，I am wondering if I can only use Chrono::GPU for my particle-related content, and all other content remains the same, such as multi-core acceleration, loading my own obj. More specifically, I plan to use both ChSystemMulticoreSMC and ChSystemGpuMesh. When compile the project, there are errors "LNK2019：Unresolvable external symbols" in every functions defined in GPU and used in the Muticore and I feel this is a deeper issue involving linkers. So I would like to ask for guidance or is there another way to use the Chrono::GPU as a DEMsolver only for the particles.

And I learned something about projectchrono/DEM-Engine, but I found  how to Install DEM-Engine and the DEM-Engine usage are still waiting to be added, I would love to try it if I could.

Thank you again!

[Ruochun Zhang]

Hi,

I hope someone can provide better help on the linkage issue. What I can say is that you can try building it with cuda11.6 and the newest gcc. If you are using cuda11.8, or an ancient version of cuda or gcc, I cannot be sure. I've been building it with the said configuration with no problem, on Linux or Windows.

About Chrono::GPU's usage, yes it supports obj meshes. I am not sure about what you meant by multi-core acceleration. I might, if you elaborate a bit. And Chrono::GPU should interact with Chrono just fine, for that maybe you can have a look at the ballcosim demo.

If you care about polydisperse spherical particles or complex shaped particles, then DEM-Engine is the way to go. You can start using it now. Indeed, documentations are being added. I can drop you a message when it becomes more accessible. Right now, I attached a snippet from one of my previous emails, to help you understand how to build this tool on Linux. In terms of using it, I'd start with checking out and running its demos. And then, the methods in API.h are mostly commented, which for now, may serve as an ad-hoc documentation for you to understand what some of its basic usages are.

Thank you,

Ruochun

[yibing Yan]

Hi, thank you for your response!

First of all, I may have to apologise for my language skills and I really appreciate that you are willing to listen to my ideas. I'd like to describe my question again. I have finished a complete complex experiment, including around 10k granular objects, two objs of my own, one container by using utils::AddBoxGeometry and several links and motors, such as ChLinkMotorRotationSpeed、ChLinkMotorLinearSpeed、ChLinkMateFix. I achieved it by using the MCORE module, although it can speed up the program by using multiple threads, it still took 2 hours four one time simulation.

Now I am considering using the reinforcement learning afterwards, so it is important to improve the simulation speed. I am wondering if I can use Chrono::GPU only for my  granular objects, and all other content remains the same by using the MCORE module. More specifically, I plan to use both ChSystemMulticoreSMC and ChSystemGpuMesh in one cpp. The reason I want to do this is because Chrono::GPU is more like a separate module, some of the functions I need for simulation can't be found in Chrono::GPU, but can be found in the MCORE module and are already realized through my previous efforts.

I also note that Chrono::GPU quote ChronoEngine_GPU、ChronoEngine_irrlicht、ChronoEngine_multicore、ChronoEngine_opengl、ChronoEngine_postprocess、ChronoEngine_robot and ChronoEngine_multicore( the MCORE module ) is the one which I used now.  So I can use MCORE-functions in cpps in Chrono::GPU，by including the .h insteading of modify the CMakeLists.txt. 

I tried and felt if this idea was unattainable. Because I need to create two systems in one cpp. Meanwhile, for visualization, opengl::ChVisualSystemOpenGL is used in the MCORE module and ChGpuVisualization is used in the Chrono::GPU and I can't find an interface between the two which means they can't be showed in one window. I don't know how to solve this problem anymore and I wonder if you have any suggestions.

I really appreciate your help!

[Ruochun Zhang]

Hi,

What you wanted is possible. There is no problem creating two systems in one script, the only problem is their interaction. You can do that via co-simulation. Like a said, demo_GPU_ballcosim may give you an idea on how to do that. The general idea is that your complex mechanical system involving ChBodies and joints and such, will still be managed by a Chrono SMC system. Those ChBodies can be instructed to receive external forces and torques via accumulators; those external forces and torques in this case should be queried from Chrono::GPU simulations. That is, you load obj meshes into a Chrono::GPU system, and in each time step, you let it compute the contact forces between meshes and particles, then feed that information to ChBodies to update the locations of those bodies, then feed the new locations of these obj meshes back to Chrono::GPU to complete one time step, and then repeat.

If your particle system is large I wouldn't recommend doing runtime visualization anyway, that'd be totally prohibiting in terms of computational cost. Chrono::GPU can write particles and meshes to files, and maybe you should generate movies based on those as a post-processing step.

Thank you,

Ruochun

[yibing Yan]

Hi,

Thank you for your advice, after trying for several days, I succeed in using co-simulation, and it took only 10 minutes every one simulation. I have another question now, as I said before, I am going to use reinforcement learning with chrono. I think of using openAI and I also found projectchrono/gym-chrono. However, I don't know if I can realize what I have done with PyChrono, because the Chrono::Engine Python module does not cover all the features of the C++ API.

Meanwhile, in Project Chrono: Install the PYTHON module,  I found maybe I can't use Chrono::GPU system and Chrono SMC system in PyChrono. Can you give me any advice?

Thank you very much again sincerely!

[Radu Serban]

You are correct: Chrono::GPU is currently not wrapped in PyChrono.

But you can certainly use smooth contact (that is construct a ChSystemSMC) in PyChrono. Where/what did you see that made you think that’s not possible?

 

--Radu

--
You received this message because you are subscribed to the Google Groups "ProjectChrono" group.
To unsubscribe from this group and stop receiving emails from it, send an email to projectchron...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/projectchrono/8e6dcb70-2812-4b15-aa00-845f77b9c67dn%40googlegroups.com.

[Ruochun Zhang]

Hi,

In terms of involving simulation results of Chrono::GPU in your reinforcement learning project, I would suggest you generate the dataset using Chrono::GPU, and then use the dataset in the training. You probably have to do that anyway, even if Chrono's DEM support is wrapped in Python.

Ruochun

[yibing Yan]

hello, Ruochun. Thank you for your advice, now I am trying to prepare the dataset, and everything seems good now!

Then, I have a question about the unit in the demo_GPU_ballcosim.json. In this json, the unit of  "sphere_radius"、"box_X" seems to be mm, but the "grav_Z" equals -980, so I guess it's cm/s^2 ? 

The reason why I want to know is because the force I measured is over 1e8, so I guess its unit is not N? 

I noticed  that the chrono system should not have uniform unit, but all units need to correspond. I would appreciate it very much if you could tell me the units of the "normalStiffS2S"、normalDampS2S"  in this by the way.

demo_GPU_ballcosim.json
{
  "sphere_radius": 1,
  "sphere_density": 1,
  "box_X": 300,
  "box_Y": 300,
  "box_Z": 200,
  "step_size":  5e-5
  "time_end": 2,

  "grav_X": 0,
  "grav_Y": 0,
  "grav_Z": -980,

  "normalStiffS2S": 1e8,
  "normalStiffS2W": 1e8,
  "normalStiffS2M": 1e8,

  "normalDampS2S": 10000,
  "normalDampS2W": 10000,
  "normalDampS2M": 10000,

  "tangentStiffS2S": 1e8,
  "tangentStiffS2W": 1e8,
  "tangentStiffS2M": 1e8,

  "tangentDampS2S": 2000,
  "tangentDampS2W": 2000,
  "tangentDampS2M": 2000,

  "static_friction_coeffS2S": 0.5,
  "static_friction_coeffS2W": 0.5,
  "static_friction_coeffS2M": 0.5,

  "cohesion_ratio": 0,
  "adhesion_ratio_s2w": 0,
  "adhesion_ratio_s2m": 0,

  "verbose": 0,
  "run_mode": 1,

  "psi_T": 32,
  "psi_L": 16,

  "output_dir": "ballcosim",
  "write_mode": "csv"
}

[Ruochun Zhang]

Hi,

Chrono is dimensionless. So as you noted, there is an underlying consistent set of units. In Chrono GPU, the length is usually assumed to be in cm (no demo uses mm as its length unit), the mass is usually in g, the rest are in SI units. The force is therefore in g·cm/s². Those are just one possible interpretation, and any interpretation that has consistency would go.

From this paper, The unit of normal stiffness is g/s² (the same as k in Eq. 3), and the unit of normal damping is 1/s (similar to /gamma in Eq. 3, but Chrono ::GPU's damping will be multiplied by particle mass to form /gamma).

Ruochun

[yibing Yan]

Hi, Ruochun. Happy new year!

Thank you for your help! Recently, I used other objs in the simulation. At first, it showed the error 'xxx triangles are found in one of the SDs. The max allowance is 512' at the beginning of the simulation. I guess that the reason is my objs is too complex because it contains curves surface. I used stls to get objs. So to solve the error, I reduce my stls and objs. 

After that, the simulation seems can be started. However, during the simulation, there are many problems, 'Error! sphere xxxx has negative local pos in SDxxx...' I found your reply in the previous forum, the "step_size" is 5e-5, when I change it to 1e-5,  the force and torque got by gpu_sys.CollectMeshContactForces are always 0. And during the simution, particles will become abnormal as the following picture, but when I used my previous objs, everything is correct.

As I said before, there are many problems,  sometimes the error is about slots, and sometimes error is still about too much triangles during the simution instaed of at the beginning.

I was really confused and spent several days, looking forward to your help!

[Ruochun Zhang]

Hi,

I think you did the right thing in terms of resolving the too-many-triangles problem. C::GPU assumes that the triangles in the mesh you use are about the same size or bigger than the particle size. It has difficulty processing triangles that are much smaller than particles. The idea is that the mesh features preserved only by triangles that small will not benefit the simulation accuracy, since at that point the bottleneck for geometry representation accuracy becomes the particles/spheres. 

But you have to make sure your resultant reduced mesh is valid. The problem of not seeing forces or too many triangles in an SD could be because of that. The mesh needs to have correct outward normals, and should not have things like duplicate points/facets and such. If it is a small mesh, you can send it here and I could quickly check if it is alright. Also, when you use CollectMeshContactForces you have to make sure you are querying the correct mesh, meaning the first argument, the integer, needs to match the returned numbering of the mesh when you load the mesh into the system.

The negative local pos or too-many-sphere-in-SD type of error is more common. Uninspiring as it sounds, it is most likely due to a diverged/destabilized simulation. What you should do is: Reduce the time step size further; add more damping; or reduce the stiffness. Just those things that make DEM easier to run. The unusual splash as shown in your picture is one common symptom of insufficient temporal resolution. But I cannot say for sure, since there could be other causes, such as bad meshes.

Thank you,

Ruochun

[yibing Yan]

Hi, Ruochun

Thank you for your help! The thing that I am sure is about the using of CollectMeshContactForces, including the first argument. Because when I use 5e-5 time step,  CollectMeshContactForces works correctly, but when I use 1e-5, force and torque are always 0.

So I sent you some meshes, expecting for check. Meanwhile, I'd like to share how I got those reduced objs and stls.  I used a 3D modelling software called 'Meshmixer', it can reduce stls in a certain percentage, I set 50%. Before that, I export stls from the software 'soildworks' with minimum precision. Finally, I use solidworks again to import reduced stls and save as objs. In previous attempts, I have used the same approach to get stls and objs for simulation without problems. This time, I did the extra step of reducing the stl.

Thank you a lot!

[Ruochun Zhang]

Hi,

OK this mesh has an extremely sharp tip. That is a demanding physics in terms of numerical simulations, you agree? DEM is based on geometry penetration/overlap. Capture that microscopic particle--mesh overlap at that mesh tip is not easy, considering the geometry's own thickness. But other than that, the mesh seems valid.

I don't know what exact simulation you are running but say if you are using particles of diameter 0.5cm or something and a Young's modulus 1e9, then I suppose the time step size has to be 1e-6s or something like that. It's likely that 1e-5 won't cut it. As for not getting any force readings, I suspects it's because the simulation crashes right after the mesh tip hits the particles and all the readings you got were before the particles and mesh made contact, so they're all 0.

To quickly do a proof of concept you can make a similar mesh that does not have the tip, and repeat the simulation to see if it is easier. I even attached one, but it's just your mesh with the tip and most of the top structures removed. I imagine however, that tip is the key of the physics you are trying to simulate. If that is the case, eventually you have to add that part back, and go with small time step sizes since you have to.

Thank you,

Ruochun

[yibing Yan]

Thank you for your help! I will study it and make experiments for a few more days.

[yibing Yan]

Hi, Ruochun
The last issue about failure in simulation is almost solved, I think the model is still too complex for the simulation. Finally, I remake the 3d model, for example by removing the sharp tips and I reduced 80 percentage triangles of the curved surface in the stl. Also, I find there is a probability that the simulation will fail because I sometimes retest and it gets better.
At the same time, I have some other questions and I really appreciate your help .

1.In your previous answer, you told me that Chrono is dimensionless and in Chrono GPU, the length is usually assumed to be in cm (no demo uses mm as its length unit).However, I load this blue mesh in the simulation, whose height is 60mm, and I don't transform：

 float trans = 1.f; 

 spoon_mixer_mesh->Transform(ChVector<>(0), ChMatrix33<>( trans )); 

But I set "sphere_radius" 1 which I did't make change in  demo_GPU_ballcosim.json,  and the simulation as the picture make me a little confused.

2.Can chrono's simulation obtain the force at each different contact point between the mesh and the particle? CollectMeshContactForces should be a measurement of the combined force.
3.If I want to simulate a specific particle material, such as moon soil or cement, can you give me an idea on how to modify the parameters of the particle, because I see a lot of parameters such as normalStiffS2S static_friction_coeffS2S..... and I feel a bit confused. I feel like I should read some papers describing these material, but how should I relate them to the parameters in the simulation?

Thank you very much again!

在2023年1月2日星期一 UTC+8 13:35:08<Ruochun Zhang> 写道：

[Ruochun Zhang]

Hi,

Simulations failing randomly is not a good sign... Perhaps the simulation parameters are just on the verge of being valid. Or, it's also possible that Chrono::GPU has some suspicious memory operations that cause troubles in some scenarios such as yours. But I cannot be sure. To answer your questions...

1. Yes, this package is dimensionless. That means when it reads a file, it reads numerics only, not unit systems. Honestly, I don't think your mesh file has a unit system baked into it either. Once it is exported from your CAD system, there is no way to know the unit system you used, nor does Chrono care about it. So if you created mesh in your CAD using an mm-based metric system and then in the simulation set the sphere radius to be 1, thinking it means 1cm, then this is the inconsistency I talked about earlier. The way you are doing it implicitly makes this "1" in sphere radius mean 1mm. There is no such thing as a switch in Chrono::GPU that changes the way it interprets unit systems, the only thing that can be relied on is that you do the scaling and unification of unit systems properly under the hood.
2. Chrono::GPU cannot do that. But the new DEM-Engine can do that.
3. In this case, you should use the material-based force model (by the way, the default force model in DEM-Engine is also material-based). It's best if you check out the demo_GPU_ballDrop example. There you can see that you need to UseMaterialBasedModel(true) and then set the material properties, such as Young's modulus, etc.

Thank you,

Ruochun

[yibing Yan]

Hi, Ruochun

Thank you for your help sincerely!

Now, I am trying material-based force model in my simulation which is similar to the demo_GPU_ballcosim.cpp. There are two simulations. When run_mode == 0, this run is particle settling phase. After it is done, I will have a settled bed of granular material and a checkpoint file to store this state through gpu_sys.WriteCheckpointFile(checkpoint_file). Then, we change run_mode from 0 to 1, load the checkpoint file and start the second simulation.

Now, I am trying to use material-based force model instead of using SetKn_SPH2SPH、SetGn_SPH2SPH、SetGt_SPH2SPH...

I use the setMatreialProperty from demo_GPU_ballDrop. In the setting phase, I still use gpu_sys.WriteCheckpointFile(checkpoint_file) to get the cheeckpoint file. I notice that in the checkpoint file, the parameter such as K_n_s2s、G_t_s2w、G_t_s2m..are 0. So, in the second simulation, the measured force is always 0. It looks as if there is no collision and the simulation goes very fast. To solve the problem, I use setMatreialProperty again in the second simulation, after load the checkpoint file. However, it didn't work. But the simulation runs at normal speed. I am confused about this and could you help me? Than you very much!

void setMatreialProperty(ChSystemGpuMesh& gran_sys) {
    double cor_p = 0.5;  // use cor_p = 0.9 for sand or glass beads
    double cor_w = 0.5;
    double youngs_modulus = 1e8;
    double mu_s2s = 0.16;
    double mu_s2w = 0.45;
    double mu_roll = 0.09;
    double poisson_ratio = 0.24;

    gran_sys.UseMaterialBasedModel(true);
    gran_sys.SetYoungModulus_SPH(youngs_modulus);
    gran_sys.SetYoungModulus_WALL(youngs_modulus);
    gran_sys.SetRestitution_SPH(cor_p);
    gran_sys.SetRestitution_WALL(cor_w);
    gran_sys.SetPoissonRatio_SPH(poisson_ratio);
    gran_sys.SetPoissonRatio_WALL(poisson_ratio);
    //gran_sys.SetRollingMode(CHGPU_ROLLING_MODE::SCHWARTZ);
    gran_sys.SetRollingMode(CHGPU_ROLLING_MODE::NO_RESISTANCE);
    gran_sys.SetRollingCoeff_SPH2SPH(mu_roll);
    gran_sys.SetRollingCoeff_SPH2WALL(mu_roll);
    gran_sys.SetFrictionMode(CHGPU_FRICTION_MODE::MULTI_STEP);
    gran_sys.SetStaticFrictionCoeff_SPH2SPH(mu_s2s);
    gran_sys.SetStaticFrictionCoeff_SPH2WALL(mu_s2w);
}

[Ruochun Zhang]

Hi,

You are right about re-setting the material properties after loading a checkpoint. In fact, I suggest you just pretend that the checkpoint file stores particle size and location information only, and set everything one more time should you need to restart a simulation. When you say there is no force, do you mean CollectMeshContactForces returns 0 force always? If that is the case then you probably should ensure that you re-set the SPH2MESH material properties as well, since I didn't see related lines in your snippet. And then ensure that the mesh indeed touches the granular material when you measure. If you mean you try to output a contact pair info file and it's empty then you probably need to manually call SetRecordingContactInfo(true).

As you noted before, DEME is currently the DEM package being developed and maintained. Just letting you know that it now has some proper introduction added to the readme document that you may want to check out.

Thank you,

Ruochun

[yibing Yan]

 Hi, ruochun

Thank you for your help sincerely!

I still have some problems in the material, regarding the simulation parameters. Based on your last suggestion, I tried to use the material-based force model but still failed for some reasons. So I continued to set the parameters from .json like the demos in the Chrono::GPU. I also read some papers about Chrono, including the one you mentioned before: Chrono::GPU: An Open-Source Simulation Package for Ganular Dynamics Using the Discrete Element Method.

1. I notice that the parameter of S2S、S2W、S2M are same, such as normalStiffS2S、normalStiffS2W、normalStiffS2M. I am confused because I think the granular material should be different to the mesh material, so why S2S and S2M are same?
2. I don't know what the material of the mesh model in the demos are, such as the mixer in the demo_GPU_mixer.cpp and the ball in the demo_GPU_ballCosim.cpp 
3. I want to modify the parameters to simulate the simulation between different metals and particles, such as aluminum and titanium. Do you know how I should modify these parameters including normalStiff、normalDamp、tangentStiff、tangentDamp and static_friction_coeff?
4. When reading the paper, I have some questions about this paper Chrono::GPU: An Open-Source Simulation Package for Ganular Dynamics Using the Discrete Element Method. You taught me once before that the unit of normal stiffness is g/s² (the same as k in Eq. 3), and the unit of normal damping is 1/s (similar to /gamma in Eq. 3, but Chrono ::GPU's damping will be multiplied by particle mass to form /gamma). I feel difficult to understand Eq.18 and Eq.19 and the text described it above and below. δn means small penetration which I understand it as a variable that tends to 0. I'm wondering how it convert to the parameter we need, namely the stiffness and damping coefficients kn, kt, γn, and γt.

Sorry to bother you, but my core question is the third one. The other questions came up when I was exploring its solutions. I'd appreciate very much it if you knew it. And thank you so much for all the help you've been giving me!

part of .json:

    "sphere_radius": 1,
    "sphere_density": 1,

    "normalStiffS2S": 1e8,
    "normalStiffS2W": 1e8,
    "normalStiffS2M": 1e8,

    "normalDampS2S": 10000,
    "normalDampS2W": 10000,
    "normalDampS2M": 10000,

    "tangentStiffS2S": 1e8,
    "tangentStiffS2W": 1e8,
    "tangentStiffS2M": 1e8,

    "tangentDampS2S": 2000,
    "tangentDampS2W": 2000,
    "tangentDampS2M": 2000,

    "static_friction_coeffS2S": 0.5,
    "static_friction_coeffS2W": 0.5,
    "static_friction_coeffS2M": 0.5,

[Ruochun Zhang]

Hi,

To answer the questions:

1. They can be different. In that test, I didn't choose to set them differently though. Is there anything that makes you concerned about this choice?

2. Mesh material properties are specified by those S2M parameters. Compared to real-world materials, the properties we use tend to be much less stiff. This is to make the simulation easier to run, and it is a common practice.

3. and 4. are very related, I'd like to talk about them together. The short answer is that in your case you should use material-based properties, instead of specifying stiffness and damping numbers. An example of using material-based properties is demo_GPU_ballDrop. There, you specify Young's modulus and Poisson's ratio and friction coefficient and such, and the solver calculates the rest without you worrying about it. For aluminum or titanium, you should know those material properties. But I should notify you that using true Young's modulus could necessitate an extremely small time step size for your simulation to run, and it is questionable whether using true properties means much for increasing the fidelity of your simulations.

I admit that Eq.18 and Eq.19 make the text a bit less intuitive to understand. Eq.18 and Eq.19 basically say that when you set normalStiffS2S, normalDampS2S and such in the code, you are setting \hat{k} and \hat{\gamma}, rather than k and \gamma. We need to convert \hat{k} and \hat{\gamma} to k and \gamma to understand the physics, because Eq.3 and 4 use k and \gamma. But Chrono::GPU uses a nonlinear force model where the force is proportional to \delta^{1.5}, rather than \delta. That is to say the k and \gamma in Eq.3 and 4 are not independent of \delta. And indeed, k and \gamma contain a \delta^{0.5} in them, as indicated in Eq.18 and Eq.19. Also, k and \gamma are dependent on R and m, meaning that smaller particles are effectively stiffer given the same material, and this is a part of the force model. As for how to convert Young's modulus and such to k and \gamma, as indicated in the paper you are referred to Fleischmann, J.; Serban, R.; Negrut, D.; Jayakumar, P. On the importance of displacement history in soft-body contact models. J. Comput. Nonlinear Dyn. 2016, 11, 044502. Using this paper you can probably figure out a stiffness param k' which is in front of \delta^{1.5}, then you know k' is independent of \delta (since we use a force model proportional to \delta^{1.5}), and then based on the particle size and mass, you can figure out \hat{k} which is completely independent, and the solver asks for \hat{k}.

After reading all these, you probably already decided to use the material-based model. I would like to comment that the way \hat{k} and \hat{\gamma} were implemented is more force model-oriented, without considering much about the implications on materials (mindset: as long as we can explain how they make into the force model, it is fine). This is related to the fact that the stiffness and damping choices in many situations are numerical viability-driven, rather than trying to capture a specific material. You probably don't believe this now, but faithfully setting the true stiffness and damping, in some DEM simulations, makes them much more difficult to run while offering little accuracy boost for the application you try to simulate.

One last thing: If you use DEM-Engine, the only default model is material-based, so know that if you switch to that tool you don't have to worry about all these. Also note that the friction coefficient between two materials, if you use the material-based model in Chrono::GPU, will always be the larger one between the two. Whereas in DEM-Engine, you can specify explicitly the friction coefficient between any pair of two materials involved in a contact.

Ruochun

[yibing Yan]

Hi, ruochun, thank you for your help sincerely! After some attempts, I succeeded in using  material-based properties. I realized that I should use functions in ChSystemGpuMesh:: instead of ChSystemGpu::. I will continue to learn it for a few days, and I will try to use DEM-Engine if I get the chance later. Thank you very much for your help!