Error when requesting HRU level output data.

[alahri89]

Hi Chris,

I receive an error message when using run_swat2012 with SWATplusR 0.6.4.

I prepared a minimum example that reproduces the error on my system:

library(SWATplusR)
library(tibble)

par <- tibble(`DEPIMP_BSN.bsn | change = absval` = 2000)

swist22_mgmt_txtinout_path <- file.path(
  "D:",
  "SWAT-Projects",
  "Swist",
  "Modellvarianten",
  "Swist22",
  "Scenarios",
  "3_mgmt",
  "TxtInOut"
)

results <- run_swat2012(
  project_path = swist22_mgmt_txtinout_path,
  output = define_output(
    file = "hru",
    variable = "LULC",
    unit = 1:1824
  ),
  parameter = par
)

Error message:

Building 1 thread in 'D:/SWAT-Projects/Swist/Modellvarianten/Swist22/Scenarios/3_mgmt/TxtInOut/.model_run': 
 Completed 1 thread in 39S                                                  
Performing 1 simulation on 1 cores: 
 Simulation 1 of 1   Time elapsed: 4M 33S   Time remaining: 0S    Error in { : 
  task 1 failed - "The size of `nm` (86) must be compatible with the size of `x` (85)."

What's strange that that error occurs only with that specific parameter (DEPIMP_BSN.bsn) when trying to obtain HRU level output. If I change another parameter, or try to change DEPIMP_BSN.bsn requesting other output data (RCH or SUB), no error occurs.

I noticed closed issue https://github.com/chrisschuerz/SWATrunR/issues/8 mentions a very similar problem.

Here is the stack trace:

4: stop(simpleError(msg, call = expr))
3: e$fun(obj, substitute(ex), parent.frame(), e$data)
2: foreach(i_run = 1:n_run, .packages = c("dplyr", "lubridate", 
       "stringr", "processx"), .options.snow = opts) %dopar% {
       worker_id <- paste(Sys.info()[["nodename"]], Sys.getpid(), 
           sep = "-")
       thread_id <- worker[worker$worker_id == worker_id, 2][[1]]
       thread_path <- run_path %//% thread_id
       if (!is.null(parameter)) {
           thread_parameter <- swat_parameter
           thread_parameter <- modify_parameter(parameter, thread_parameter, 
               file_meta, run_index, i_run)
           write_parameter(file_meta, thread_parameter, thread_path)
       }
       msg <- run(run_os(swat_exe, os), wd = thread_path, error_on_status = FALSE)
       if (nchar(msg$stderr) == 0) {
           model_output <- read_swat2012_output(output, thread_path) %>% 
               extract_output(output, .)
           if (!is.null(save_path)) {
               save_run(save_path, model_output, parameter, run_index, 
                   i_run, thread_id)
           }
    ...
1: run_swat2012(project_path = swist22_mgmt_txtinout_path, output = define_output(file = "hru", 
       variable = "LULC", unit = 1:1824), parameter = par)

I'd be grateful for help, as I was unable to resolve the error myself. Thanks a lot :)

Cheers Alex

[alahri89]

Hi everyone,

short update from my part: I was not aware that the package has been renamed to SWATrunR, so I havn't been using the latest version of the package. I now installed SWATrunR 0.9.4 and rerun the example code I provided above with that version of the package. However, the error persists, this time with a slightly changed error message explicitly naming a call to purrr::set_names() as the source of the error.

Building 1 thread in 'D:/SWAT-Projects/Swist/Modellvarianten/Swist22/Scenarios/3_mgmt/TxtInOut/.model_run': 
 Completed 1 thread in 1M 57S                                               
Performing 1 simulation on 1 cores: 
 Simulation 1 of 1   Time elapsed: 6M 24S   Time remaining: 0S    Error in { : task 1 failed - "ℹ In index: 1.
Caused by error in `set_names()`:
! The size of `nm` (86) must be compatible with the size of `x` (85)."

The important parts of the stack trace are basically the same. I was aware that the error is probably raised by purrr:set_names(), but I am not familiar with the inner workings of foreach() and was unable to locate the error more precisely.

[chrisschuerz]

Hey @alahri89,

I ran the code above with my small test setup and cannot reproduce the error, even with the parameter change. The only thing I had to change was of course the unit input argument as my setup has a lower number of HRUs.

The only thing that I can think of as a potential issue is that a change of DEPIMP_BSN.bsn to 2 meters causes an issue in the simulations and generates e.g. absurd large values in the HRU output file, so that columns run into others and cannot be separated anymore when run_swat2012 tries to read them.

Can you have a look into the output file in '.model_run/thread_1/outputs.hru' if there are any odd columns with large values or **?

[alahri89]

Hi Chris,

thank you for your quick response and taking your time!

I was unable to find any ill-formatted columns in my output.hru file, and I managed to properly read the file into a data.frame using base R's read.fortran() function.

However, I noticed that the output.hru has exactly 86 columns. This fits the numbers given in the error message, if the output.hru is formatted in a way that creates only 85 columns when read by SWATrunR. What's more, I was able to avoid the error when I set DEPIMP_BSN.bsn to 0. The error seems to re-appear as soon as I set the parameter to values greater than 0 (I tested it with values of 1, 500, 1000 and 2000). Nevertheless, this should all be valid input for DEPIMP_BSN.bsn according to the SWAT2012 documentation.

In summary, you are probably right with your suspicion that it is a formatting issue in the output.hru file caused by modifying DEPIMP_BSN.bsn. But I was unable to locate the exact error in output.hru (the file is huge), and it is kind of perplexing to me that I managed to read the file using read.fortran() despite the supposedly bad formatting. I'm a bit unsure how to proceed: Is this an obscure SWAT problem that I happened to run into, with SWAT printing badly formatted output files under certain circumstances? Or is it something that arises and can be dealt with inside SWATrunR?

If you can't provide any further help from the distance, I understand. I appreciate the effort in any case. Thanks for the amazing package by the way. Until now, everything worked like a charm and made my work with SWAT much more fun :)

Cheers Alex