View Issue Details

IDProjectCategoryView StatusLast Update
0002140OpenFOAM[All Projects] Bugpublic2016-07-09 20:48
ReportersariewAssigned Tohenry 
Status resolvedResolutionfixed 
PlatformGNU/LinuxOSUbuntuOS Version14.04
Product Versiondev 
Fixed in Versiondev 
Summary0002140: OpenFOAM-dev (4.x) does not compile
DescriptionThe compilation of OpenFOAM-dev (4.x) fails with the following error messages:
checkGeometry.C:992:25: error: no matching function for call to 'Foam::globalIndex::gather(Foam::label&, Foam::List<int>&, const scalarField&, Foam::scalarField&)'
moveDynamicMesh.C:87:5: error: no matching function for call to 'Foam::globalIndex::gather(Foam::label&, Foam::List<int>&, const scalarField&, Foam::scalarField&)'
make[3]: *** [/home/sariew5/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt64Opt/applications/utilities/mesh/manipulation/checkMesh/checkGeometry.o] Error 1
make[2]: *** [checkMesh] Error 2
make[2]: *** Waiting for unfinished jobs....
make[3]: *** [/home/sariew5/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt64Opt/applications/utilities/mesh/manipulation/moveDynamicMesh/moveDynamicMesh.o] Error 1
make[2]: *** [moveDynamicMesh] Error 2
CMake Warning at /home/sariew5/OpenFOAM/ThirdParty-dev/platforms/linux64Gcc/ParaView-5.0.1/lib/cmake/paraview-5.0/ParaViewPlugins.cmake:988 (message):
  GUI resource files in plugins are no longer supported. The same
  functionality can be obtained using Hints in the Server Manager xml files.
  See the Major API Changes document for details.
Call Stack (most recent call first):
  CMakeLists.txt:55 (ADD_PARAVIEW_PLUGIN)

What should I do next?
Steps To Reproducecd $WM_PROJECT_DIR
./Allwmake > log.make 2>&1
TagsNo tags attached.



2016-07-07 05:42


log.make.tar.gz (23,059 bytes)


2016-07-09 16:48

updater   ~0006509

@sariew: This issue was introduced recently in commit 05d89e486f87 in the dev repo and it seems to only affect the 64-bit integer builds. In addition, the changes made in that commit are not in the 4.x repository.

So the first question is: Do you really need 64-bit integer values? Are you dealing with meshes that have more than 2.147×10^9 cells, faces or points? If not, then you can build with the standard 32-bit integer support.

As for the issue with ParaView, it's just a warning and it should not affect the build.


@Henry and Mattijs: The compiler error with 64-bit labels in "checkGeometry.C" and "moveDynamicMesh.C" reveals that there is a consistency problem in the underlying processor management system.

There are a few places where the use of "int" is hard-coded, such as "Foam::UPstream::procIDs_" using "DynamicList<List<int>>"; in the same file "$FOAM_SRC/OpenFOAM/db/IOstreams/Pstreams/UPstream.H" where this is defined, there are several other processor ID references that use "label" and "labelList". And there is a lot of code that is relying on "label" and "labelList", instead of using "int", when dealing with processor IDs.

So my questions are: Should we switch all of the "int" entries to "label" to simplify maintenance?
If not, should we add a new type that allows a bit more finer control on this mechanism, at the very least to enforce consistency for processor IDs, instead of using the sporadic "int"/"label" definitions? Something like "procLabel" and "procLabelList"?

Because from a memory-economy perspective, most cases can do just fine with 16-bit integers for processor ID; 32-bit is more than enough... and 64-bit integers for processor count will require a future generation of hardware, 5-10 years from now.


2016-07-09 17:41

manager   ~0006510

I think 'int' would be best for processor IDs.


2016-07-09 18:11

manager   ~0006511

The issue with using 'label' for processor IDs is

MPI_Comm_rank(MPI_Comm, int*)

The problem with using 'int' is that the indexing of List is hard-coded to use 'label' so some of the List manipulation routines do not work if the list of indices provided is 'List<int>'.


2016-07-09 19:09

updater   ~0006512

Mmm... at least for the lists, we could have a "procLabelList" that is derived from "labelList", with a few additional methods for when a "List<int>" is strictly needed. This would allow for a fairly easy recasting at least at the core level of Pstream et al when dealing with the MPI layer, while maintaining the support for "labelList" everywhere else. The downside is memory and time needed for resampling "int" to "label" and vice-versa.

On the other hand, having a "procLabel" that is just a "typedef" for "int", would only be possible for internal use at the core level near Pstream... I still to take a better look into how "label" is implemented in OpenFOAM, to see an effective way of doing this.


2016-07-09 19:46

manager   ~0006513

I have added an explicit constructor for List from a List of another type which is the simplest way of avoiding the current problem. A more general solution will require List to be additionally templated on the index type.


2016-07-09 20:48

manager   ~0006514

Resolved by commit cd58a79a446de844380f3df414851e1db0cfc05b

Issue History

Date Modified Username Field Change
2016-07-07 05:42 sariew New Issue
2016-07-07 05:42 sariew File Added: log.make.tar.gz
2016-07-09 16:48 wyldckat Note Added: 0006509
2016-07-09 17:41 henry Note Added: 0006510
2016-07-09 18:11 henry Note Added: 0006511
2016-07-09 19:09 wyldckat Note Added: 0006512
2016-07-09 19:46 henry Note Added: 0006513
2016-07-09 20:48 henry Note Added: 0006514
2016-07-09 20:48 henry Status new => resolved
2016-07-09 20:48 henry Fixed in Version => dev
2016-07-09 20:48 henry Resolution open => fixed
2016-07-09 20:48 henry Assigned To => henry