tamnva / r-swat Goto Github PK

Please rather use the Authors@R field and declare Maintainer, Authors
and Contributors with their appropriate roles with person() calls.
e.g. something like:
Authors@R: c(person("Alice", "Developer", role = c("aut", "cre","cph"),
email = "[email protected]"),
person("Bob", "Dev", role = "aut") )

The Description field is intended to be a (one paragraph) description of
what the package does and why it may be useful. Please add more details
about the package functionality and implemented methods in your
Description text.

If there are references describing the methods in your package, please
add these in the description field of your DESCRIPTION file in the form
authors (year) doi:...
authors (year) arXiv:...
authors (year, ISBN:...)
or if those are not available: https:...
with no space after 'doi:', 'arXiv:', 'https:' and angle brackets for
auto-linking. (If you want to add a title as well please put it in
quotes: "Title")

Please always explain all acronyms in the description text. -> SWAT/SWAT+

Please add \value to .Rd files regarding exported methods and explain
the functions results in the documentation. Please write about the
structure of the output (class) and also what the output means. (If a
function does not return a value, please document that too, e.g.
\value{No return value, called for side effects} or similar)
Missing Rd-tags:
dds.Rd: \value
userObjFunction.Rd: \value
userReadSwatOutput.Rd: \value

You have examples for unexported functions. Please either omit these
examples or export these functions.
Examples for unexported function
observedToList() in:
observedToList.Rd
readFileContent() in:
readFileContent.Rd
simToList() in:
simToList.Rd

Please make sure that you do not change the user's options, par or
working directory. If you really have to do so within functions, please
ensure with an immediate call of on.exit() that the settings are reset
when the function is exited.
e.g.:
...
oldwd <- getwd() # code line i
on.exit(setwd(oldwd)) # code line i+1
...
setwd(...) # somewhere after
...
e.g.: -> R/runSWATpar.R; R/saveOutput.R
If you're not familiar with the function, please check ?on.exit. This
function makes it possible to restore options before exiting a function
even if the function breaks. Therefore it needs to be called immediately
after the option change within a function.

Please do not modify the global environment (e.g. by using <<-) in your
functions. This is not allowed by the CRAN policies.
-> inst/R-SWAT/server.R

Please fix and resubmit.

The server.R file is currently quite long, could create difficulties for collaboration. Any ideas how to split this file to smaller files is welcome

When SWAT is run in parallel (Step 3. Run SWAT => Click here to run SWAT) the progress bar does not updated. It is either half full (when SWAT starts running) and full and disappear (when all SWAT simulations are done)

openjournals/joss-reviews/issues/6797

The code is clear and the structure seems to be consistent across the different scripts. However, I have tried to run devtools::check() and it does not work due to the following error associated with the vignettes:

Also, I have needed to install some additional dependencies for the check:

I have some minor comments:

• Due to the dependency with the “parallel” package (which is integrated in core R), RSWAT requires the latest versions of R (>4.1.1), so it needs to be added.
• There are some other dependencies that are missing and not included in the DESCRIPTION file(e.g., 'magrittr' 2.0.1 is being loaded, but >= 2.0.3 is required)
• If the selected directory (tempdir) does not exist, the package should create the folder in the system
• Consider creating a documentation website using the “pkgdown” (or a similar) package.

Hi,
I'm working through the JOSS review. One of the review checklist items includes:

• Installation instructions: Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.

A couple of things to note here.
First, the README and DESCRIPTION do not explicitly state you need SWAT or SWAT+ executable files. I'd include this in the README with a link to the respective downloads for each OS. In the DESCRIPTION, this requirement should be included in the SystemRequirements field. (See https://r-pkgs.org/description.html#other-fields).

Second, it isn't realistic to automate including SWAT with the package given CRAN packaging constraints. But, I think a function to download and copy a SWAT/SWAT+ executable to the project folder would be useful. The function should return the file path, then this can be provided as the SWAT executable file path argument in runSWATpar().

The first item should be fixed (IMO), but the second item is just a suggestion.

EDIT: Reference JOSS Review thread:
openjournals/joss-reviews#6797

I haven't checked how to call swat executable file (Lines 190-195 in this file in Linux operating system => TODO

Con not find CurrentSimulationReport.log file in the Output folder. There is an error:
Listening on http://127.0.0.1:7554 [SPS-ERROR] 2023-09-15 11:04:32 task 1 failed - "NA/NaN argument"

Please help solve this problems.

Comments from the JOSS editor (openjournals/joss-reviews#6320)

This isn't really packaged to normal R standards (it seems like users are intended to clone the repo and edit scripts before installing the package, which isn't typical) and there's a lot of odd code choices (long chain of "x == y | x == z |", rather than using %in%; bulky wrappers around built-in functions).

openjournals/joss-reviews/issues/6797

The manuscript describes the RSWAT package, as a tool to work different versions of the Soil and Water Assessment Tool (SWAT). While the manuscript adequately introduces the tool, I have some general comments:

First, the contribution of the package is not very clear for me. The manuscript says the package basically replicates the R-SWAT shiny app, but allowing to work without the Graphical User Interface. The other overcome limitations mentioned on the paper seem to be minor too, so I wonder why R-SWAT and RSWAT could not be merged into a single and more complete package. Indeed, the documentation says that RSWAT is an update of the older version “The older version of this package, called the R-SWAT app”.

Anyway, if there are reasons to have them as separate packages, these should be more clearly stated in the paper. In addition, I believe the subsection “Features” could be merged into the statement of need, to clarify the innovative features of the package.

In this line, I would create a new subsection (“Functionality” or similar) that shows some code examples and some potential outputs (e.g. a figure), in line with other manuscripts in JOSS. This is, in my opinion, helpful for the users to better understand the package.

I have also some specific comments:

• L7: The first sentence is repetitive, and should be modified to better introduce the topic
• L10: “A model-specific tool” sounds confusing
• L19: “developed since its development”
• L21: “To solve new challenges”. Could you provide an example?
• L23: Minor
• L23-24: Could you elaborate more on these changes?
• L41: As said, these limitations could be solved within the R-SWAT package by, for example, using Docker containers to eliminate package dependencies, or documenting the functions within the R-SWAT documentation site.
• L55: Not sure if this text requires its own subsection or could be merged with the previous one

Currently, selecting the SWAT executable file, SWAT parameter files, and observed file use shinyFilesButton, but the response of this function is quite slow and it does not keep track of the last directory browsed (for long file path, this is quite inconvenient). Any suggestions are welcome

Hi,
One more checklist issue from the JOSS review checklist:

• Automated tests: Are there automated tests or manual steps described so that
  the functionality of the software can be verified?

I see you have the testthat framework started on the main branch. Are you planning on incorporating unit tests here? One of my major comments when using runSWATpar() are the lack of helpful error messages when arguments are incorrect. For example, my working folder had not been created yet, but instead of an error saying the folder did not exist I received:
Error in if (substr(temp, 1, 9) == "TxtInOut_") { : missing value where TRUE/FALSE needed
So, I think including some functions that check file paths are valid and that arguments are the expected types (data.frame, character, vector, etc.) would be an improvement for troubleshooting. These would be useful automated tests that ensure graceful failures and diagnosable errors are returned.

A second point, related to #47 is that there are a lot of functions hidden within server.R or the inst folder. It would be useful to move those to /R where the function could be documented, exported, and tested. I'm not a Shiny developer and don't have a great perspective of best practices for packaging up Shiny apps, so hopefully this is not bad advice! That would also eliminate a check note I get when building the package locally:

* checking dependencies in R code ... 
NOTE
Namespaces in Imports field not imported from:
'DT' 'excelR' 'ggplot2' 'htmltools' 'plotly' 'shinyFiles'
'shinydashboard' 'shinyjs' 'spsComps' 'tippy'
All declared Imports should be used.

Refactoring the Shiny app would potentially be a lot of work. But I think at least including some tests for runSWATpar() would be very helpful.

Edit: Cross reference JOSS review thread:
openjournals/joss-reviews#6797