Who translates the particle types?

OpenKIM
1

Hi,

Typically, both a test and a model specifies the supported atomic types per symbol in their .kim file, and specify an associated numerical value. Those values typically do not match. Who is responsible for doing the translation? The KIM API translates 0-based neighbor lists to 1-based or vice versa, but does not appear to translate the particle numbers. Am I correct in assuming that the Test and not the Model should do that?

Best regards

Jakob

2

Hi Jakob,

Right. The Test is responsible for using integer indices for particle species which the Model defines. The KIM_API_get_partcl_type_code() routine allows the Test to easily obtain this information. (The KIM_API_set_partcl_type_code() routine is only for use by Model Drivers; see the documentation for that routine and in standard.kim for more details.)

There are also the routines KIM_API_get_model_partcl_typs() and KIM_API_get_test_partcl_typs() that can be used if a need arises.

3

Dear Ryan,

Thank you very much for all your replies!

I am having another problem: My test is using the neighObject field in the KIM API to store a pointer to the C++ object that knows about the neighbor list. I store it like this:

  model->setm_data(&x, 2*4,
       "get_neigh", 1, &get_neigh_wrapper, 1,
       "neighObject", 1, this, 1);

and later in the get_neigh function I try to recover it like this:

extern "C" {
  static int get_neigh_wrapper(void **kimmdl, int *mode, int* request,
      int *particle, int *numnei, int **nei1particle,
      double **rij)
  {
    KIM_API_model *model = (KIM_API_model *) *kimmdl;
    int x;
    OpenKIMcalculator *calc = (OpenKIMcalculator *) model->get_data("NeighObject", &x);

I have inserted printing statements that show that “model” is the same pointer in the two cases. Nevertheless, when the get_data line is called it returns NULL and set an error in x.

Am I doing something wrong here? It seems that perhaps I should use get/set_test_buffer instead, but I am not sure what the purpose of neighObject is then?

My Model completely ignores the neighObject argument, it assumes that the Test is handling that part. Is that correct?

Best regards

Jakob

4

Dear Ryan,

Thank you very much for all your replies!

My pleasure!

I am having another problem: My test is using the neighObject field in the KIM API to store a pointer to the C++ object that knows about the neighbor list. I store it like this:

model->setm_data(&x, 2*4,
      "get_neigh", 1, &get_neigh_wrapper, 1,
      "neighObject", 1, this, 1);

and later in the get_neigh function I try to recover it like this:

extern "C" {
static int get_neigh_wrapper(void **kimmdl, int *mode, int* request,
     int *particle, int *numnei, int **nei1particle,
     double **rij)
{
   KIM_API_model *model = (KIM_API_model *) *kimmdl;
   int x;
   OpenKIMcalculator *calc = (OpenKIMcalculator *) model->get_data("NeighObject", &x);

I have inserted printing statements that show that "model" is the same pointer in the two cases. Nevertheless, when the get_data line is called it returns NULL and set an error in x.

Am I doing something wrong here?

The "argument" names are case sensitive. You are asking for "NeighObject" instead of "neighObject". :wink:

It seems that perhaps I should use get/set_test_buffer instead, but I am not sure what the purpose of neighObject is then?

You could use the test buffer for this, but technically that is "cheating". One reason you would need the neighOjbect argument is if your Test creates multiple particle configurations and multiple KIM_API_model objects. Then you will need multiple neighbor lists and your get_neigh() function needs to know which neighbor list data to use...

My Model completely ignores the neighObject argument, it assumes that the Test is handling that part. Is that correct?

Yep. That is correct. The Model should not do anything with the neighObject argument.

Cheers,

Ryan

5

Hi again,

This was pure stupidity on my part. I spelled neighObject wrong when retrieving the pointer (upper-case N), and I really don’t know why I did not see it myself.

I hope you have not wasted too much time on this.

Best regards

Jakob

6

No problem. I noticed it pretty quickly... :slight_smile:

Ryan