Overflow with huge number of variables

[NamjaeChoi]

Overflow with huge number of variables

[lindsayad]

@NamjaeChoi is a relatively new member of the Griffin team, so he works pretty closely with @YaqiWang

[jwpeterson]

#include <iostream>
#include <limits>
#include <cmath>

// This is a test to see if there is overflow in a temporary
// calculation used to initialize a member variable.
// https://github.com/libMesh/libmesh/issues/3541
struct Test
{
public:
  Test(unsigned int row_i, unsigned int size) :
    end_location(row_i * size + size - 1)
    {}
  
  const std::size_t end_location;
};

int main()
{
  Test t0(128, 128);
  std::cout << t0.end_location << std::endl; // prints 16511

  unsigned int large = std::sqrt(std::numeric_limits<unsigned int>::max()) - 1;
  Test t1(large, large); 
  std::cout << t1.end_location << std::endl; // prints 4294770689

  Test t2(65536, 65536); 
  std::cout << t2.end_location << std::endl; // should print 4295032831, but prints 65535 instead
  
  return 0;
}

OK, I think I am wrong. I tried this test, and the intermediate row_i * size calculation is apparently done as an unsigned int and overflows.

[jwpeterson]

We could probably switch to using std::size_t when referring to the number of variables, but I think you will likely run into lots of other issues if you try to solve an actual problem with > 65536 vars.

[NamjaeChoi]

What could be the other issues than overflow?

[jwpeterson]

I think just general slowness mostly. @YaqiWang could possibly comment further on this, since he has used libMesh (via MOOSE) to solve problems with thousands (but I think not 10s of thousands) of variables. We fixed some of the slowness issues for him, but I'd be willing to bet there are others.

[jwpeterson]

Also, just to mention so that we are on the same page, the number of variables in libMesh is not the same thing as the number of unknowns (DOFs) you can solve for, which can obviously be much more.

[NamjaeChoi]

Yeah, we are on the same page. The number of variables is fairly large in neutronics applications, which is determined as the number of directions multiplied by the number of energy groups.

[YaqiWang]

The number of variables itself does not cause overflow. The places we need to be careful where square of it appears for example should be limited. I think with a test case, we can find those places.

[jwpeterson]

OK, so in the specific line you mentioned,

    _end_location(_row_i*_mat.size()+_mat.size()-1)

I don't think there is overflow because _end_location is already std::size_t:

  const std::size_t _end_location;

Even though _row_i is an unsigned int, the compiler "upgrades" the temporary result of _row_i*_mat.size() to a std::size_t.

[YaqiWang]

@NamjaeChoi can you double check this?