The python preprocessing scripts use nodex, nodey, and nodez to define the number of elements and therefore the number of tracers. This is a legacy of the previous pyre version of CitcomS (no longer used). However, the C-code use different parameters to determine the nodes:
342 input_int("mgunitx",&(E->mesh.mgunitx),"1",m);
343 input_int("mgunitz",&(E->mesh.mgunitz),"1",m);
344 input_int("mgunity",&(E->mesh.mgunity),"1",m);
345
346 input_int("levels",&(E->mesh.levels),"1",m);
347
348 levmax = E->mesh.levels - 1;
349 E->mesh.nox = E->mesh.mgunitx * (int) pow(2.0,levmax) * E->parallel.nprocx + 1;
350 E->mesh.noy = E->mesh.mgunity * (int) pow(2.0,levmax) * E->parallel.nprocy + 1;
351 E->mesh.noz = E->mesh.mgunitz * (int) pow(2.0,levmax) * E->parallel.nprocz + 1;
This makes sense, since it forces the node counts to be compatible with the structure of a parallel multigrid solver. But it also means that the (potentially) user-specific nodes are not actually used! (which causes confusion).
It is not desirable to change the structure of the C-code since there are good reasons to do it this way. So we could either add a note in the assimilation documentation this is the case, or we could ask the preprocessing scripts to point this fact out.
The python preprocessing scripts use nodex, nodey, and nodez to define the number of elements and therefore the number of tracers. This is a legacy of the previous pyre version of CitcomS (no longer used). However, the C-code use different parameters to determine the nodes:
342 input_int("mgunitx",&(E->mesh.mgunitx),"1",m);
343 input_int("mgunitz",&(E->mesh.mgunitz),"1",m);
344 input_int("mgunity",&(E->mesh.mgunity),"1",m);
345
346 input_int("levels",&(E->mesh.levels),"1",m);
347
348 levmax = E->mesh.levels - 1;
349 E->mesh.nox = E->mesh.mgunitx * (int) pow(2.0,levmax) * E->parallel.nprocx + 1;
350 E->mesh.noy = E->mesh.mgunity * (int) pow(2.0,levmax) * E->parallel.nprocy + 1;
351 E->mesh.noz = E->mesh.mgunitz * (int) pow(2.0,levmax) * E->parallel.nprocz + 1;
This makes sense, since it forces the node counts to be compatible with the structure of a parallel multigrid solver. But it also means that the (potentially) user-specific nodes are not actually used! (which causes confusion).
It is not desirable to change the structure of the C-code since there are good reasons to do it this way. So we could either add a note in the assimilation documentation this is the case, or we could ask the preprocessing scripts to point this fact out.