I have put together a sort-of-working sintering pair interaction, and now I would like to make a wall/gran/sinter fix to contain and compact my sintering particles. My pair/gran/sinter pair style is based on pair/gran/hooke/history/stiffness and so I have tried to simply re-create/re-name the wall/gran/hooke/history/stiffness to be compatible with my particles (since wall and particle interaction must be the same).
This is not working so well for me. One of my problems is that LIGGGHTS can't find the particle material parameters associated with pair/gran/sinter, so it gives me an "address not mapped" segfault. In particular, I think this is where things are going wrong (or at least *starting* to go wrong):
fix_wall_gran_hooke_history_simple.cpp, line 70, has
k_n = ((PairGranHookeHistorySimple*)pairgran)->k_n;
//and several other parameters
so I have made fix_wall_gran_sinter.cpp to be
k_n = ((PairGranSinter*)pairgran)->k_n;
//and several other parameters
In my limited understanding of c++, these statements mean that k_n will be assigned a pointer to the k_n array of the PairGranSinter class. I know that this array exists, since the simulation runs fine until a particle contacts the wall. Is there some special place I need to register my PairGranSinter class so that LIGGGHTS can find it?
I am using LIGGGHTS 1.4.6. Relevant codes are attached, and I thank you in advance for any hints.
DAN
| Attachment | Size |
|---|---|
 fix_wall_gran_sinter_h.txt | 763 bytes |
| fix_wall_gran_sinter_cpp.txt | 3.37 KB |
ckloss | Thu, 12/22/2011 - 09:10
Hi Dan, at first glance, your
Hi Dan,
at first glance, your code looks ok.
>>In my limited understanding of c++, these statements mean that k_n will be assigned a
>>pointer to the k_n array of the PairGranSinter class
correct
if you get a segfault, you can use a memory debugger like valgrind. I put together some info here:
node/683
That should help
Cheers, Christoph
dbreton | Thu, 12/22/2011 - 19:59
valgrind results
Hi Chrisoph,
Thanks for the help. I installed valgrind and I get a lot of things, but this seems like the relevant bit:
==3778== Process terminating with default action of signal 11 (SIGSEGV)
==3778== Access not within mapped region at address 0x0
==3778== at 0x4FA46D: LAMMPS_NS::FixWallGranHookeHistory::compute_force(int, double, double, double, double, double, double, double*, double*, double) (fix_wall_gran_hooke_history.cpp:194)
==3778== by 0x6821B4: void LAMMPS_NS::FixWallGran::post_force_eval<3>(int) (fix_wall_gran.cpp:846)
==3778== by 0x67F656: LAMMPS_NS::FixWallGran::post_force(int) (fix_wall_gran.cpp:667)
==3778== by 0x6866A8: LAMMPS_NS::Modify::post_force(int) (modify.cpp:348)
==3778== by 0x6270C1: LAMMPS_NS::Verlet::run(int) (verlet.cpp:275)
==3778== by 0x55E19A: LAMMPS_NS::Run::command(int, char**) (run.cpp:160)
==3778== by 0x49E2A7: LAMMPS_NS::Input::execute_command() (run.h:16)
==3778== by 0x49EC0F: LAMMPS_NS::Input::file() (input.cpp:191)
==3778== by 0x5ABC91: main (main.cpp:29)
When I check the pointers stored in k_n in fix_wall_gran_sinter.cpp, they are pointing to things like 0x11d2870 0x11d2890 0x11d28b0 ... not 0x0.
It turned out that the missing pointer was the one for the *c_history argument to FixWallGranHookeHistory::compute_force -- I don't think my pair interaction creates anything like this, though PairGranHookeHistorySimple, on which it is based, does not either...?
At the moment, I am limping along by commenting out the shear history effects section of FixWallGranHookeHistory::compute_force, which seems to solve the memory problem.
Clearly in over my head,
DAN
ckloss | Mon, 01/02/2012 - 15:59
Hi Dan, could you resolve the
Hi Dan,
could you resolve the issues? Normally the # of contact history values should be extracted from the pair style. In other words: The # of contact history values available in the wall style equals the # in the equivalent pair style.
Let us know how you get on.
Cheers, Christoph