ScalFMM issueshttps://gitlab.inria.fr/solverstack/ScalFMM/-/issues2023-04-25T15:44:46+02:00https://gitlab.inria.fr/solverstack/ScalFMM/-/issues/42Change leaf in leaf_view in l2p unit test2023-04-25T15:44:46+02:00Olivier COULAUDolivier.coulaud@inria.frChange leaf in leaf_view in l2p unit testESTERIE PierreESTERIE Pierrehttps://gitlab.inria.fr/solverstack/ScalFMM/-/issues/40warning on ubuntu gcc-12.2.0 from xtensor, wrong call to builtin memcmp.2023-04-07T14:42:39+02:00ESTERIE Pierrewarning on ubuntu gcc-12.2.0 from xtensor, wrong call to builtin memcmp.https://gitlab.inria.fr/solverstack/ScalFMM/-/issues/39FFTW with MKL still produce uncoherent include path (libmkl-dev)2023-04-07T14:16:11+02:00ESTERIE PierreFFTW with MKL still produce uncoherent include path (libmkl-dev)https://gitlab.inria.fr/solverstack/ScalFMM/-/issues/38Unit container/variadic_containers.cpp does not compile2023-03-06T09:26:34+01:00Olivier COULAUDolivier.coulaud@inria.frUnit container/variadic_containers.cpp does not compileThe test does not compile (old format catch -> catch2), ....The test does not compile (old format catch -> catch2), ....ESTERIE PierreESTERIE Pierrehttps://gitlab.inria.fr/solverstack/ScalFMM/-/issues/37Constness problem with particle interface2023-03-01T11:52:54+01:00Olivier COULAUDolivier.coulaud@inria.frConstness problem with particle interfaceCheck Constness for particle interface (iterator and proxy) and and write a unit test.
The following code does not compile (leaf is a leaf_view (see check_l2p.cpp))
for(auto p_tuple_ref: leaf)
{
auto proxy = typename group_tree_type:...Check Constness for particle interface (iterator and proxy) and and write a unit test.
The following code does not compile (leaf is a leaf_view (see check_l2p.cpp))
for(auto p_tuple_ref: leaf)
{
auto proxy = typename group_tree_type::leaf_type::proxy_type(p_tuple_ref);
std::cout << idx << " p " << proxy << std::endl;
}ESTERIE PierreESTERIE Pierrehttps://gitlab.inria.fr/solverstack/ScalFMM/-/issues/35unit.homogenous_omp fails with LLVM2023-04-13T18:05:08+02:00Olivier COULAUDolivier.coulaud@inria.frunit.homogenous_omp fails with LLVMThe test unit.homogenous_omp fails with LLVM 13 and OneAPI.The test unit.homogenous_omp fails with LLVM 13 and OneAPI.ESTERIE PierreESTERIE Pierrehttps://gitlab.inria.fr/solverstack/ScalFMM/-/issues/34Periodic algorithm for 1/r2022-05-19T09:11:03+02:00Olivier COULAUDolivier.coulaud@inria.frPeriodic algorithm for 1/rThe periodic algorithm is correct only for fast decaying kernels i.e., r^{-s} with s > 3.
It is therefore necessary to introduce an Ewald-like approach to solve the cases s=1 or s=2.The periodic algorithm is correct only for fast decaying kernels i.e., r^{-s} with s > 3.
It is therefore necessary to introduce an Ewald-like approach to solve the cases s=1 or s=2.https://gitlab.inria.fr/solverstack/ScalFMM/-/issues/25Please provide guidance on which version to use2021-09-17T14:54:00+02:00Edgar BonetPlease provide guidance on which version to useFrom the README, it is very hard to tell which versions of ScalFMM
(tags, branches or commits) are meant to be used in production by
end-users.
The obvious choice, for most software projects, is to use the latest
stable release. In the ...From the README, it is very hard to tell which versions of ScalFMM
(tags, branches or commits) are meant to be used in production by
end-users.
The obvious choice, for most software projects, is to use the latest
stable release. In the case of ScalFMM, the closest thing we have to a
“stable release” would be a tag. The latest tag (V1.5.1), however, is
already quite old (2018-04-11). More annoyingly, it suffers from several
issues (e.g. #21 and #22) which have long ago been fixed in the git
repo.
For lack of a suitable tagged version, one may be tempted to use the tip
of a branch. This comes with its own problems:
* Unlike tags, branches are expected to evolve. For a software project
relying on ScalFMM, selecting a ScalFMM branch would make the build
irreproducible. This can be annoying, and is unacceptable in the
context of CI testing.
* There are 13 branches to choose from, and no documentation on the
purpose of each of them. The README simply suggests to check out
“requested\_branch” (sic), which is unhelpful. It also links to a
description of the [GitLab Flow][], which fails to shed much light:
It describes concepts such as “environment branches” and “release
branches” which do not map to ScalFMM branches in an obvious way.
* One may try to guess the purpose of each branch by looking at its
name, however,
* release\_1.5 seems the most promising: the closest to a “release
branch” in the sense of the GitLab flow, yet it is one year older
than the tag V1.5.1.
* maintenance/scalfmm-1.5 and maintenance/scalfmm-2.0 are fresher, yet
they do not get all the fixes relevant to them (e.g.
49a2145a117390fd04f8c01978c4a7a172f551c6), as would be expected for
release branches.
* even master does not get all the relevant fixes (again,
49a2145a117390fd04f8c01978c4a7a172f551c6).
The last option would be to select a specific commit, identified by its
SHA1. This is not ideal, and the choice of what commit to use is not
obvious.
## Suggested solutions
The optimal solution would be to have releases tagged on a regular basis
(v1.5.2, v1.5.3... v2.0.0...). Failing that, some guidance in the README
about what branches are meant for which users would be very welcome.
[GitLab Flow]: https://docs.gitlab.com/ee/topics/gitlab_flow.htmlhttps://gitlab.inria.fr/solverstack/ScalFMM/-/issues/24Please make it easier to submit issues2021-09-17T14:52:37+02:00Edgar BonetPlease make it easier to submit issuesFiling an issue on ScalFMM is unreasonably difficult for an outsider:
1. The obvious approach is to go to the [issues tab][] and click on the
“New issue” button, but this fails with the message “You need to sign
in **or sign up** ...Filing an issue on ScalFMM is unreasonably difficult for an outsider:
1. The obvious approach is to go to the [issues tab][] and click on the
“New issue” button, but this fails with the message “You need to sign
in **or sign up** before continuing.” (emphasis mine).
2. For an unregistered user, there is no simple way to sign up. The
sign-in page says “External users need to request an external account
from an Inria member.” This is impractical. Which Inria member are we
supposed to request the account from?
3. The README [suggests to Contact the developers][help] at
scalfmm-public-support@lists.gforge.inria.fr, but this address
bounces messages coming from unregistered users with “Vous n'êtes pas
autorisé à envoyer des messages sur cette liste” (French for “You are
not allowed to send messages on this list”).
4. The README does not mention that one has to subscribe to the
public-support list before posting, nor does it provide instructions
on how to do so.
Note that GitHub has created a precedent: nowadays it is very strongly
_expected_ that, for any non-dead project, filing an issue should be
_easy_.
## Suggested solutions
* Migrate to GitHub ;-) or maybe gitlab.com
* allow issues to be filed by unregistered users
* allow users to sign up, as it [used to be allowed in the
past][sign-up]
* allow users to reach the developers via an e-mail address that does
not bounce
[issues tab]: https://gitlab.inria.fr/solverstack/ScalFMM/-/issues
[help]: https://gitlab.inria.fr/solverstack/ScalFMM#help-and-news
[sign-up]: https://gitlab-account.inria.fr/https://gitlab.inria.fr/solverstack/ScalFMM/-/issues/23Undefined behavior in call to memcpy2019-11-26T17:16:14+01:00Ghost UserUndefined behavior in call to memcpyThe file Src/Components/FBasicParticleContainer.hpp contains two calls
to `memcpy()`, where the second parameter (the source pointer) can be
null. This only happens when the third parameter (the byte count) is
zero. This is, however, und...The file Src/Components/FBasicParticleContainer.hpp contains two calls
to `memcpy()`, where the second parameter (the source pointer) can be
null. This only happens when the third parameter (the byte count) is
zero. This is, however, undefined behavior.
[According to cppreference.com][cppref]:
> If either `dest` or `src` is a null pointer, the behavior is undefined,
> **even if count is zero**.
(emphasis mine).
**Affected versions**: I only tested the version tagged "V1.5.1".
**Test**: The script
```shell
CXX_FLAGS="-std=c++14 -fsanitize=undefined"
cd Tests/Utils/
rm -f testOctreeRearrange
g++ $CXX_FLAGS testOctreeRearrange.cpp -o testOctreeRearrange
./testOctreeRearrange
```
displays these error messages:
> ../../Src/Components/FBasicParticleContainer.hpp:117:23: **runtime error**: null pointer passed as argument 2, which is declared to never be null
> ../../Src/Components/FBasicParticleContainer.hpp:126:23: **runtime error**: null pointer passed as argument 2, which is declared to never be null
**Solution**: Only `memcpy` if `nbParticles` is non zero:
```shell
sed -i 's/memcpy/if (nbParticles != 0) memcpy/' Src/Components/FBasicParticleContainer.hpp
```
[cppref]: https://en.cppreference.com/w/cpp/string/byte/memcpyESTERIE PierreESTERIE Pierrehttps://gitlab.inria.fr/solverstack/ScalFMM/-/issues/17Intel Compiler --and PerfTest.ccp internal error: ** The compiler has encou...2019-11-15T09:15:38+01:00Olivier COULAUDolivier.coulaud@inria.frIntel Compiler --and PerfTest.ccp internal error: ** The compiler has encountered an unexpected problem.Bug with Intel compiler. In PerfTest.cpp we use C++17 features, which may explain the internal compiler error.
[ 37%] Building CXX object Tests/CMakeFiles/PerfTest.dir/noDist/PerfTest.cpp.o
cd /home/coulaud/Dev/src/ScalFMM/gitlab-deve...Bug with Intel compiler. In PerfTest.cpp we use C++17 features, which may explain the internal compiler error.
[ 37%] Building CXX object Tests/CMakeFiles/PerfTest.dir/noDist/PerfTest.cpp.o
cd /home/coulaud/Dev/src/ScalFMM/gitlab-devel/BuildIntel18/Tests && /cm/shared/apps/intel/composer_xe/2018.0.015/bin/icpc -DPerfTest_EXPORTS -I/home/coulaud/Dev/src/ScalFMM/gitlab-devel/BuildIntel18/Src -I/home/coulaud/Dev/src/ScalFMM/gitlab-devel/Src -I/home/coulaud/Dev/src/ScalFMM/gitlab-devel/Contribs -I/home/coulaud/Dev/src/ScalFMM/gitlab-devel -I/cm/shared/apps/intel/composer_xe/2018.0.015/mkl/include/fftw -fpic -Wall -m64 -fma -align -finline-functions -ipo -fstrict-aliasing -funroll-loops -ftree-vectorize -Wall -fp-model source -march=native -axCORE-AVX2,CORE-AVX-I,AVX -rdynamic -g -qopenmp -O3 -DNDEBUG -std=c++14 -o CMakeFiles/PerfTest.dir/noDist/PerfTest.cpp.o -c /home/coulaud/Dev/src/ScalFMM/gitlab-devel/Tests/noDist/PerfTest.cpp
icpc: warning #10193: -vec is default; use -x and -ax to configure vectorization
": internal error: ** The compiler has encountered an unexpected problem.
** Segmentation violation signal raised. **
Access violation or stack overflow. Please contact Intel Support for assistance.
compilation aborted for /home/coulaud/Dev/src/ScalFMM/gitlab-devel/Tests/noDist/PerfTest.cpp (code 4)
make[2]: *** [Tests/CMakeFiles/PerfTest.dir/noDist/PerfTest.cpp.o] Erreur 4
make[2] : on quitte le répertoire « /home/coulaud/Dev/src/ScalFMM/gitlab-devel/BuildIntel18 »
make[1]: *** [Tests/CMakeFiles/PerfTest.dir/all] Erreur 2
make[1] : on quitte le répertoire « /home/coulaud/Dev/src/ScalFMM/gitlab-devel/BuildIntel18 »
make: *** [all] Erreur 2ESTERIE PierreESTERIE Pierrehttps://gitlab.inria.fr/solverstack/ScalFMM/-/issues/16Intel Compiler and OpenMP dependencies2018-03-21T15:23:55+01:00Olivier COULAUDolivier.coulaud@inria.frIntel Compiler and OpenMP dependenciesSeveral errors with OpenMP4 dependencies with the intel2018 compiler. The files were automatically removed from the compilation by positioning the SCALFMM_USE_OMP4 variable OFF in the CMakeList.txt.Several errors with OpenMP4 dependencies with the intel2018 compiler. The files were automatically removed from the compilation by positioning the SCALFMM_USE_OMP4 variable OFF in the CMakeList.txt.https://gitlab.inria.fr/solverstack/ScalFMM/-/issues/10Move/copy previous Scalfmm documentation to gitlab wiki2017-12-17T14:38:03+01:00Berenger BramasMove/copy previous Scalfmm documentation to gitlab wikiThere might be some automatization of the conversion of the format to match the wiki syntax.There might be some automatization of the conversion of the format to match the wiki syntax.https://gitlab.inria.fr/solverstack/ScalFMM/-/issues/9Use HDF5 for binary input files2019-11-15T09:16:00+01:00Berenger BramasUse HDF5 for binary input filesRefactor input and use HDF5 (input/output).
Evaluate if current binary format will still be useful then.Refactor input and use HDF5 (input/output).
Evaluate if current binary format will still be useful then.Berenger BramasBerenger Bramas