Some basic concepts in FrictPhys.cpp

Asked by gaoxuesong

Hi. Now i am studying the source code of FrictPhys.cpp. I am confused about some concepts even after i check the programmer manual. My questions are mainly about these codes,

1. const shared_ptr<FrictMat>& mat1 = YADE_PTR_CAST<FrictMat>(b1);

     1.1 Is the shared_ptr<FrictMat> a template class and will instantiate a pointer to FricMat? I have checked the definition of shared_ptr but it is too complicated for a c++ newer to understand.

     1.2 The YADE_PTR_CAST will do change the b1 type to FrictMat? But if b1 is not a pointer to FrictMat, like a CohFrictMat, will it cause a material type mismatch between the particle material and the IPhysFunctor?

2. Ra=sphCont->refR1>0?sphCont->refR1:sphCont->refR2; Rb=sphCont->refR2>0?sphCont->refR2:sphCont->refR1;

    2.1 The Ra, Rb here are the stiffness related particle size? Why these two values could be negative?

3. interaction->phys = shared_ptr<FrictPhys>(new FrictPhys());
    const shared_ptr<FrictPhys>& contactPhysics = YADE_PTR_CAST<FrictPhys>(interaction->phys);
    contactPhysics->kn = Kn; contactPhysics->ks = Ks;

    3.1 Also the conversion of interaction->phys to FrictPhy type. Another is that since the reference contactPhysics has decoration of const, why it is able to change the value of its pointing memory?

4. Real Kn = (!kn) ? 2*kna*knb/(kna+knb) : (*kn)(mat1->id,mat2->id,kna,knb);

    4.1 I understand the true part of this expression. What does the false part means? (*kn) is a function?

Thanks for your patience to look through all my questions.

Xuesong

Question information

Language:
English Edit question
Status:
Solved
For:
Yade Edit question
Assignee:
No assignee Edit question
Solved by:
gaoxuesong
Solved:
Last query:
Last reply:

This question was reopened

Revision history for this message
gaoxuesong (260582472-9) said :
#1
Revision history for this message
gaoxuesong (260582472-9) said :
#2

Can i change the status of this question? I make a mistake to set it as solved. :(

Revision history for this message
Jan Stránský (honzik) said :
#3

Hello,

1.1

> Is the shared_ptr<FrictMat> a template class

yes. But as C++ newcomer, you can consider shared_ptr<SomeClass> as normal pointer SomeClass* with "automatic destruction"

> will instantiate a pointer to FricMat?

no, the pointer already exists. It just change (cast) it for C++ from
const shared_ptr<Material>&
to
const shared_ptr<FrictMat>&

> I have checked the definition of shared_ptr but it is too complicated for a c++ newer to understand.

apart from definitions, try to google some simple examples.

1.2

> The YADE_PTR_CAST will do change the b1 type to FrictMat?

yes, see above

> But if b1 is not a pointer to FrictMat, like a CohFrictMat, will it cause a material type mismatch between the particle material and the IPhysFunctor?

if b1 is not FrictMat, than mat1 will be nullptr, causing segmentation fault. But this function is called from Yade internals, specifically IPhysDispatcher, who sends there only correct types.

CohFrictMat is not a good example, because CohFrictMat **IS** FrictMat (it is derived from it) and the code would work OK.

2
> Why these two values could be negative?

who not? :-)
This condition is there from (at least, was too lazy to search more) 2009, probably its meaning was Sphere-Facet interaction or something like that

3
const shared_ptr<FrictPhys>& contactPhysics
means that the pointer is constant (the FrictPhys instance), not its content. You can change its content, but you cannot change, where the pointer points.

4
kn is MatchMaker [1]

cheers
Jan

[1] https://gitlab.com/yade-dev/trunk/commit/56597aa634e5f5a7684210dd4c8a858be5116cae#b34548f45a5a6c26d6a5293e702d6ccb1cbd5bbf_44_50
[2] https://yade-dem.org/doc/yade.wrapper.html#yade.wrapper.MatchMaker

Revision history for this message
Robert Caulk (rcaulk) said :
#4

>const shared_ptr<FrictMat>& mat1 = YADE_PTR_CAST<FrictMat>(b1);

This is saying that no matter what material class b1 actually has, mat1 is going to treat it as if it is a FrictMat. This means that we can use mat1 later to access members that FrictMat would have (e.g. mat1->young)

>But if b1 is not a pointer to FrictMat, like a CohFrictMat, will it cause a material type mismatch between the particle material and the IPhysFunctor?

Nope.

>shared_ptr but it is too complicated for a c++
[1]

> The Ra, Rb here are the stiffness related particle size? Why these two values could be negative?

No. https://yade-dem.org/doc/yade.wrapper.html#yade.wrapper.GenericSpheresContact.refR1

> Also the conversion of interaction->phys to FrictPhy type. Another is that since the reference contactPhysics has decoration of const, why it is able to change the value of its pointing memory

I think ti is because we are referencing using &. A bit confusing, no doubt.

>4. Real Kn = (!kn) ? 2*kna*knb/(kna+knb) : (*kn)(mat1->id,mat2->id,kna,knb);

kn is a shared_ptr<Matchmaker> with a custom () operator [2].

[1]https://www.yade-dem.org/doc/prog.html#shared-pointers

[2https://gitlab.com/yade-dev/trunk/blob/master/pkg/common/MatchMaker.hpp#L38

Revision history for this message
Robert Caulk (rcaulk) said :
#5

Ah we worked on this at the same time, Jan ;-).

About this piece:

const shared_ptr<FrictPhys>& contactPhysics

According to stack overflow, a const shared_ptr<FrictPhys> contactPhys (sans &), would mean that contactPhysics is constant [1]. So I am guessing we can only modify it because we are taking it as a reference too. Maybe you can clarify this?

[1]https://stackoverflow.com/questions/17793333/difference-between-const-shared-ptrt-and-shared-ptrconst-t

Revision history for this message
Bruno Chareyre (bruno-chareyre) said :
#6

> According to stack overflow, a const shared_ptr<FrictPhys> contactPhys (sans &), would mean that contactPhysics is constant [1].

I don't think so. With 'const shared_ptr<FrictPhys> contactPhys ' the pointed data would not be constant, as opposed to 'shared_ptr<const FrictPhys> contactPhys '.

The role of '&' is only to avoid reference counting (it is the conventional method to pass shared_ptr).

Revision history for this message
Robert Caulk (rcaulk) said :
#7

Ah my mistake for p vs *p

Revision history for this message
gaoxuesong (260582472-9) said :
#8

Thanks very much for your answers. Helps me a lot.