Open dqwu opened 7 years ago
@jedwards4b might have some pointers on why the feature (num aggregators) was not implemented in PIO2. Meanwhile, we could get rid of some of these tests (if they don't test anything new) for faster test runs.
I think that I didn't implement in pio2 because I never saw a measurable benefit of changing aggregators in pio1. But we probably should implement this feature so that if an mpiio layer or new hardware came along that benefited from this feature we would be ready to act on it.
Some Fortran decompose tests are using aggregators: pio_decomp_tests_4p_1agg pio_decomp_tests_4p_2agg pio_decomp_tests_4p_3agg pio_decomp_tests_4p_2iop_1agg pio_decomp_tests_1d_4p_1agg pio_decomp_tests_1d_4p_2agg pio_decomp_tests_1d_4p_3agg pio_decomp_tests_1d_4p_2iop_1agg pio_decomp_tests_2d_4p_1agg pio_decomp_tests_2d_4p_2agg pio_decomp_tests_2d_4p_3agg pio_decomp_tests_2d_4p_2iop_1agg pio_decomp_tests_3d_4p_1agg pio_decomp_tests_3d_4p_2agg pio_decomp_tests_3d_4p_3agg pio_decomp_tests_3d_4p_2iop_1agg
There is an option "--pio-tf-num-aggregators" to specify the number of aggregators for these tests. The argument will be passed to the PIO_init interface.
PIO_init interface will call the following subroutine in piolib_mod.F90
subroutine init_intracom(comp_rank, comp_comm, num_iotasks, num_aggregator, stride, rearr, iosystem,base, rearr_opts)
However, in this subroutine, num_aggregator parameter (the mpi aggregator count) is never used. This means the following 3 tests are exactly the same: pio_decomp_tests_4p_1agg pio_decomp_tests_4p_2agg pio_decomp_tests_4p_3aggIf the aggregators will not be used, should we update these tests (rename and reduce) to yield lighter test load?