Hello Madam or Sir,
I am the user of OpenMesh, and I want ask some questions about the parallel code with OpenMesh, exactly, the parallel code is based on OpenMP on the VS2013.
The first question: When I use the OpenMP on the VS2013 to speed up the program which write with OpenMesh, for example, I add the code: #pragma omp parallel for num_threads(7) , just like the following:
and the errors follow, and I do not know why.
and the second question: Could the code with iterator of OpenMesh be paralleled by OpenMP just like " for (TriMesh::FaceIter f_it = mesh.faces_begin(); f_it != mesh.faces_end(); f_it++) " in the above picture? or How can I parallel the code with iterator of OpenMesh?
Thank you for your time! And I am looking forward to your reply.
Sincerely
LuWang
Hi All,
I have a code which uses OpenMP to run in parallel, using multiple mesh instances. From time to time, I'm dumping those instances into separate binary .om files, using separate ostream objects with the function
bool OpenMesh::IO::write_mesh ( const Mesh & _mesh,
std::ostream & _os,
const std::string & _ext,
Options _opt = Options::Default,
std::streamsize _precision = 6
)
Unfortunately, the execution seem to randomly fail with the error "double free or corruption (fasttop)". This is a backtrace:
======= Backtrace: =========
/lib64/libc.so.6(+0x81489)[0x2b63bd384489]
/home1/06589/tg858882/assembly_openmesh_KNL/OpenMesh-9.0/build/Build/bin/../lib/libOpenMeshCore.so.9.0(_Z5omlogv+0x558)[0x2b63bc128488]
/home1/06589/tg858882/assembly_openmesh_KNL/OpenMesh-9.0/build/Build/bin/../lib/libOpenMeshCore.so.9.0(_ZNK8OpenMesh2IO10_OMWriter_12write_binaryERSoRNS0_12BaseExporterENS0_7OptionsE+0x49)[0x2b63bc10aaf9]
/home1/06589/tg858882/assembly_openmesh_KNL/OpenMesh-9.0/build/Build/bin/../lib/libOpenMeshCore.so.9.0(_ZNK8OpenMesh2IO10_OMWriter_5writeERSoRNS0_12BaseExporterENS0_7OptionsEl+0xe7)[0x2b63bc10aa67]
/home1/06589/tg858882/assembly_openmesh_KNL/OpenMesh-9.0/build/Build/bin/../lib/libOpenMeshCore.so.9.0(_ZN8OpenMesh2IO11_IOManager_5writeERSoRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERNS0_12BaseExporterENS0_7OptionsEl+0xd9)[0x2b63bc0adea9]
./Assembly(_Z7dump_omN8OpenMesh20TriMesh_ArrayKernelTINS_13DefaultTraitsEEElRSo+0x11c)[0x44e33c]
./Assembly(_Z9propagateRN8OpenMesh20TriMesh_ArrayKernelTINS_13DefaultTraitsEEEll13RunParametersRSoS5_R14UmbrellaWindowRSt23mersenne_twister_engineImLm32ELm624ELm397ELm31ELm2567483615ELm11ELm4294967295ELm7ELm2636928640ELm15ELm4022730752ELm18ELm1812433253EE+0x36e)[0x4f89ee]
./Assembly(_Z31run_umbrella_parallel_temperingNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x7c4)[0x4f3b84]
/opt/intel/compilers_and_libraries_2018.2.199/linux/compiler/lib/intel64_lin/libiomp5.so(__kmp_invoke_microtask+0x93)[0x2b63bc556563]
/opt/intel/compilers_and_libraries_2018.2.199/linux/compiler/lib/intel64_lin/libiomp5.so(+0xa93ea)[0x2b63bc51e3ea]
/opt/intel/compilers_and_libraries_2018.2.199/linux/compiler/lib/intel64_lin/libiomp5.so(+0xa8aab)[0x2b63bc51daab]
/opt/intel/compilers_and_libraries_2018.2.199/linux/compiler/lib/intel64_lin/libiomp5.so(+0xe19c0)[0x2b63bc5569c0]
/lib64/libpthread.so.0(+0x7dd5)[0x2b63bc854dd5]
/lib64/libc.so.6(clone+0x6d)[0x2b63bd400ead]
As you can see, it traces back to OMWriter and indeed, the error seems to come up upon writing. I was therefore wondering if there is anything that prevents such parallel writing (to separate, binary files, via separate ostream objects) or this is expected to work properly?
Thanks a lot for your help,
Botond
Hi All,
I have a code which uses OpenMP to run in parallel, using multiple mesh instances. From time to time, I'm dumping those instances into separate binary .om files, using separate ostream objects with the function
bool OpenMesh::IO::write_mesh ( const Mesh & _mesh,
std::ostream & _os,
const std::string & _ext,
Options _opt = Options::Default,
std::streamsize _precision = 6
)
Unfortunately, the execution seem to randomly fail with the error "double free or corruption (fasttop)". This is a backtrace:
======= Backtrace: =========
/lib64/libc.so.6(+0x81489)[0x2b63bd384489]
/home1/06589/tg858882/assembly_openmesh_KNL/OpenMesh-9.0/build/Build/bin/../lib/libOpenMeshCore.so.9.0(_Z5omlogv+0x558)[0x2b63bc128488]
/home1/06589/tg858882/assembly_openmesh_KNL/OpenMesh-9.0/build/Build/bin/../lib/libOpenMeshCore.so.9.0(_ZNK8OpenMesh2IO10_OMWriter_12write_binaryERSoRNS0_12BaseExporterENS0_7OptionsE+0x49)[0x2b63bc10aaf9]
/home1/06589/tg858882/assembly_openmesh_KNL/OpenMesh-9.0/build/Build/bin/../lib/libOpenMeshCore.so.9.0(_ZNK8OpenMesh2IO10_OMWriter_5writeERSoRNS0_12BaseExporterENS0_7OptionsEl+0xe7)[0x2b63bc10aa67]
/home1/06589/tg858882/assembly_openmesh_KNL/OpenMesh-9.0/build/Build/bin/../lib/libOpenMeshCore.so.9.0(_ZN8OpenMesh2IO11_IOManager_5writeERSoRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERNS0_12BaseExporterENS0_7OptionsEl+0xd9)[0x2b63bc0adea9]
./Assembly(_Z7dump_omN8OpenMesh20TriMesh_ArrayKernelTINS_13DefaultTraitsEEElRSo+0x11c)[0x44e33c]
./Assembly(_Z9propagateRN8OpenMesh20TriMesh_ArrayKernelTINS_13DefaultTraitsEEEll13RunParametersRSoS5_R14UmbrellaWindowRSt23mersenne_twister_engineImLm32ELm624ELm397ELm31ELm2567483615ELm11ELm4294967295ELm7ELm2636928640ELm15ELm4022730752ELm18ELm1812433253EE+0x36e)[0x4f89ee]
./Assembly(_Z31run_umbrella_parallel_temperingNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x7c4)[0x4f3b84]
/opt/intel/compilers_and_libraries_2018.2.199/linux/compiler/lib/intel64_lin/libiomp5.so(__kmp_invoke_microtask+0x93)[0x2b63bc556563]
/opt/intel/compilers_and_libraries_2018.2.199/linux/compiler/lib/intel64_lin/libiomp5.so(+0xa93ea)[0x2b63bc51e3ea]
/opt/intel/compilers_and_libraries_2018.2.199/linux/compiler/lib/intel64_lin/libiomp5.so(+0xa8aab)[0x2b63bc51daab]
/opt/intel/compilers_and_libraries_2018.2.199/linux/compiler/lib/intel64_lin/libiomp5.so(+0xe19c0)[0x2b63bc5569c0]
/lib64/libpthread.so.0(+0x7dd5)[0x2b63bc854dd5]
/lib64/libc.so.6(clone+0x6d)[0x2b63bd400ead]
As you can see, it traces back to OMWriter and indeed, the error seems to come up upon writing. I was therefore wondering if there is anything that prevents such parallel writing (to separate, binary files, via separate ostream objects) or this is expected to work properly?
Thanks a lot for your help,
Botond
Dear OpenMesh Devs,
currently it is impossible to report bugs or feature requests, since this only works for registered users on your private gitlab server.
It would be nice, if you migrate to the global git-server of the RWTH (https://git.rwth-aachen.de). Then nearly every student and every GitHub user could participate.
For the latest release I have an issue, which is only partially fixed in the current master:
The hole cmake-project has some if-branches which are only triggered, when the project is build as external-project.
Those depend on a the same check:
```
# Disable package building when built as an external library
if(${CMAKE_PROJECT_NAME} MATCHES "OpenMesh")
```
This only worked, because you don't set the project when OpenMesh is build as subproject.
But this had the issue, that OpenMesh is not compileable when the parent project did not defined to use `C` as language.
In version 9.0.0~dev you decided to define the project every time which sticks to the conventions. Good so far!
But the LANGUAGE parameter is still not set there. And the project is not buildable anymore as subproject.
To solve this I propose to add `CXX C` to the LANGUAGE parameter of the project command.
Also all checks to the ` CMAKE_PROJECT_NAME ` variable should be replaced by a cache-variable `OPENMESH_BUILD_STANDALONE`, which is defined before the project command.
Generally all CMake files are outdated and should be overhauled to use newer conventions:
- [ ] use more CMake targets
- [ ] export targets correctly (should be exported to the same namespace as they are installed)
- [ ] update CMake version to e.g. 3.15
- [ ] ...
King regards,
Fabian Keßler
--
Fabian Keßler | Studentischer Beschäftigter
Optomet GmbH | Pfungstädter Straße 92 | 64297 Darmstadt | Deutschland
Fax: +49 6151 3688460 | https://www.optomet.com/de<https://www.optomet.com/de/>
