[Getdp] 60000 Nodes == trouble?

[Kubicek Bernhard]

Hello once again,

Today, I did run into this problem: 
I have two formulations, one which contains a nodal temperature field.
The second, chained resolution, does something with the temperature
field. 
However, I don't solve the first resolution, but only the second. This
is still usefull, as I assign in the temperature field a constant value
of "12345678". I start with the preprocessing, than I patch the .pre
file by replacing all occurences of 12345678 by temperatures calculated
from somewhere differently. By that, I am (usually) able to import
forein fields into GetDP. This method oviously fails in all estetic
criterions, but it works (at least for all smaller meshes).

However, with my 60984 nodes mesh, there are some problems. Some patched
temperatures appear at false positions in the .pos files. After doing
all possible checks I could think of in my glue-code, I started browsing
GetDPs code,  and found the piece that reads in pre-processing files,
DofData.c ReadFilePRE() :
>fscanf(File_PRE, "%d %d %d %d",     &Dof.NumType, &Dof.Entity,
&Dof.Harmonic, &Dof.Type) ;
In Data_DofData.h, Dof.Entity is declared as "int".
I checked that on my compiler, INT_MAX is 2147483647, g++ 4.0.4 on 32
bit Linux, although INT_MAX in principle can be as low as ~32000.
I did not check, if this is also valid for spareskit and fortran..

So I think I should be on the save side...
And the calculation results, apart from this preprocessing problem, seem
to be ok.

Are there any other reasons that could cause positioning errors in the
preprocessing or postprocessing?
And are the entity numbers equal the node numbers of a nodal scalar
field?

Sorry for the possible incoherent language and typographic mistakes,
and thank you very much for your help,

Bernhard