Coder Social home page Coder Social logo

tomthe / rsoc Goto Github PK

View Code? Open in Web Editor NEW
3.0 4.0 1.0 2.41 MB

run SOCSIM from within R. Go to the new repository for this package: https://github.com/MPIDR/rsocsim

Home Page: https://mpidr.github.io/rsocsim/

R 4.28% C++ 48.49% C 47.23%
kinship microsimulation r-package

rsoc's People

Contributors

tomthe avatar

Stargazers

 avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

Forkers

mpidr

rsoc's Issues

Increasing the age limit from 100 years to a higher value

Socsim has a hard age limit of 100 years. Everyone still alive is killed when he/she is still alive with 100.
Several use cases for simulations with higher age limits have emerged.

We discussed this with Diego, Liliana, Emilio and Ashton over email. I copy our email exchange here into this issue for documentation.

From: Theile, Tom

changing the age_limit is harder than I thought. Changing the relevant values from 100 and 1200 to any other values leads to hard to locate crashes during the start of simulations. I need to find out why it crashes. I will keep you updated.

Von: Theile, Tom
in principal yes, users could modify the variables and then recompile the package.

But I found the values 100 and 1200 in the source as well, so these would also have to be changed to the variables.
I will know more once I actually tried this.

Von: Ashton Verdery <[email protected]>

This all makes sense and if it's already implemented as maxage/maxmonths can advance users just set it themselves and deal with the computational consequences on their own? Maybe just note in documentation.

Ashton

On Thu, Aug 18, 2022, 7:42 AM Theile, Tom wrote:

Hi,
There are a few loops in socsim that run from 0 to MAXUYEARS and several that run from 0 to MAXUMONTHS (currently = 1200). I strongly suspect that they do not have a strong impact on the time it takes to perform one simulation, but increasing the maximum age to a very high number is because of that not something I would suggest (although otherwise I would agree with Ashton: Why not?).

So I would take a nice, round number beyond anything that we need at the moment... like 150 or 200 years.
I will nevertheless crank it up to 10000 to test whether it has any impact on results or simulation time.

Best,
Tom

Von: Alburez-Gutierrez, Diego
Hi again

Quick update, I heard back from Ashton (now also in cc) with the following suggestion:
If needed, I'd recommend 130 since that is how old the current max model UN life tables go.
I recognize a maximum is needed, but why not set it to a very large number such as 9,999? I doubt many users would take advantage of it, but I could imagine if one were modeling a hypothetical system about say future kinship on Mars after we cure all disease it could be useful to be higher. Is there a cost to just making a maxage parameter (default 100) and then letting people fill in rate schedules up to it?

Tom, do you think this is feasible? A maxage parameters could be a good way of ensuring that previous scripts that relied on the original socsim release do not break.

Diego

 

From: Alburez-Gutierrez, Diego
Hi Both

Sounds good. It seems like the upper most age group in HMD data is 110+, so perhaps we can also limit SocSim input rates to 110? I don't know how common it is to actually get rates for anything higher, at least the moment. Of course, if we think that rsoc may be in use for decades to come, these data may yet become available. However, I would stick with 110 for now.

What do you think, Emilio? I just emailed Ashton, who was the first to request this change a while back, to ask if he has any thoughts on this. I also include Liliana in this email, in case she has any ideas.


Best

Diego

 

From: Theile, Tom

Okay, I will change the age-limit and let Liliana try it (She would like to have a higher limit).

Socsim will need a tiny amount more memory because of it (which might be the reason it was there?), but it is neglible.

I think 150 would be a good new limit, any reason to go even higher?


Von: Zagheni, Emilio

Hi Tom and Diego,

My quick reaction would be that, if there is demand for it and it is not too time consuming to implement, then why not? A new age limit may have to be chosen though…

-Emilio

From: Alburez-Gutierrez, Diego
Hi Tom

I am looping Emilio into this conversation to see what he thinks. Personally, I think it would be a welcome development, especially considering that Liliana is interested in studying longevity, so that restricting ages to one hundred may not make that much sense altogether. However, if we do this, it would be the first really significant way (from the point of view of the user) in which we would be deviating from ‘standard’ SOCSIM. I also wonder, and Emilio is better position to answer this, whether there was a substantial reason why the upper age limit in the simulator was restricted to one hundred.

Diego

From: Theile, Tom
Hi Diego,

increasing the age limit seems to be very easy. There are two variables MAXUYEARS and MAXUMONTHS which are set to 100 and 1200. Then there are a few occurrences of written 1200 when the age is checked. Just changing them and recompiling SOCSIM would be easy. There is a small chance that this will introduce some obscure bug, because I overlooked something, though.

Best,
Tom

Von: Alburez-Gutierrez, Diego
Hi Tom

Quick question – we spoke at some point of increasing the upper age limit of socsim from the current 100 years to something higher. Is this something you have already looked into?

Best

A case for avoiding non-standard output directory sructures

I just came to realise that some people call SOCSIM 'iteratively'. Let's say that you have rates for two years. One way of running a socsim simulation would be to have a sup to run a single simulation like:

segments 1
input_file init
output_file out

duration 12
include asmr1
include asfr1

duration 12
include asmr2
include asfr2

run

However, other people call SOCSIM recursively by having two sup files. The first runs the first set of rates and stores the output opop in a pre-defined place:

segments 1
input_file init
output_file out

duration 12
include asmr1
include asfr1

run

and the second sup file uses the output of the first simulation to apply the second set of rates:

segments 1
input_file out
output_file out

duration 12
include asmr2
include asfr2

run

In this context it doesn't make sense to create a separate 'sim_result' directory for each simulation output (like sim_results_sSWE_example.sup_20220803). Instead, the 'original' SOCSIM approach of storing the outputs in a user-defined place should be preferred.

Problems installing RSocsim (OS)

Hi - and apologies if there is another way I should try to fix this - I am new to R and coding in general. I have a project I would like to use RSocsim which I'm very excited by. I get the below error message when trying to download it. Any guidance would be very much appreciated.

devtools::install_github("MPIDR/rsocsim")
Downloading GitHub repo MPIDR/rsocsim@HEAD
── R CMD build ──────────────────────────────────────────────────────────────────────────────────────────────────────────
✔ checking for file ‘/private/var/folders/0t/q_68jd055v19hpk23zywzp2r0000gn/T/RtmpxoXvnA/remotes7d3d60ce0dbb/MPIDR-rsocsim-8b3e1cf/DESCRIPTION’ (832ms)
─ preparing ‘rsocsim’:
✔ checking DESCRIPTION meta-information
─ cleaning src
─ checking for LF line-endings in source and make files and shell scripts
─ checking for empty or unneeded directories
─ building ‘rsocsim_1.4.1.tar.gz’

  • installing source package ‘rsocsim’ ...
    ** using staged installation
    ** libs
    clang++ -mmacosx-version-min=10.13 -std=gnu++14 -I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG -I'/Library/Frameworks/R.framework/Versions/4.2/Resources/library/Rcpp/include' -I/usr/local/include -fPIC -Wall -g -O2 -c RcppExports.cpp -o RcppExports.o
    clang++ -mmacosx-version-min=10.13 -std=gnu++14 -I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG -I'/Library/Frameworks/R.framework/Versions/4.2/Resources/library/Rcpp/include' -I/usr/local/include -fPIC -Wall -g -O2 -c startSocsimWithFile.cpp -o startSocsimWithFile.o
    **startSocsimWithFile.cpp:4:10: fatal error: 'src\events.cpp' file not found
    #include "src\events.cpp"
    ^~~~~~~~~~~~~~~~
    1 error generated.
    make: *** [startSocsimWithFile.o] Error 1
    ERROR: compilation failed for package ‘rsocsim’
  • removing ‘/Library/Frameworks/R.framework/Versions/4.2/Resources/library/rsocsim’
    Warning message:
    In i.p(...) :
    installation of package ‘/var/folders/0t/q_68jd055v19hpk23zywzp2r0000gn/T//RtmpxoXvnA/file7d3d74403a37/rsocsim_1.4.1.tar.gz’ had non-zero exit status**

Handle and remove compiler warnings

During the compilation of SOCSIM (with Rcpp), the compiler prints more than a hundred warnings into the console.
A large part of them stem from the fact that large parts of SOCSIM were written in older versions of C/C++ which did not warn about these issues. Most of the issues are coding-style related, but a lot of the issues might actually be serious issues. Nevertheless the warnings might irritate new (and not new) users of the R-package and should be removed.

Strange behavior when reusing the process. Initialization of arrays

The command line version of SOCSIM creates a new process every time we start a simulation from the CL.
rsoc runs by default ( or the "inprocess"-method) inside the R process. If we run a simulation a second time, arrays (e.g. rate blocks...) might have contents from a previous run. This can lead to strange results, when we change the rates.

Solving this would mean to initialize all arrays correctly. The workaround we have at the moment is to start a new process inside R (usually meant to do parallel processing. This works okay, but we are not able to route the print-statements to the R output. So you can not see how far the simulation has come. (But output gets written to the .log-file which can be read during simulation).

Todo:

  • Check if enough gets written to the .log file
  • mention in documentation that CTRL + SHIFT + F10 restarts R and makes the "inprocess" execution mode safe.
  • figure out how and where to initialize these arrays (not 100% sure that this alone would solve the issue).

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.