centreforhydrology / wdpm Goto Github PK

I see this

Because the matrix locations of each thread are separated by 3 rows and columns, the points are independent, and race conditions are avoided.

But it's unclear to me how this makes it safe since hydrological interactions tend to propagate. A citation or more complete explanation here would be useful.

The performance I am seeing is significantly slower than that listed in the manual. I tried testing using the supplied 'basin5.asc' file, adding 10 mm water with an elevation tolerance of 1 mm, running in serial.
I used a Lenovo Thinkpad T460p with i-7, 2.7 GHz x 4. A comparable system in the user guide took ~140 s to run this command. This took 1048 s for me.
I ran with:

./WDPMCL add basin5.asc null test.asc null 10.0 1.0 1.0 0 0

openjournals/joss-reviews#2276

This is an issue with the downloadable Linux binary, not the GitHub source code, but this still seemed the best place to address it.
I realised that I had just downloaded and attempted to run the program and had missed some additional steps in the manual.
From the manual:

Do sudo make all to build, install and test the Intel and Nvidia OpenCL drivers

When I attempt to do so, I get the following errors:

./installcl.sh: 18: ./installcl.sh: cannot create /etc/OpenCL/vendors/intel.icd: Directory nonexistent
chmod: cannot access '/etc/OpenCL/vendors/intel.icd': No such file or directory
Installation complete.
gcc Deviceinfo.c -lOpenCL -fopenmp -o Deviceinfo -std=c99
Deviceinfo.c: In function ‘CLInitDevices’:
Deviceinfo.c:193:3: warning: ‘clCreateCommandQueue’ is deprecated [-Wdeprecated-declarations]
if( !(cl->queue = clCreateCommandQueue(cl->context, cl->currentDevice, 0, &result)) )
^~
In file included from /usr/include/CL/opencl.h:47:0,
from Deviceinfo.c:9:
/usr/include/CL/cl.h:1443:1: note: declared here
clCreateCommandQueue(cl_context /* context */,
^~~~~~~~~~~~~~~~~~~~
./Deviceinfo
Error is -1001
Error: clGetPlatforms failed: Unknown.

Makefile:8: recipe for target 'test' failed
make: *** [test] Error 1

I am not sure if this could be leading to problems I am having with running this version of the program.

openjournals/joss-reviews#2276

I am having trouble running with OpenCL; I am not sure if the issue is with my installation of OpenCL or elsewhere. When I try running with OpenCL, either with CPU or GPU, I get a segmentation fault. I am able to run the program in serial.
In case it is helpful, 'clinfo' shows the following output:

Number of platforms 1
Platform Name NVIDIA CUDA
Platform Vendor NVIDIA Corporation
Platform Version OpenCL 1.2 CUDA 10.2.185
Platform Profile FULL_PROFILE
Platform Extensions cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_fp64 cl_khr_byte_addressable_store cl_khr_icd cl_khr_gl_sharing cl_nv_compiler_options cl_nv_device_attribute_query cl_nv_pragma_unroll cl_nv_copy_opts cl_nv_create_buffer cl_khr_int64_base_atomics cl_khr_int64_extended_atomics
Platform Extensions function suffix NV

Platform Name NVIDIA CUDA
Number of devices 1
Device Name GeForce 940MX
Device Vendor NVIDIA Corporation
Device Vendor ID 0x10de
Device Version OpenCL 1.2 CUDA
Driver Version 440.100
Device OpenCL C Version OpenCL C 1.2
Device Type GPU
Device Topology (NV) PCI-E, 02:00.0
Device Profile FULL_PROFILE
Device Available Yes
Compiler Available Yes
Linker Available Yes
Max compute units 3
Max clock frequency 1241MHz
Compute Capability (NV) 5.0
Device Partition (core)
Max number of sub-devices 1
Supported partition types None
Max work item dimensions 3
Max work item sizes 1024x1024x64
Max work group size 1024
Preferred work group size multiple 32
Warp size (NV) 32
Preferred / native vector sizes
char 1 / 1
short 1 / 1
int 1 / 1
long 1 / 1
half 0 / 0 (n/a)
float 1 / 1
double 1 / 1 (cl_khr_fp64)
Half-precision Floating-point support (n/a)
Single-precision Floating-point support (core)
Denormals Yes
Infinity and NANs Yes
Round to nearest Yes
Round to zero Yes
Round to infinity Yes
IEEE754-2008 fused multiply-add Yes
Support is emulated in software No
Correctly-rounded divide and sqrt operations Yes
Double-precision Floating-point support (cl_khr_fp64)
Denormals Yes
Infinity and NANs Yes
Round to nearest Yes
Round to zero Yes
Round to infinity Yes
IEEE754-2008 fused multiply-add Yes
Support is emulated in software No
Address bits 64, Little-Endian
Global memory size 2101870592 (1.958GiB)
Error Correction support No
Max memory allocation 525467648 (501.1MiB)
Unified memory for Host and Device No
Integrated memory (NV) No
Minimum alignment for any data type 128 bytes
Alignment of base address 4096 bits (512 bytes)
Global Memory cache type Read/Write
Global Memory cache size 73728 (72KiB)
Global Memory cache line size 128 bytes
Image support Yes
Max number of samplers per kernel 32
Max size for 1D images from buffer 134217728 pixels
Max 1D or 2D image array size 2048 images
Max 2D image size 16384x16384 pixels
Max 3D image size 4096x4096x4096 pixels
Max number of read image args 256
Max number of write image args 16
Local memory type Local
Local memory size 49152 (48KiB)
Registers per block (NV) 65536
Max number of constant args 9
Max constant buffer size 65536 (64KiB)
Max size of kernel argument 4352 (4.25KiB)
Queue properties
Out-of-order execution Yes
Profiling Yes
Prefer user sync for interop No
Profiling timer resolution 1000ns
Execution capabilities
Run OpenCL kernels Yes
Run native kernels No
Kernel execution timeout (NV) Yes
Concurrent copy and kernel execution (NV) Yes
Number of async copy engines 1
printf() buffer size 1048576 (1024KiB)
Built-in kernels
Device Extensions cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_fp64 cl_khr_byte_addressable_store cl_khr_icd cl_khr_gl_sharing cl_nv_compiler_options cl_nv_device_attribute_query cl_nv_pragma_unroll cl_nv_copy_opts cl_nv_create_buffer cl_khr_int64_base_atomics cl_khr_int64_extended_atomics

NULL platform behavior
clGetPlatformInfo(NULL, CL_PLATFORM_NAME, ...) NVIDIA CUDA
clGetDeviceIDs(NULL, CL_DEVICE_TYPE_ALL, ...) Success [NV]
clCreateContext(NULL, ...) [default] Success [NV]
clCreateContextFromType(NULL, CL_DEVICE_TYPE_DEFAULT) No platform
clCreateContextFromType(NULL, CL_DEVICE_TYPE_CPU) No devices found in platform
clCreateContextFromType(NULL, CL_DEVICE_TYPE_GPU) No platform
clCreateContextFromType(NULL, CL_DEVICE_TYPE_ACCELERATOR) No devices found in platform
clCreateContextFromType(NULL, CL_DEVICE_TYPE_CUSTOM) Invalid device type for platform
clCreateContextFromType(NULL, CL_DEVICE_TYPE_ALL) No platform

ICD loader properties
ICD loader Name OpenCL ICD Loader
ICD loader Vendor OCL Icd free software
ICD loader Version 2.2.11
ICD loader Profile OpenCL 2.1

openjournals/joss-reviews#2276

These blocks have near-duplicate functionality. Good coding practice is to abstract repetition into functions, please do so.

openjournals/joss-reviews#2276

WDPM/src/ contains C files and OpenCL files. These need a build system so they can be reproducibly compiled into a binary by the user. CMake is a strong, cross-platform choice. Make might be initially simpler to work with, but will be more challenging cross-platform.

An example of using CMake is here. If you have difficulty working with cmake, please comment here and I can help.

openjournals/joss-reviews#2276

Overlaps with #16, #20, and/or #23.

Following the compilation instructions given in the manual here, I find that the program is missing a CL subdirectory.

$ gcc WDPMCL-Command-line.c -lOpenCL -o WDPMCL
WDPMCL-Command-line.c:25:10: fatal error: CL/cl.h: No such file or directory
   25 | #include <CL/cl.h>
      |          ^~~~~~~~~
compilation terminated.

openjournals/joss-reviews#2276

These lines, and probably others in the repo, are part of a Python2 compatibility strategy.

Python2 was discontinued on January 1, 2020 after a 12 year decommissioning process. Supporting Python2 at this point is a Sisyphean task; it would be better to remove such support.

openjournals/joss-reviews#2276

These lines show a large amount of duplication. This could be reduced by looping over a list of components to enable/disable. It also suggests that perhaps the UI should be broken into separate controller classes that can be enabled/disabled separately. Handling everything in single mass code blocks is a recipe for low maintainability.

openjournals/joss-reviews#2276

I am trying to run this using the WDPM.py file and it calls for a cmap_black.sh file, which is not included. The manual does not provide any description of this file for me to create it myself, so I suspect it should have been provided.

openjournals/joss-reviews#2276

This section is pretty dense. White space coupled with appropriate comments would make its maintenance easier.

openjournals/joss-reviews#2276

The link in the README (http://www.usask.ca/hydrology/WDPM.php) redirects to (https://research-groups.usask.ca/hydrology/). There are no executables available here.

Executables should rarely, if ever, be distributed with a Git repo. The repo should contain sufficient material to generate the executables.

openjournals/joss-reviews#2276

The manual includes some examples, e.g. 100 mm of water added. However, it does not state what runoff fraction, elevation tolerance, etc was used to obtain the results seen so that a user can more easily test and compare results.

openjournals/joss-reviews#2276

I can't find a contributors guide.

See https://github.com/holukas/dyco/blob/main/CONTRIBUTING.md for an example

openjournals/joss-reviews#2276

There are many instances of checking if something is true, e.g. this. Doing so is non-Pythonic.

openjournals/joss-reviews#2276

You state:

"Subtraction of water may be due to infiltration to the soils, but in the Prairies it is more commonly caused by evaporation."

Could you cite a source demonstrating that this is the case?

openjournals/joss-reviews#2276

You write in the acknowledgments that, "Much of the OpenCL code and the Python GUI were written by Oluwaseun Sharomi." I am glad that you have acknowledged Sharomi's contributions. However, the OpenCL code and Python GUI are key pieces of what you are publishing here. I do not see Sharomi's name in the references for any work that they may have previously published, which could have been a reason to just cite their work as a basis for what you are presenting here. Therefore, it would seem that Sharomi's work is being published for the first time here without their direct participation. I find this concerning.

Could you justify your rationale for your provided author list and/or consider expanding it in a way that would seem to give more appropriate credit to contributors?

I haven't seen any file indicating code dependencies.

For Python, a requirements.txt file would be helpful.

For other dependencies, such as gdaldem, which appears in WDPM/src/cmap_black.sh, the README file or a conda requirements file should indicate the dependency.

openjournals/joss-reviews#2276

I'm not finding a test suite.

This site explains how to build one.

In our recent FillSpillMerge work we used randomized testing to generate hundreds of thousands of artificial landscapes and then tested

1. To see if adding a very large amount of water gives a result exactly equal to depression filling,
2. That incrementally adding portions of water gives the same result as adding the same amount of water all at once
3. And more, see link for details.

Performing extensive tests identified bugs in our software and we were able to fix them before they impacted downstream science. Given the complexity of WDPM having a good set of unittests seems appropriate.

• "Removing the water and smoothing to a tolerance of 1 mm required 1,000 iterations - the minimum possible."

  • The minimum possible what?

• " by several government agencies and by private consultants."

  • Could you provide examples and/or references?

@whedon generate pdf

With the error message:

Gdk-Message: 22:39:47.991: WDPM.py: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.

This happens when I click 'start', but only sometimes with a given set of parameters.

openjournals/joss-reviews#2276

Import should be sorted alphabetically and grouped, per the pep8 style guide (link).

Imports are always put at the top of the file, just after any module comments and docstrings, and before module globals and constants.

Imports should be grouped in the following order:

Standard library imports.
Related third party imports.
Local application/library specific imports.
You should put a blank line between each group of imports.

Problems include, but are not limited to this.

openjournals/joss-reviews#2276

"Computation Settings" don't appear to be documented in the manual. Other settings from the GUI may also be undocumented.

Although the manual should document everything since you're otherwise relying heavily on it for this purpose, using tooltips in the GUI would be a much more accessible way of communicating the information, eg, https://codeloop.org/how-to-create-tooltip-in-wxpython/

In the paper, you claim:

"Addition of water could be caused by rainfall, but in the Prairies it is more commonly due to snowmelt runoff."

Can you cite a reference showing that this is true? Considering that the formerly-glaciated prairies cover a large north--south extent, I am not sure that this is the case everywhere, or even in most cases.

openjournals/joss-reviews#2276

Production code should not have functionality commented out. If you're not using it, remove it. If you might use, make a flag of some sort to control access. These lines are a notable instance.

openjournals/joss-reviews#2276

WDPMCL-threshold6.c is referenced in CMakeLists.txt, but doesn't appear in the repo.

Could you explain what makes Prairie a proper noun? Is there a specific prairie region that you have in mind, and/or is this simply convention in Canadian English?

openjournals/joss-reviews#2276

The link included in the README.md should be updated to:
https://research-groups.usask.ca/hydrology/modelling/wdpm.php

This also illustrates one difficulty of hosting documentation off-site. I may suggest that you include the manual as part of this repo (perhaps via git LFS, if you are concerned about space + commits). This can then become part of a version of record, published permanently via Zenodo -- or (potentially, I do not know) directly via JOSS.

openjournals/joss-reviews#2276

Python2 was discontinued on January 1, 2020 after a 12 year decommissioning process.

At this point print statements need parens:

print("This is now the only way to print in Python.")

openjournals/joss-reviews#2276

Pylint and Black are Python linters: programs that parse your code to detect mistakes, bugs, and bad practices before they become an issue. I use them regularly and many of my industry collaborators set up their git repos so they are physically unable to commit code that doesn't pass linting checks. Given the number of issues in the existing Python code, using a linter is probably the fast way to improve it.

I forget if Pylint or Black do this, but some linters complain if functions have too many if clauses or classes have too many methods. This can be difficult to resolve, but doing so would resolve some cases where I feel the existing logic is difficult to follow, especially since there are no comments.

openjournals/joss-reviews#2276

Compiling with this CMakeLists.txt file using the -Wall -pedantic combo reveals a number of code issues including unused variables, unchecked file I/O returns, and uninitialized variables. These should all be resolved.

openjournals/joss-reviews#2276

Mystery binary blobs should be avoided whenever possible: the repo itself should generating them for transparency, reproducibility, and mutability. I'm not sure what WDPM/src/WDPMCL is.

openjournals/joss-reviews#2276

openjournals/joss-reviews#2276

Having vital information tucked away in a PDF file doesn't seem like a good idea to me.

• It makes the information harder to search both from the web, from the CLI, and from within an IDE.
• It makes it more challenging to version control
• The TeX format can be unintuitive to some and you're not making use of most of its powerful features (e.g., equation typesetting, extensive cross-referencing) here, so I don't see a compelling reason to use it for those.
• It means that a user looking at your software immediately has to start digging to even figure out how to use it. Presenting more information on the README page would be a nicer first experience.
• Even the README page doesn't actually provide a hyperlink to the manual.

I would feel more comfortable if you were to translate the manual into markdown format. That makes it easy to read on Github, easy to version control, and still human-readable in any standard code editor.

A few links to people arguing against PDFS:
https://www.theguardian.com/higher-education-network/2015/feb/11/researchers-its-time-to-ditch-the-pdf

https://www.nngroup.com/articles/pdf-unfit-for-human-consumption/

https://blog.scholasticahq.com/post/why-pdfs-no-longer-enough-file-types-digital-journals/

https://www.theatlantic.com/science/archive/2018/04/the-scientific-paper-is-obsolete/556676/?single_page=true

I'm getting some inconsistent behaviour and I'm not sure if it is user error or if the program just isn't working.

On the version I have compiled myself:
Once I press start, the following comes up:

Please wait ........................
                                          
Program arguments in order of specification
Add module specified
Path and Name of Report file
DEM file name (string)
Water file name (string)
Output file name (string)
Scratch file name (string) - Optional, use --NULL-- to omit
Depth of water to add (mm) (real)
Water runoff fraction (real)
Elevation tolerance (mm) (real)
Specify 0 for serial CPU and 1 for opencl 
Specify 0 for OpenCL CPU and 1 for opencl GPU 

and then nothing further happens. If I click 'end', it says that the simulation is not running. No result file is created. My settings are shown in the image.

Strangely, one time when I ran this, it did create a reasonable-looking output file. I am not certain what my exact settings were for that one time since I had not yet realised this was an issue, but I think they were the same as in the screenshot. I have not been able to make this work a second time.

In the binary version I downloaded, the statements printed out are different, and this one seems to specify an error:
Couldn't identify a platform: No such file or directory
I am not sure which file it can't find.

openjournals/joss-reviews#2276

In the C code I see inconsistent formatting like so:

    final_vol=final_vol*cellarea;
    meanwater = watertotal/((float)watercount);
    basincount=0;
      for(i=0; i<numrows; i++){
    for(j=0; j<numcols; j++){
	    if(dem[i][j]>missingvalue){
            basincount++;
	    }
	}
    }

This is because the code intermixes tabs and spaces. It's likely that my tab display width is different from yours.

Please reformat the code to consistently use only spaces for whitespace (this is a common requirement of coding style guides).