Series of errors for external users of EpiModelHIV public version

[sgoodreau]

Hi @smjenness and @AdrienLeGuillou The email below is from @sestansfield, my former PhD student and long-time collaborator. The as.control.list piece sounds familiar, although a quick search of issues and e-mails doesn't find anything. I think both issues most likely indicate that there are updates in EpiModelHIV-p that need to be ported over to EpiModelHIV. A quick workaround could be to grant them access to EpiModelHIV-p, but it's probably best to solve the issue altogether.

I'm going to go check my latest version set-up for them now.

Hi Steve,

My group at the Hutch is getting ready to use EpiModelHIV for an upcoming project. I have been working with Sam to get the ARTnet data to run the code for his Atlanta MSM model as a jumping off place. One of the other postdocs (Serin) has been trying to start working with the code before we get the data and has run into some issues relating to versions, with the version of EpiModelHIV on github being from a few years ago versus EpiModel itself being very current.

This is how she described the issue:

I am writing to seek your guidance on replicating the Atlanta MSM model from https://github.com/EpiModel/CombPrev repository.

I tried using the renv.lock setting, which includes R 4.0.2, EpiModel 1.7.3, EpiModelHPC 2.1.0, etc., this setup yields many errors while installing other packages (e.g., nlme, mgcv).

To address this, I downloaded the most recent versions of EpiModelHIV (v. 1.5.0), EpiModel (v. 2.5.0), and EpiHPC (v. 2.5.0) on R 4.4.2 from the provided GitHub repository. However, I still encounter some errors due to compatibility issues, particularly with the outdated functions in EpiModelHIV, which was last updated in 2020. Here are some of the problems I have encountered while running the intervention/sim.R file with the most recent versions:

• Error with as.control.list method: When running the netsim function with burnin, param, init, and controlas arguments, I received an error indicating that there was no applicable method for as.control.list applied to an object of class "control.net". To work around this, I had to specify the class of the control object to include "control.net", "control.list", and "list".
• Error in departure.FUN module: When running the same netsim function, I encountered an error in the departure.FUN module at step 3381, indicating that the deleteAttr function could not be found. The deleteAttrfunction was deprecated after version 2.4.0, so I need to modify this function to address the issue.

Given these challenges, I am seeking advice on the best practices to make EpiModelHIV compatible with the current versions of EpiModel and EpiHPC. Any insights or recommendations you could provide would be greatly appreciated.

Thank you for your time and assistance.

Are we missing anything in running EpiModelHIV?

Thanks!
Sarah

[AdrienLeGuillou]

Hi @sgoodreau, EpiModelHIV is indeed very much behind EpiModelHIVp.
I'll chat with @smjenness Today to see how to resolve that.

[smjenness]

@sestansfield : this renv.lock should (theoretically, we are testing this now) work, but it seems like you are working with a newer version of R, rather than the linked version 4.0.2 and that is why you are getting some package install fails. You could use an R version manager like Rig (https://github.com/r-lib/rig) to use a specific version of R instead.

[sgoodreau]

Update from Sarah's post-doc:

I have indeed installed and tested with the R version 4.0.2, but it still got some errors. As Sarah mentioned in the email, I used the renv.lock setting, which is R 4.0.2, EpiModel 1.7.3, etc, but this setup generated many errors while installing other packages.

My best guess is that updating EpiModelHIV would help resolve this problem, but I’ll give it another try using the older version R tomorrow. I have also noticed the tickets issued on GitHub EpiModelHIV and will continue to keep an eye on the progress.

[slee-fredhutch]

Update from Sarah's post-doc:

I have indeed installed and tested with the R version 4.0.2, but it still got some errors. As Sarah mentioned in the email, I used the renv.lock setting, which is R 4.0.2, EpiModel 1.7.3, etc, but this setup generated many errors while installing other packages.

My best guess is that updating EpiModelHIV would help resolve this problem, but I’ll give it another try using the older version R tomorrow. I have also noticed the tickets issued on GitHub EpiModelHIV and will continue to keep an eye on the progress.

Hi, I'm the post-doc working with Sarah.

I’ve tried installing EpiModel v1.7.3 to run the basic version of EpiModelHIV (v1.5.0) with R 4.0.2, but it still gives some errors. It seems that some of the issues are related to architecture compatibility, as I’m using a Mac with a recent Apple silicon chip, and some of the required package versions don’t support it, given that EpiModel v1.7.3 was built in 2020.

[AdrienLeGuillou]

@sgoodreau I tried to do an install with R4.0.5 and the renv.lock file from the CombPrev repo.
I confirm that making it work woud be non trivial.

The best course of action would indeed be to use recent EpiModel and EpiModelHIV. The past 2 years have seen a lot of breaking changes in R itself and a lot of packages that we depend on had to be upgraded. This in turns create unsolvable dependency loops for older EpiModel version.

[sgoodreau]

Thanks @AdrienLeGuillou. I'm not sure what you mean by using "recent EpiModel and EpiModelHIV". Do you have a specific set of versions that you know work together without errors? Or by recent do you mean to use a version of EpiModelHIV-p, since those are updated? If the latter, we will need to give Sarah and Serin access.

[sgoodreau]

Also - is there anything I can help with in terms of updating the current public versions?

[AdrienLeGuillou]

Oh sorry for being imprecise.
I meant the default branch of EpiModelHIV-p and the latest CRAN release of EpiModel.

For the public version of EpiModelHIV, it's "simply" a question of what we want to share and when.
I'll see with @smjenness on Tuesday what he recommends. The actual porting is not a use issue.

[sgoodreau]

OK thanks @AdrienLeGuillou. I will grant them access to EpiModelHIV-p now.

[sgoodreau]

Oh wait it looks like Sarah is already a member of the EpiModel organization, so should have access. I think we should add her post-doc Serin Lee but it doesn't seem like I have permission to do so, at least that I can find.

[sgoodreau]

Serin's username is @slee-fredhutch