Making Quantile Residulas and VAST is not linked as DLL

[dshanisko]

I have just recently updated to R 4.0.3 and have been converting older models over the the newer versions of VAST and FishStatUtils and ran into the following:

Error in simulate_data(fit = list(tmb_list = list(Obj = Obj)), type = type) : VAST is not linked as a DLL, so simulate_data will not work. Please re-run model (potentially from informative starting values to save time) to use simulate_data

I had been running a sequence of models and outputing to a new subfolder for each run. During my initial test of all worked up until the plotting of "### Making quantile residulals..."

The first model succeeds with:

Making quantile residuals using conditional simulation and package DHARMa

Sampling from the distribution of data conditional on estimated fixed and random effects Finished sample 25 of 250 Finished sample 50 of 250 Finished sample 75 of 250 Finished sample 100 of 250 Finished sample 125 of 250 Finished sample 150 of 250 Finished sample 175 of 250 Finished sample 200 of 250 Finished sample 225 of 250 Finished sample 250 of 250 No fitted predicted response provided, using the mean of the simulations Substituting probability-integral-transform (PIT) residuals for DHARMa-calculated residuals Invisibly returning output from DHARMa::createDHARMa, e.g., to apply plot.DHARMa to this output

Plotting quantile residuals

Warning messages: 1: In spTransform(xSP, CRSobj, ...) : NULL source CRS comment, falling back to PROJ string 2: In wkt(obj) : CRS object has no comment 3: In spTransform(xSP, CRSobj, ...) : NULL source CRS comment, falling back to PROJ string 4: In wkt(obj) : CRS object has no comment 5: In spTransform(xSP, CRSobj, ...) : NULL source CRS comment, falling back to PROJ string 6: In wkt(obj) : CRS object has no comment

The second model, which is identical to the first with the exception of the subfolder results in:

Making quantile residuals using conditional simulation and package DHARMa

Sampling from the distribution of data conditional on estimated fixed and random effects Error in simulate_data(fit = list(tmb_list = list(Obj = Obj)), type = type) : VAST is not linked as a DLL, so simulate_data will not work. Please re-run model (potentially from informative starting values to save time) to use simulate_data In addition: Warning messages: 1: In spTransform(xSP, CRSobj, ...) : NULL source CRS comment, falling back to PROJ string 2: In wkt(obj) : CRS object has no comment 3: In spTransform(xSP, CRSobj, ...) : NULL source CRS comment, falling back to PROJ string 4: In wkt(obj) : CRS object has no comment

This has occurred on two different laptops under R 4.0.3 and MRAN 4.0.2 with slightly different configurations. Has anyone esle experienced this message? I ran several other tests and the initial model typically works, but successive models give the warning message.

I examined the portion of code that appears to generate the message...

Check for loaded VAST

Modified from TMB:::getUserDLL

dlls <- getLoadedDLLs() isTMBdll <- function(dll) !is(try(getNativeSymbolInfo("MakeADFunObject",dll), TRUE), "try-error") TMBdll <- sapply(dlls, isTMBdll) if( sum(TMBdll)!=1 ){ stop("VAST is not linked as a DLL, so simulate_data will not work. Please re-run model (potentially from informative starting values to save time) to use simulate_data") }

When I run this outside of plot_results my sum(TMBdll) is equal to 2.

Apologies if I have missed something obvious.

David

[kellijohnson-NOAA]

It can only have one vast model loaded at a time. You need to unload the previous one otherwise it does not know what model to simulate from.

[dshanisko]

Thank you. That makes sense. Is there a simple way to unload a specific model one results are reported?

[James-Thorson-NOAA]

Interesting. I guess I haven't tried this simulation code when running models in sequence. Thanks @kellijohnson-NOAA for responding and suggesting a fix!!

Any thoughts on a generic fix for this behavior from you two or anyone else?

[kellijohnson-NOAA]

I often run models outside of the directory where it is compiled, so i don't think it is a good idea to just assume that the directories should match up. It does seem like it might be okay to assume that if more than one VAST model is loaded that you would want the most recent one, which would require getting the data frame of loaded DLLs and using file.info() to find which one was compiled most recently. Might be best to just put the work back to the user but give a more informative error message that lists the DLLs of interest and the call giving people an example of how to unload one.

On Mon, Oct 26, 2020 at 12:27 PM Jim Thorson notifications@github.com wrote:

Interesting. I guess I haven't tried this simulation code when running models in sequence. Thanks @kellijohnson-NOAA https://github.com/kellijohnson-NOAA for responding and suggesting a fix!!

Any thoughts on a generic fix for this behavior from you two or anyone else?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/James-Thorson-NOAA/FishStatsUtils/issues/54#issuecomment-716772688, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA7LCFEF5V5OBIVKB74KY2LSMXETJANCNFSM4S7ZDCBQ .

-- Kelli Faye Johnson, PhD Research Fish Biologist Northwest Fisheries Science Center National Marine Fisheries Service 2725 Montlake Boulevard East Seattle, Washington 98112 (206) 860-3490 kelli.johnson@noaa.gov

[James-Thorson-NOAA]

If hypothetically I identify the most recent using file.info(), or alternatively get the user to identify which directory contains the right model object to use ... is there some way to then pass that info to obj$simulate() to then use it?

I.e. do you know of any way around this issue besides closing all DLLs except the single one that is intended to be simulated from?

[James-Thorson-NOAA]

OK, on the development branch I have now changed simulate_data(.) to allow multiple DLLs to be loaded when using simulate_data, and giving a warning when more than one is loaded. I think this will then simulate from the more recent DLL. I welcome feedback on this thread, but I'm closing it for now.

[dshanisko]

Thanks you.