[taranov]

Hello, everybody!

We use OF 1.6.x from the git repository. And we found the following strange feature or even a bug:

A nonuniform field F of type T, for example of type T = vector, is represented
in a dictionary as

F nonuniform List<vector>
n
(
(fx1 fy1 fz1)
(fx2 fy2 fz2)
...
(fxn fyn fzn)
)
;

where n is the size of the field. But if the size is zero, n=0, then the field
F is written to the dictionary as

F nonuniform 0();

so the information about the type of the field is lost. If this field has been
decomposed and its size in the processor0 is zero
then this field is assumed to be the field of scalar during reconstruction,
which leads to problems if the actual type of the field is not scalar.

Please comment on this behavior.

Thanks in advance,
Andrey Taranov

[henry]

Could you provide a small case which reproduces the problem?

H

[taranov]

Dear Henry,
we have found that this problem is connected with the reconstructPar application. We have a shared library of our extensions to OpenFOAM. This library contains, among other things, a new type of boundary condition.
The new boundary condition class is derived from one of the standard OpenFOAM classes and has two members of types vectorField and tensorField.
We decomposed our case in such a way that the whole inlet went to
the last processor, so the sizes of the decomposed parts of these fields in
all other processors, including the master process, are zero. These fields in
all other processors were written to the dictionary file as
vField nonuniform 0();
tField nonuniform 0();
When we reconstructed our case, these fields were reconstructed incorrectly,
i.e. they were reconstructed as fields of scalar with very tiny (but nonzero)
values. When we decomposed our case in such a way that the whole inlet went to
the master process, reconstructPar worked correctly.

There are two solutions to this problem. The first one is to manually insert the definitions of the type into all other processors
vField nonuniform List<vector> 0();
tField nonuniform List<tensor> 0();
The other solution is to relink reconstructPar with our shared library. We
think that it would be much better to write the information about the type of
the field even when size of this field is zero.

Best regards,
Andrey Taranov