MESAHub/mesa

Use allocatable arrays in predictive_mixing

evbauer opened this issue · 2 comments

On the distillation branch, Rob pointed out to me that there's a risk of stack overflow when using explicit shape automatic arrays, for example to declare an extra array for saving the composition in case it needs to be reset. (See discussion at a31cb38#r117329563.)

This was a construction I had copied over from predictive mixing, which makes even more extensive use of such automatic arrays:

real(dp) :: lnd_save(s%nz)
real(dp) :: Cp_save(s%nz)
real(dp) :: Cv_save(s%nz)
real(dp) :: gamma1_save(s%nz)
real(dp) :: grada_save(s%nz)
real(dp) :: chiRho_save(s%nz)
real(dp) :: chiT_save(s%nz)
real(dp) :: lnfree_e_save(s%nz)
real(dp) :: d_eos_dlnd_save(num_eos_basic_results,s%nz)
real(dp) :: d_eos_dlnT_save(num_eos_basic_results,s%nz)
real(dp) :: xa_save(s%species,s%nz)
real(dp) :: zbar_save(s%nz)
integer :: k
real(dp) :: w
real(dp) :: rho_face_save(s%nz)
integer :: op_err
logical :: make_gradr_sticky_in_solver_iters

@rhdtownsend do you think it would be worthwhile to refactor this code to use something more like the saved_data construction with allocatable arrays like in conv_premix?

Does it help, though? Are we not just delaying the inevitable until there's an assignment of allocate statement? Or does an array being allocatable mean that only parts of it will go on the stack when needed (in which case I agree with using allocatable arrays)? I do find the explicit shapes help readability, though that can also be achieved in a comment.