CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Bugs

Zero size field

Register Blogs Members List Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Display Modes
Old   April 14, 2010, 04:06
Default Zero size field
  #1
New Member
 
Join Date: Jul 2009
Posts: 4
Rep Power: 8
taranov is on a distinguished road
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
taranov is offline   Reply With Quote

Old   April 15, 2010, 03:10
Default
  #2
Senior Member
 
Join Date: Mar 2009
Posts: 854
Rep Power: 13
henry is on a distinguished road
Could you provide a small case which reproduces the problem?

H
henry is offline   Reply With Quote

Old   April 20, 2010, 04:51
Default
  #3
New Member
 
Join Date: Jul 2009
Posts: 4
Rep Power: 8
taranov is on a distinguished road
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
taranov is offline   Reply With Quote

Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Superlinear speedup in OpenFOAM 13 msrinath80 OpenFOAM Running, Solving & CFD 18 March 3, 2015 06:36
Moving mesh Niklas Wikstrom (Wikstrom) OpenFOAM Running, Solving & CFD 122 June 15, 2014 06:20
OF 1.6 | Ubuntu 9.10 (64bit) | GLIBCXX_3.4.11 not found piprus OpenFOAM Installation 22 February 25, 2010 14:43
Phase locked average in run time panara OpenFOAM 2 February 20, 2008 15:37
fluent add additional zones for the mesh file SSL FLUENT 2 January 26, 2008 12:55


All times are GMT -4. The time now is 09:27.