I am using Palbos1.0-v1.0r0, and trying with the code sparseDomainFromSTL.cpp. However, there are several errors (see blow) if I compile it. I have installed boost and cvmlcpp.
sparseDomainFromSTL.cpp: In function ‘int main(int, char**)’:
sparseDomainFromSTL.cpp:144: error: ‘TreeReader3D’ was not declared in this scope
sparseDomainFromSTL.cpp:144: error: expected primary-expression before ‘int’
sparseDomainFromSTL.cpp:144: error: expected ‘;’ before ‘int’
sparseDomainFromSTL.cpp:148: error: ‘treeReader’ was not declared in this scope
sparseDomainFromSTL.cpp:149: error: ‘generateSparseMultiBlock’ was not declared in this scope
sparseDomainFromSTL.cpp:153: error: ‘dynamicsFromOctree’ was not declared in this scope
sparseDomainFromSTL.cpp:161: error: type ‘’ argument given to ‘delete’, expected pointer
What’s wrong with it? Moreover, why didn’t you use octree mesh in the aneurysm case (examples/showCases/aneurysm)?
Any message from you are welcome.
In Palabos 1.0, domain voxelization is no longer done with the CVMLCPP, but with internal algorithms in Palabos. The reason we had to do this is because, as the CVMLCPP is not MPI-parallel, we ran into memory/performance issues for the pre-processing of large parallel problems. Voxelization and domain creation are now fully parallel and extremely fast. Btw, while in the aneurysm case we do not explicitly use an octree mesh as defined by the CVMLCPP, we do use a memory efficient sparse block structure which is essentially equivalent.
I am sorry that we broke backward compatibility by doing this; it should however not take too much effort to migrate your code to the new voxelizer, by taking example on the aneurysm application. Let us know if you run into any issues and need help with the migration.
Thanks very much for your reply. I do appreciate your kindly help.
As Palabos doesn’t use octree mesh now, more additional outside cells (for internal flow) should be considered. Will these outside cells be calculated during the loop? Moreover, if I use a complex geometry and thousands processors, there will be no fluid cells on some processors. Am I right?
Palabos uses a sparse mesh representation which is almost exactly equivalent to the octree representation. There is no wasted memory allocation, and there is no load balancing issue.
In the aneurysm case, one can output the surface with wirteSurfaceVTK and the full domain/box with wirtevtk(*lattice,).
Is there any convenient method to output (a) the flow fields in the real flow region or (b) the flow fields in the sparse boxes? I think the last one would be easier.
In the aneurysm case, one can output the surface
with wirteSurfaceVTK and the full domain/box with
wirtevtk(*lattice,).
Is there any convenient method to output (a) the
flow fields in the real flow region or (b) the
flow fields in the sparse boxes? I think the last
one would be easier.