OpenArray v1.0: a simple operator library for the decoupling  of ocean modeling and parallel computing

Huang, Xiaomeng; Huang, Xing; Wang, Dong; Wu, Qi; Li, Yi; Zhang, Shixun; Chen, Yuwen; Wang, Mingqing; Gao, Yuan; Tang, Qiang; Chen, Yue; Fang, Zheng; Song, Zhenya; Yang, Guangwen

doi:https://doi.org/10.5194/gmd-12-4729-2019

Articles | Volume 12, issue 11

https://doi.org/10.5194/gmd-12-4729-2019

© Author(s) 2019. This work is distributed under
the Creative Commons Attribution 4.0 License.

https://doi.org/10.5194/gmd-12-4729-2019

© Author(s) 2019. This work is distributed under
the Creative Commons Attribution 4.0 License.

Articles | Volume 12, issue 11

Development and technical paper

|

11 Nov 2019

Development and technical paper |

| 11 Nov 2019

OpenArray v1.0: a simple operator library for the decoupling of ocean modeling and parallel computing

Xiaomeng Huang, Xing Huang, Dong Wang, Qi Wu, Yi Li, Shixun Zhang, Yuwen Chen, Mingqing Wang, Yuan Gao, Qiang Tang, Yue Chen, Zheng Fang, Zhenya Song, and Guangwen Yang

Download

Final revised paper (published on 11 Nov 2019)
Preprint (discussion started on 25 Feb 2019)

Interactive discussion

Status: closed

AC: Author comment | RC: Referee comment | SC: Short comment | EC: Editor comment

- Printer-friendly version

- Supplement

RC1: 'Review for Huang et al.', Anonymous Referee #1, 06 Mar 2019
- AC1: 'Responses to the comments of referee #1', Xiaomeng Huang, 15 Mar 2019
RC2: 'Review of Huang et al.', David Webb, 25 Mar 2019
- AC2: 'Responses to the comments of Dr David Webb', Xiaomeng Huang, 16 Apr 2019

Peer-review completion

AR: Author's response | RR: Referee report | ED: Editor decision

AR by Anna Wenzel on behalf of the Authors (22 May 2019) Author's response

ED: Referee Nomination & Report Request started (04 Jun 2019) by Steven Phipps

RR by Anonymous Referee #1 (05 Jun 2019)

RR by David Webb (23 Jun 2019)

Suggestions for revision or reasons for rejection

Unsuitable for GMD

Having judged the original paper as being unsuitable for GMD I was not keen to review the revised version, but I received a plea from the Topic Editor to check that the model could be compiled with the ‘new’ instructions (apparently earlier neither referee had managed to compile the model).

After some effort (see below) I managed to compile the programs and routines in the top level and in directory ‘c-interface’. The compile process then failed in the ‘modules’ directory:

============================
mpicxx -O3 -ffast-math -DBOOST_LOG_DYN_LINK -fopenmp -c -fPIC --std=c++0x -Werror=return-type -fno-trapping-math -fno-signaling-nans modules/tree_tool/Simple_Node.cpp -o modules/tree_tool/Simple_Node.o
modules/tree_tool/Simple_Node.cpp: In member function ‘void* Simple_node::get_val()’:
modules/tree_tool/Simple_Node.cpp:30:1: error: control reaches end of non-void function [-Werror=return-type]
}
^
cc1plus: some warnings being treated as errors
make: *** [makefile.linux:63: modules/tree_tool/Simple_Node.o] Error 1
=============================

In addition to my earlier comments I conclude, from the sequence of problems that arose in trying to compile the code again, that the model and instructions are not robust enough for use by the GMD community. I found nothing in the revised paper that tempted me to revise my earlier comments. I therefore again recommend that the paper be rejected by GMD and instead be submitted to a more suitable computer (or software) science journal.

Test process

I was conscious last time of the number of additional packages that I had to install before I could compile the programs. One of the problems seemed to be that the authors were use to using scripting packages, for example fypp, which are not usually used by the community running geophysical models. At the same time they were treating gcc, fortran, openmpi and netcdf as being special.

Another oddity was the use of pnetcdf, somewhat outdated, and a lack of specificity about which version of python or openmpi to use.

This time I started with a clean install of opensuse 15.1, the KDE desktop version. The use manual talks of compiling the various subroutine libraries etc, but my experience last time and with other systems is that each library usually requires at least one other library to be compiled and the whole process can take for ever.

Instead modern distributions use packages, installation of one package automatically installing any additional required packages. The authors need to revise their user manual to reflect this.
With opensuse 15.1 I could install packages:

gcc7-7.4.0, gcc7-fortran-7.4.0, gcc7-c++-7.4.0 (+ 12 packages)
openmpi1-gnu-hpd-devel (+13 packages)
pnetcdf (+26 packages)
armadillo-devel

To download from the git repository I also needed git:
git (+ 25 packages)

The system had python3 already installed. But script test.sh needed python. Other packages I found I had to install to get to the compile stage are:
python-base (+ 2 packages)
ctags
lua-luarocks
clang7 (+21 packages)

Additional packages were also installed but unfortunately it is only after installation that I can be sure that the package contains, for example the include file, that is needed.

Time taken : parts of 4 days (probably about 10 hours).

Hide

ED: Reconsider after major revisions (09 Jul 2019) by Steven Phipps

Dear authors,

Thank you for submitting a revised version of your manuscript.

You will see that both referees have made extensive comments about the source code and manual for OpenArray, based on their experiences of attempting to compile the library and test case. Referee #1 was able to compile the library and test case, but only with some modifications. Referee #2 was not successful. As a result, referee #2 concludes that "the model and instructions are not robust enough for use by the GMD community".

Under the circumstances, I attempted to compile the library and test case myself. For these purposes, I used a clean install of Fedora 22 and the KDE desktop version. I was able to compile the library, although I have a couple of comments:

(i) On my machine, the names of the Intel MPI compilers are mpifort, mpicc and mpic++. The compiler flag to enable OpenMP is also -openmp, rather than -qopenmp. Both of these required me to edit the makefile.

(ii) I had to install the ctags package to avoid an error at the precompile stage.

However, I was unable to compile the test case. Firstly, it would be helpful if the instructions could make it clear that you need to be in the build/ directory, rather than the top-level directory. Nonetheless, the main problem is simply that the model does not compile:

mpifort -O0 -w -g -std=c++0x -DBOOST_LOG_DYN_LINK -openmp -D_WITHOUT_LLVM_ -o manual_main user-manual/oa_main.o \
-lpnetcdf -lboost_program_options -lboost_filesystem -lboost_system -lboost_log -lboost_log_setup -lboost_thread -ldl -ljit -lgfortran -Wl,-rpath=/lib64/ -lstdc++ -L/lib64/ -lpnetcdf -lboost_program_options -lboost_filesystem -lboost_system -lboost_log -lboost_log_setup -lboost_thread -ldl -ljit -lgfortran -Wl,-rpath=/lib64/ -lgfortran -L. -lopenarray -lm -ldl -lstdc++ -lboost_program_options \
-lboost_system -lboost_log -lboost_log_setup -lboost_thread -lpnetcdf -lpnetcdf
/usr/bin/ld: cannot find -ljit
/usr/bin/ld: cannot find -ljit
collect2: error: ld returned 1 exit status
makefile.intel:146: recipe for target 'manual_main' failed

Clearly, there is at least one undocumented dependency on an external library that is causing compilation to fail.

I am afraid, therefore, that I agree with Referee #2 that OpenArray is not yet in a sufficiently robust state for me to allow publication in Geoscientific Model Development. Ultimately, while your manuscript fulfils the GMD mission of documenting the software, it remains the case that the software described must also be useful to the community.

I have therefore made the decision “Reconsider after major revisions”. Referee #1 has suggested that the text of the manuscript would benefit from proof-reading. Apart from this, I would like to emphasise that the text of the manuscript itself is satisfactory and you should not consider that you need to make changes.

Rather, my reason for returning the manuscript to you at this stage is to allow you to revise the manual and source code of OpenArray, in response to the comments of both referees and in response to my own comments above. I hope you can agree that your manuscript will be strengthened considerably if OpenArray is a robust tool that can readily be adopted by the community.

Kind regards,
Steven Phipps
Handling Topical Editor

Hide

AR by Xiaomeng Huang on behalf of the Authors (19 Aug 2019) Author's response Manuscript

ED: Referee Nomination & Report Request started (05 Sep 2019) by Steven Phipps

RR by Anonymous Referee #3 (10 Sep 2019)

ED: Publish subject to technical corrections (26 Sep 2019) by Steven Phipps

AR by Xiaomeng Huang on behalf of the Authors (30 Sep 2019) Author's response Manuscript

Post-review adjustments

AA: Author's adjustment | EA: Editor approval

AA by Xiaomeng Huang on behalf of the Authors (30 Oct 2019) Author's adjustment Manuscript

EA: Adjustments approved (31 Oct 2019) by Steven Phipps

Short summary

We designed a simple computing library (OpenArray) to decouple ocean modelling and parallel computing. OpenArray provides 12 basic operators featuring user-friendly interfaces and an implicit parallelization ability. Based on OpenArray, we implement a practical ocean model with an enhanced readability and an excellent scalable performance. OpenArray may signal the beginning of a new frontier in future ocean modelling through ingesting basic operators and cutting-edge computing techniques.