Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Random <0.1% variation in GCAM outputs #199

Closed
harounchahed opened this issue Mar 10, 2022 · 2 comments
Closed

Random <0.1% variation in GCAM outputs #199

harounchahed opened this issue Mar 10, 2022 · 2 comments

Comments

@harounchahed
Copy link

Hi,

I have run the same GCAM scenario (with the same config files and input data) 3 times in a row and the results were slightly different at each run. The results are different by ~0.0007% at each run, so it's an insignificant change and is likely due to a random seed setting in GCAM. However, I am curious to know what is this variation due to and am wondering if it can be avoided (e.g., by setting a value for the random seed if that exists).

Thanks in advance for your help!

@pralitp
Copy link
Contributor

pralitp commented Mar 10, 2022

Hello Haroun,

Right. Since GCAM 5.4, by default, running the same scenario repeatedly is only guaranteed to reproduce results within solution tolerance. However, this is not because GCAM is explicitly using any randomization. Instead it is because since version 5.4, by default, GCAM utilizes multiple CPU/cores to perform computations. And due to the inexact way numeric values are represented in a computer the introduction of these parallel computations causes non-deterministic behavior.

The error from these non-deterministic operations is small, on the order of 1e-9 difference for market supplies and demands which need to be solved. However, some markets in GCAM are also modeled in a range of values as low as 1e-6. And certainly a lot of decisions with in the solution algorithm operate on small value thresholds. Thus the non-deterministic operations could, and often do, lead to very different paths through the solver. Thus the results are only guaranteed to be reproducible within solution tolerance.

If exact reproducibility is important for your work then you should re-compile GCAM with parallelism turned off as detailed in the build instructions documentation.

@pralitp pralitp closed this as completed Mar 10, 2022
@harounchahed
Copy link
Author

This is very helpful - thanks a lot Pratel!

pralitp added a commit that referenced this issue Jun 7, 2022
Merge in JGCRI/gcam-core from sha/feature/detailed-industry-byu to master

* commit '8c5cd23104dcb1555ee17a1e057f53c25a788276': (88 commits)
  Update logit exponent for chemical feedstocks
  Update other industry energy use and feedstocks terminal_coef
  Copy NONENUSE bitumen usage to NECONSTRUC
  Update PREBUILT_DATA.rda
  Update chemical and construction sector income elasticity
  fix small bug in query from 04aaad4
  revise cogeneration queries for Rapid XML change (from output-secondary to secondary-output)
  Update query
  Delete files and comments
  Update nomenclature of the constants
  Update aluminum income elasticity for Africa_Southern
  Update GCAM_DATA_MAP.rda
  Update Main_queries.xml
  Revise BLASTFUR shareweight and interpolation rule assumptions
  Delete EAF with scrap CCS
  Add missing precursors
  Revise hard-wired iron and steel supply sector
  Remove hard coding
  Remove trailing spaces from "electricity " and "delivered coal "
  Revert back hydrogen and nuclear share weights
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants