nodes, nodey, and nodez

[djbower]

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.

[michaelchin]

Force the equation nodex = 1 + nprocx + mgunitx + 2**(levels-1) to be satisfied in preprocessing python script.

f602784