Constant size matrix errors for CSVMC

[jtkrogel]

The CSVMC tests are currently failing due to constant size matrix errors. A stopgap would be to recompile the code at all nightly test sites to use a large enough WALKER_MAX_PROPERTIES to clear these particular tests, but I think this issue should remain open (or at least another one created and remain open) until archaic compile time sizing is no longer required.

See: https://cdash.qmcpack.org/CDash/testDetails.php?test=8433143&build=120036 https://cdash.qmcpack.org/CDash/testDetails.php?test=8433144&build=120036 https://cdash.qmcpack.org/CDash/testDetails.php?test=8433142&build=120036

[prckent]

I would prefer not to fix the nightlies since it will hide the very clear user-facing problem

[ddinge]

I'm seeing this error on an ARM machine with gnu compiler and open mpi. I don't think increasing "WALKER_MAX_PROPERTIES" will fix it. I tried changing it from the previous 2048 to 4096 and it made no difference. Resizes where the first dimention goes from 1 to 2 in the message below seem to generate the error. Resizes with 1,x are fine.

Error message "You cannot resize a constant size matrix beyond its initial max dimensions ( 2,14 > 1,2048 )"

I'm a newby to the code so this is a phenomenological observation not based on a knowledge of the code logic. Perhaps someone can chime in on what the code is attempting to do here.

[prckent]

@ddinge There is nothing wrong with your compiler here. The code is unfortunately behaving as it is meant to, if not how we would like it to in future.

The code needs a redesign in this area to fix. There was a problem in the legacy dynamic sizing of properties that was temporarily patch/bypassed some months back by defining a maximum number of properties. This is problematic for some qmc methods (CSVMC) and for some observables as you have discovered but it OK for vanilla VMC and DMC runs. Basically the legacy code/design needs replacing to better to suit current needs.

[markdewing]

The issue is ConstantSizeMatrix can only be resized along dimensions independently. Even if there is enough underlying storage to accommodate the resized matrix, it still fails. One solution is to compare the total size when resizing:

--- a/src/Containers/MinimalContainers/ConstantSizeMatrix.hpp
+++ b/src/Containers/MinimalContainers/ConstantSizeMatrix.hpp
@@ -160,13 +160,23 @@ public:
 
   void resize(size_t m, size_t n)
   {
-    if (n > n_max_ || m > m_max_)
+    if (n*m > n_max_* m_max_)
     {
       std::ostringstream error;
       error << "You cannot resize a constant size matrix beyond its initial max dimensions ( " << m << "," << n << " > "
             << m_max_ << "," << n_max_ << " )\n";
       throw std::domain_error(error.str());
     }
+    if (n > n_max_) {
+      size_t cap = n_max_ * m_max_;
+      n_max_ = n;
+      m_max_ = cap/n_max_;
+    }
+    if (m > m_max_) {
+      size_t cap = n_max_ * m_max_;
+      m_max_ = m;
+      n_max_ = cap/m_max_;
+    }
     n_ = n;
     m_ = m;
   }

The changes in n_max and m_max are not ideal - the total size according to n_max*m_max can shrink from the original allocation. (I think the integer division will ensure it can't grow). Also this doesn't preserve the row/column indexing of any existing contents. However, this fix is good enough for the CSVMC tests.