API cannot work well in parallel calcultaion

Raheem Sterling_22160

Hi,

I have introduced a contact model, and it works well when number of core is 1, the results was in coincide with analytical solutions, but when the number of cores larger than 1, the simulation was not in my expect, like particles had large velocity and disappeared. What may cause the problem as I described?

 I am not sure if the initialization of values will lead this. In my code, I have defined some unassigned CSimplevectors in the cpp file and h file, just like:

CSimpervector n1, but not CSimpervector n1(0.0,0.0,0.0).

And I also introduced some new custom properties. Are there any experiences about this?

RWood

Hi,

The default constructor for CSimple3DVector initialises new instances to {0, 0, 0}, so that's not a big deal. That said, in general you should always initialise your variables, just to be sure that you know the starting value.

Custom properties are multi-threaded, so unlikely to be the cause, but the only way to be sure if to debug your code on multiple processors and walk through the values line by line, to see where the issue arises. 

The easiest way to introduce a variable that is not threadsafe (i.e. doesn't work in parallel) is if you are adding to a variable in your class, that you've initialised in the header. For example, if you initialise something to 0 in the header, say, and want to add 1 to it each time there is a contact, if two contacts happen on two threads simultaneously, they will both add 1 to the value 0, so each will see a value of 1 and not a value of 2 as you might expect. Have a look in your code for instances like this.

Cheers,

Richard

RWood

Hi,

The default constructor for CSimple3DVector initialises new instances to {0, 0, 0}, so that's not a big deal. That said, in general you should always initialise your variables, just to be sure that you know the starting value.

Custom properties are multi-threaded, so unlikely to be the cause, but the only way to be sure if to debug your code on multiple processors and walk through the values line by line, to see where the issue arises. 

The easiest way to introduce a variable that is not threadsafe (i.e. doesn't work in parallel) is if you are adding to a variable in your class, that you've initialised in the header. For example, if you initialise something to 0 in the header, say, and want to add 1 to it each time there is a contact, if two contacts happen on two threads simultaneously, they will both add 1 to the value 0, so each will see a value of 1 and not a value of 2 as you might expect. Have a look in your code for instances like this.

Cheers,

Richard

Raheem Sterling_22160

Richard Wood_20774 said:

Hi,

The default constructor for CSimple3DVector initialises new instances to {0, 0, 0}, so that's not a big deal. That said, in general you should always initialise your variables, just to be sure that you know the starting value.

Custom properties are multi-threaded, so unlikely to be the cause, but the only way to be sure if to debug your code on multiple processors and walk through the values line by line, to see where the issue arises. 

The easiest way to introduce a variable that is not threadsafe (i.e. doesn't work in parallel) is if you are adding to a variable in your class, that you've initialised in the header. For example, if you initialise something to 0 in the header, say, and want to add 1 to it each time there is a contact, if two contacts happen on two threads simultaneously, they will both add 1 to the value 0, so each will see a value of 1 and not a value of 2 as you might expect. Have a look in your code for instances like this.

Cheers,

Richard

Hi Richard,

Thank for your explanation, I have debugged the code, and the problem was as you said.

I need a vector named "ni" to store the initial contact vector of each contact, so I introduced a custom property to  store it, but I defined "ni" in the header file, so I found that sometime ni not equal to the value it should be. So I define it in the cpp file. It works well, thanks a lot.

Reagrds!

Raheem