int32 overflow leads to crash in shaping_driver.

[BradWhitlock]

I ran the shaping_driver and it crashed on a relatively small mesh. It seems that the problem is caused by an int32 overflow that causes a negative size. mfem::DenseTensor uses int32 for computing sizes and it computes its TotalSize using dofs*dofs*NE.

• Can we work around it for large sizes?
• Or, is there an MFEM that uses an "IndexType" rather than int?
• Does the mass_integrator.AssembleEA() call really need to work on dofs*dofs*NE? Or should the size dimension really be pow(dofs,1/2) or pow(dofs, 1/3)?

  examples/quest_shaping_driver_ex -i $AXOM_DIR/data/shaping/spheres.yaml \
    --method sampling --sampling inout inline_mesh --min -1.1 -1.1 -1.1 --max 1.1 1.1 1.1 --dimension 3 \
    --background-material void --caliper report --order 4 --policy seq --res 64 64 64 --quadrature-order 4

[INFO]: Creating inline box mesh of resolution [ 64 64 64] and bounding box { min:(-1.1,-1.1,-1.1); max:(1.1,1.1,1.1); range:<2.2,2.2,2.2> }
[INFO]: After loading mesh has 262,144 elements and (approximate) bounding box { min:(-1.1,-1.1,-1.1); max:(1.1,1.1,1.1); range:<2.2,2.2,2.2> }
[INFO]: ========================Sampling InOut fields for shapes========================
[INFO]: --------Processing shape 'background' of material 'void' (format 'none')--------
[INFO]: -------Processing shape 'outer_shell' of material 'steel' (format 'stl')--------
[INFO]: --------Processing shape 'inner_ball' of material 'void' (format 'stl')---------
[INFO]: ================Generating volume fraction fields for materials=================
NE=262144
dofs=125
sz=-198967296