New AFQMC test failures #5235
Comments
|
The changes shouldn't have introduced any semantic change. (should compile to the same machine code). My changes in qmcpack, should also work with previous version of Multi, that is the first thing I would try, to revert back Multi. What is different in these tests with respect to the CI? |
The only differences are supposed to be compiler and library versions, since we do more combinations in the nightlies. However (can't look fully now) I couldn't quick spot an AFQMC enabled build in the current CI tests (!), implying we lost one important configuration in the last round of CI updates. Do you see one? |
|
I don't know, I edited .cpp files only. How is a configuration "lost"? (BTW, the changes I made should compile to the same code) |
|
Lost: probably missing for months, at least if I did not miss the AFQMC results. |
|
If these tests were lost for months, perhaps it was broken before #5228 . I am not sure what #5234 was about. (Multi had to reimplement tuples, and not simple use |
|
thank you for trying, can you try reverting the version of Multi by itself? |
Cannot compile the code by merely reverting boost_multi part. |
|
That is strange, a red flag too. Ok, feel free to revert the whole of #5228 (including reverting multi) or until it compiles. I can try again later with the necessary changes, the changes I have to make in qmcpack should be mechanical. |
|
change the code In the build directory The expected printout of |
|
shouldn't the loop go from |
|
Let me check. |
|
nkpts is also 8. makes no difference. |
|
great, thanks. Let me see what happens with |
|
yes. integers. I did additional check I got both Clearly wrong. |
|
mmm, this is very strange. The only thing I can imagine is that the internal pointer in I did a bunch of paranoid tests of iterator arithmetic and it seems to work. If you can catch the exact type of {
int const count = 8;
multi::array<int, 1> arr({24}, 1);
BOOST_TEST( arr.size() == 24 );
BOOST_TEST( arr.begin() == arr.begin() );
BOOST_TEST(!(arr.begin() != arr.begin()));
BOOST_TEST( arr.begin() != arr.end() );
BOOST_TEST(!(arr.begin() == arr.end()));
BOOST_TEST( arr.begin() != arr.begin() + count );
BOOST_TEST(!(arr.begin() == arr.begin() + count));
BOOST_TEST( std::accumulate(arr.begin(), arr.begin() + count, 0) == count );
auto const& arr_strided = arr.strided(3);
BOOST_TEST( arr_strided.begin() == arr_strided.begin() );
BOOST_TEST(!(arr_strided.begin() != arr_strided.begin()));
BOOST_TEST( arr_strided.begin() != arr_strided.end() );
BOOST_TEST(!(arr_strided.begin() == arr_strided.end()));
BOOST_TEST( arr_strided.begin() != arr_strided.begin() + count );
BOOST_TEST(!(arr_strided.begin() == arr_strided.begin() + count));
BOOST_TEST( std::accumulate(arr_strided.begin(), arr_strided.begin() + count, 0) == count );
} |
|
|
|
what is exactly missing in this configuration to reproduce the error? |
Need |
|
do you know why this was not catch |
|
We only have AFQMC in CI CUDA builds. Probably we should it on in a few CPU builds. |
|
I do a CI with CPU and GPU of qmcpack on my own, but unfortunately not with QMC_COMPLEX=1 |
|
Fails in Mac clang too: |
|
I did a bisection and the error was introduced in July. |
|
One of the error happens here: BufferAllocatorGenerator(MemoryResource const& a, long initial_size = 0, Constructor const& c = {})
: base_mr(a),
_size(initial_size),
_start(static_cast<pointer>(base_mr.allocate(_size, Align))), // <----- HERE
mr_({_start, _size}, std::addressof(base_mr)),
constr_(c)
{}This is getting complicated, it is going to take time. |
|
#5228 has been reverted and new CI coverage added. |
|
sorry for the confusion, is it possible to revert back the Multi update, but not the |
Didn't work. I tried #5235 (comment) Once you have a fix in the upstream multi, first revert my revert commit and then update multi in QMCPACK. |
|
can you put a branch in which the |
Describe the bug
A few new AFQMC test failures resulted in the nightlies after PRs from the last couple of days, presumably after #5234 or #5228. Configurations such as GCC14-Complex-Mixed-Release. Looks to be changes in error tolerance handling in some cases e.g. https://cdash.qmcpack.org/tests/8777436 but more serious in others https://cdash.qmcpack.org/tests/8777462
To Reproduce
Nightly complex builds, develop.
Expected behavior
Tests pass
System:
sulfur
The text was updated successfully, but these errors were encountered: