Closed wsmorgan closed 7 years ago
I like option 1 better. Is it hard to implement?
As for the optional argument being in the "wrong" place. I don't really mind; optional arguments don't need to be in order, but it doesn't hurt to make it more intuitive.
No it's not. I've implemented both changes and they will be implemented in version 1.0.7.
Great
This bug was uncovered by @lancejnelson When trying to compile compare_enum_files.x the following error occurs:
This happens because the file name in the compare_enum_files.f90 driver has a declared shape of 800 but the file name variable in io_utils read_struct_enum_out is an allocatable with deferred shape.
We have two options 1) change the variable in the compare_two_enum_files.f90 to be allocatable or 2) change the variable in io_utils to have a specific size (I would recommend 800 since that's the current size in compare_two_enum_files.f90 is the only place the subroutine gets called). However, since I'm not sure how widely these subroutines are used I wanted to get another opinion before implementing either solution.
Also @lancejnelson noticed that the fname in read_struct_enum_out is optional but not the last argument being passed to the function. This works, for now, but it seems counter intuitive should we re-organize the arguments to make more sense?