View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002140 | OpenFOAM | Bug | public | 2016-07-07 05:42 | 2016-07-09 20:48 |
| Reporter | sariew | Assigned To | henry | ||
| Priority | normal | Severity | minor | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Platform | GNU/Linux | OS | Ubuntu | OS Version | 14.04 |
| Product Version | dev | ||||
| Fixed in Version | dev | ||||
| Summary | 0002140: OpenFOAM-dev (4.x) does not compile | ||||
| Description | The 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 Reproduce | cd $WM_PROJECT_DIR ./Allwmake > log.make 2>&1 | ||||
| Tags | No tags attached. | ||||
|
|
|
|
|
@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. |
|
|
I think 'int' would be best for processor IDs. |
|
|
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>'. |
|
|
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. |
|
|
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. |
|
|
Resolved by commit cd58a79a446de844380f3df414851e1db0cfc05b |
| 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 |
